What happened to the homepage?

With all the attention spent on conversions, micro sites, landing pages and retargeting, have we neglected our home pages?

Think about it.

Have you really looked at the analytics behind the user interaction with your homepage? Do you have more than 10 links? If so, what if one of those links receives only 2% of the click through traffic? Is it still worth including it on the page?

These questions and more might (and should) be on your radar. In fact, do we even need these relics of the web one-point-oh? How do we understand what should go into designing and possibly reinventing these cornerstones of our websites? And, is it possible to use customer data, market research, web analytics and thoughtful design to turn a clunky, overlooked page into a useful tool for our customers that adds value to our marketing strategy?

I believe that we haven’t paid enough attention to designing intelligent home pages. But, I also believe the keys to deciphering the ingredients that are needed to make great pages (great depends on what matters most to your organization) are well within your reach.

This April, I’ll be presenting on what I feel is a methodology for creating a great home page experience at Innovation Enterprise’s Social Media and Web Analytics Innovation Summit. After the summit, I’ll share my findings and postulations on my site here. Stay tuned!

Should I purchase domain names proactively?

This past week, The Donald made headlines when it was uncovered that his company owned thousands of domain names that are simply being parked in what it deems as a defensive move.

Says Trump’s son, Eric, “For a company like ours, it’s incredibly important to protect ourselves, and it’s incredibly important to own our intellectual property.”

Here’s why this doesn’t make financial sense, and why it also a futile effort:

Yahoo lists some of the domains owned:

  • DonaldTrumpSucks.com
  • TrumpCorporationSucks.com
  • TrumpOrganizationSucks.com

It typically costs anywhere from a few dollars to about $15 to keep each domain per year. Let’s say it’s $10. And let’s say they have 50,000 domains. That means they are paying $500,000 a year to park these domains. Chump change for a billion-dollar corporation, right? Well, after 20 years, that’s $10 million. Not to mention the lost return on capital the $500,000 would generate on a annualized basis.

The Trump organization is probably also (over)paying an agency to manage these domains on their behalf… perhaps another $50,000 – $100,000 per year.

When asked, I have never recommended purchasing domain names to thwart potential slander. And I’m asked this same question at each company I work. The reason is pretty simple, you just cannot purchase all the combinations of potentially scandalous domain names. In fact, there are 36 to 245th power which is basically a 2 with 381 zeroes following it. That’s a lot more than a google, and a lot of $10 bills each year. For example, here are five domain names I could purchase that they haven’t yet:

  • DonaldTrumpSucks1.com
  • DonaldTrumpSucks123.com
  • DonaldTrumpSucksABC.com
  • DonaldTrumpSucksNYC2016HellYeahEveryone.com
  • DonaldTrumpSucks3000.info

See my point?

Not only is this a waste of money, it’s a waste of time.

Proponents of this futile activity will claim “it’s worth it if we even thwart one attack!” But you won’t. If you know search engine optimization, you don’t even need Trump in the name of your website to talk about the organization. I’m talking about them now, and if I had good content and SEO, then I won’t need a Trump-specific domain name to spread my word.

And, let’s say you are slandered, if another person is using your trademark and/or slandering you, there’s a really good chance you can shut them down through the legal system – and it’s typically not a big company fighting you, but an individual that lacks sufficient legal resources to counter attack.

So save some time and a lot of money and stop buying domains you don’t need.

How to redo a corporate website in 12 weeks

UMA's new homepage

UMA’s new home page.

Website relaunch projects don’t have to take a year (or more). In fact, when executed properly by skilled teams, you can rapidly deploy (or redeploy) a new website. Here’s how I recently relaunched the website for my school, Ultimate Medical Academy:

  • PREP PHASE (12 weeks prior to project start; or launch minus 24 weeks)
    My web team (consisting of two employees) tested out some concepts for the new website by piloting the technology and styles on smaller projects ahead of time. We knew we wanted to push the envelope quite a bit with the school’s site, but we didn’t want the site to be the first time we tried all the new bells and whistles. Like any good web team, we have and actively manage a project backlog or road map that goes out about a year. This helps us understand what’s ahead and manage our time effectively. It also enables us to pilot some new techniques ahead of time. So, beginning about six months earlier, we had two very small websites to build for other projects at UMA. In each of those builds, we tried a few new things. Some worked, while other ideas didn’t pan out as we had expected. These sites served as a proving ground for new ideas.


  • RESEARCH PHASE (week 1)
    First, we formed a steering committee that included the following members of the marketing team: web manager, web developer, copywriter, brand director, creative manager, search marketer, and me (the VP). That’s it. This group would make all the decisions, with the VP (me), holding veto power and general oversight of scope. The web manager would be the project manager and oversee development and the day-to-day project plan. Next, we asked each member of the steering committee to spend a couple hours looking at and documenting sites they felt were “great.” It didn’t matter what your definition of great was; just that you came back the next day with a good list and could present it to the team. More on that in a moment. The other task we completed early on in the first week was to discuss the results of a brand perception study we had completed months earlier which helped us understand what our customers really wanted out of their experiences. During this phase we met pretty much daily to discuss all the features and aspects we wanted to include in the site. We reviewed everyone’s wish list, sample sites from their research, competitor sites, and so on. The end results was a ranked list of features into a couple of buckets: things our site must do at the launch, and things we wanted the site to do eventually. While we knew that a success project needed to have some elasticity to accommodate unforeseen needs along the way, it was also important that we minimize scope creep to hit the 12 week goal. At this point in the project we did not worry about “how” to do something, just whether we wanted to do it. Later, during the development process, we would tackle how to address items that were excessive in development time and light on ROI. The goal was to come out of the week with a solid list of features. Additionally, during the first week (and carrying into the 2nd week), we identified every major department at our school (about 10) and met with each stakeholder group’s leadership for about 60-90 minutes. During these meetings we explained the project’s goals, set expectations, and solicited feedback/input into the site. The questions we asked were fairly basic:

    • Does the current site meet your needs?
    • Do you use the current site? If no, why not?
    • What would you want out of a new site?
    • What other sites do you like and why?
    • Who can we work with on your team to help update your section’s content/copy?


  • DEVELOPMENT & DESIGN (weeks 2-12)
    Now the sprint begins. We kicked off three separate initiatives at once because we knew that if we ran the three parts of the project in serial order, we wouldn’t hit the 12 week goal.

    • Our copywriter began rewriting what would become nearly 200 pages of copy
    • Our designer began mocking up the different templates for various site sections
    • Our developers started work on the templates and sandbox config by having the three teams work in concert, we had to communicate daily to ensure pieces fit together, especially with how copy was to be produced. For example, our copywriter had to work with the other two teams on headlines to ensure there was enough space for various copy elements incorporated into the template designs.The designer had to work closely with the developers to ensure that his designs could be easily reproduced in the code.As the VP of marketing, I had to ensure that project requests outside of the web reboot were minimized in order for the teams to be able to focus primarily on the website project. We set aside 20% of our week (about one day) for other projects, but ultimately were able to reduce that a bit further. We did have to supplement our 12-week schedule with a few late evenings a couple weekends, but nothing too dramatic. We wanted to use the extra time mid-project rather than wait until the end and scramble. This gave us a much more predictable finish date, as we did our “long hours” mid-project and then glided in. Though, I don’t want to underscore how close of a finish it was. But more on that later.


  • COMPLIANCE & REVIEW (weeks 4-12)
    The majority of public-facing content marketing produces is reviewed by an independent team to ensure that what we are saying is legal and compliant with a score of very specific regulatory requirements governing advertising and communications within the post-secondary education space. This means that everything we write needs to be reviewed. To ensure the compliance team was up to the task, our steering committee met with their team early on to set expectations. We shared the site concept to generate excitement and provide context. We also checked in regularly and developed a good system for sharing feedback, collaborating and obtaining sign-off efficiently. The web developers used draft copy for development, with little formatting or editing, as much of the content would have to be replaced. In other areas, they simply used lorem ipsum types of placeholders, since we knew the copy was going to change during the review. I also reviewed all the copy to ensure the messaging was consistent with my objectives for the new site. This meant that I had to provide a very fast turnaround on the nearly 200 pages of copy; so scheduling the requisite amount of time and attention to this project was key.


    Early on in the project, the steering committee met almost daily. As week three approached, meetings were scaled back to 2-3 times per week. The meetings were used to:

    • Review progress
    • Allow team members to ask questions about features/specs
    • Address issues in real-time
    • Make on the spot decisions
    • Discuss new findings and limitations
    • Review features and scope to reevaluate the two buckets (must have and nice to have)… ultimately, a few items that were found to be heavy in development time and low on ROI were pushed from must to nice. At this point, we began keeping a list of post-launch features that would go into weekly “agile sprints” where we would release new features over time.It was important to understand that we wanted to launch a core website in 12 weeks, not a site that had 100% of everything everyone wanted. So, working with the web manager, we discussed whether certain features could wait, and adjusted the project scope as necessary.


  • LAUNCH PREP (weeks 9-12)
    To set expectations, the actual launch window I provided the school’s leadership was much broader than our target. This would allow me to squeeze a few more weeks of work if needed. So, when communicating out to the organization, I provided a month-long window, with emphasis on the end of the month. However, internally, we were managing to the early-to-mid part of the month.Additionally, I began speaking with members of the leadership team about the site, and even provided “sneak peaks” to a select few individuals, mainly the senior leadership team at the Academy. It was important that I provide them a brief overview of the site so they knew what to expect. I also wanted some feedback, to ensure we were not missing anything critical on the site. During these meetings and demos (about 3-4 took place), we also gauged feedback and excitement to understand where we might want to focus a little extra last minute effort.Since we had planned so well, and sought early input from each department, we found that the site delivered on everyone’s expectations (often exceeding it when it came to look and feel). A couple minor items came out of the demos and the team quickly adjusted what was necessary without losing too much steam.


  • QA / TESTING (weeks 10-11)
    While testing was on-going throughout the project, we expanded the testing efforts around week 10 by bringing in a couple of additional team members for a few hours to help test on various devices (tablet, iOS, Android, IE, Chrome, etc…) This helped us find as many issues as possible in the shortest amount of time. Issues were funneled directly back to the development team and tracked accordingly. The copywriter reviewed all copy once again; and I personally tested a wide variety of devices and stepped through the majority of the site.


  • GO/NO-GO (week 11)
    With about one week remaining in our sprint, we had a go/no-go meeting with the steering committee to understand what was still remaining on the project list and why so we could work through those last roadblocks efficiently.


  • THE LAUNCH (week 12)
    I opted for a soft launch on a Wednesday. This meant that we would coordinate with the information technology team that controls the DNS settings and make the switch in the afternoon after one final go/no-go call between myself and the web manager. Once the switch of the DNS was made, the QA team did another full walk through of the site across their devices and platforms. This revealed a few last minute items that needed to be addressed. Believe it or not, our old site was not heavily used by staff or students (mainly only prospective students), primarily because it was simple and didn’t include a lot of information. So we knew we could do a launch without communicating it widely to everyone at the academy. And, those few extra days of being live and testing; and collecting feedback from the few people that new the site was live, would be extremely valuable. The good news is that there were no major issues. That following Monday, we did the full launch which included an email to all staff, an announcement to our students through the online student portal, posters throughout the building, and information on the staff intranet. We also created a scavenger hunt, with five questions… Staff had to find the URLs for specific items, such as “what page features a picture of an employee dressed as a Rubik’s Cube?” Anyone who answered the questions correctly got a souvenir school pennant and was entered into a raffle for a school sweatshirt. This contest, along with the email announcement helped drive awareness about the site and all the new features.


So what worked and what didn’t?

Overall, the prep and collaboration really proved to be the cornerstone of our success. I cannot underscore how important these processes were. It was equally important to have full buy-in from senior leadership and to protect the team from competing priorities/projects.

Of course the team would have liked more time. That would have yielded minimal differences though. Of course more time would allow for more scope, but we’re releasing new features weekly. It was important to launch a new site quickly with a solid foundation, and then focus on additional features. So more time would not necessarily have yielded a higher quality site – just more features. It may have reduced stress a bit, or eliminated a few of the extra days we spent across a couple late nights and weekends. But I have a feeling we would have used those late nights and weekends even if we had more time.

I owe the success of this project to the steering team (especially John Klingler, the project manager for this endeavor.) It was a lean team, that continues to meet to this day looking at new features and specs to make the site even better. They did the hard work and were successful; I’ll bask in the moment of accomplishing a great feat and then jump into the next project “business as usual.”

What is authentic design?

My esteemed colleague, George Fox, recently shared a fantastic article with me on this very topic.  Essentially, what authentic design boils down to is creating interfaces where design isn’t forced, but rather a product of function and natural utility (of what ever it is you are creating). The post discusses various periods of history drawing comparisons to architecture and materials engineering.

Hands down, it’s one of the best articles on designing for the web I have come across.