This isn’t about the strategy of how to design a website that works–this is my take on how marketers can work with their teams, their bosses and their developers to get the site they want built with less time and less hassle. (PS all of this works for apps, too). Most people who are responsible for websites are amateurs. This is my best take on how the goal-oriented non-professional can do a good job.
Three things worth remembering:
- Every website is a marketing effort. Sooner or later, your site involves an interaction with a user, and that interaction won’t be 100% technical. You have to sell the engagement, the interaction and the story you have in mind. While websites have always involved technology, the tech is secondary to your ability to get your point across.
- Virtually all websites are not on the cutting edge of technology. You’re doing something that’s been done before, at least technically.
- Synchronizing your team is difficult, because most people know it when they see it, and seeing it is expensive. It’s sort of like building a hundred houses in order to find the one that your spouse likes–not a practical effort.
The approach I recommend:
- Find the tech elements you need by browsing the web. Make a list–I want menus that work like this site, a shopping cart that works like that site, a home page that works like this one.
- Create the entire site (or at least the critical elements) using Keynote on the Mac (PowerPoint works too, but Keynote is a little easier to work with). Begin by copying and pasting elements from other sites, but as you make progress, hire a graphic designer to create the elements you need. Keynote makes it easy to actually have spots on the screen link to other slides in the ‘presentation’, so the document you create will actually allow your team to click on various parts of the screen and jump to other pages.
- Do not do any coding at all.
What you end up with, then, is a 3 or 10 or 100 page Keynote document, with a look and a feel. With menus. With fonts. With things in their proper hierarchy. Once you’re good at this, you can build or tweak a ‘site’ in no time.
Now you have a powerful tool. You can use it in presentations, in meetings and even test it with users, all before you do any coding at all. Once you’ve shared this with the team, the question is simple, “if our website works just like this, do you approve of it?” Don’t start coding until the answer is yes.
This is a discipline, one that takes a fair amount of guts to stick with, but it pays off huge dividends. Don’t code until you know what you want.
Last step: Hand the Keynote doc to your developers and go away until it’s finished.
As I said, this works for mobile apps too. Here’s a site filled with template shortcuts for both.