Where to begin?

I’ve an immense respect for Seth Godin. The man is a genius and has done miracles and wonders for all of us in this beautiful Information Age. And while there’ve been times when I found him a bit nebulous in his advice, I thought never to find myself opposed entirely. But here we are.

Seth’s latest post is a bit of advice on how to build a website, specifically for marketers. It’s a brief post, addressing some very real concerns about how to get the website you want through visualization, because words are often just not enough. As he says in his post, “Synchronizing your team is difficult, because most people know it when they see it, and seeing it is expensive.”

He is exactly right on that point. Seeing it is expensive. But we’ll come back to that …

Seth then recommends a little online shopping. Visit the websites you like and make some lists. Again, this makes some sense. Some of the best projects begin with actual interviews, where client representatives are asked about what websites they admire, what do they like about the way they look, the way they work. Once compiled, this gives a great idea of what stakeholders want to see and how they wish to grow.

So if I agree with Seth so far, what’s my problem?

Because his next piece of advice is sigh-inducingly unfortunate.

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 […] 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.

And with that, Seth has suggested the creation of a weapon of mass assumption.

Imagine, if you will, the hard-working coder who looks up from her keyboard to find a smiling marketer at her side, a 100 page Keynote presentation in hand. “Code this,” the marketer says, then walks away. The coder blinks, dies a little inside, makes a note to check her LinkedIn profile over lunch.

I’m exaggerating, but Seth’s approach is akin to someone building a home by making a Pinterest board of pretty doors and windows, then forwarding the URL to a handful of contractors. With no architect, with no plan, you’re going to end up with an absolute mess.

And yet, Seth sees this presentation as a hammer fit for every nail.

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.

Just like this? Dr Frankenstein had a similar idea, a brilliant dream cobbled from borrowed parts. That went well.

In a way, I’m speaking in defense of my own profession. When I explain what I do, the role of a UX Architect (or Information Architect or Interactive Designer, call us what you will), a big part of that explanation is about how a good set of wireframes (blueprints for a website) can save big chunks of budget. Because they can be flexible, editable, adjustable through a series of presentations and revisions, well-made wireframes settle issues of usability and functional priority before a graphic designer is engaged and long before a coder does the heavy-lifting of making a site an actuality. Furthermore, those wireframes are informed by a UX architect’s training and experience, translating the wishes of a client and the needs of that client’s customer into interactivity that follows best practices and avoids later frustration.

And prior to wireframes, it helps immensely to have strong sets of business and functional requirements. But even if you can’t bring in a business analyst, a simple list of this-is-what-we-want-to-achieve can go a long way and can provide a check against over-reaching and losing your way.

So make your wish lists, imagineer your perfect website, but scrapbooking your way to success isn’t going to give you the results you want or need.

Now, the next question might be this: What if you don’t have a UX Architect on the payroll (or even in your circle of friends)?

Work on your requirements. The hard decisions for you to make are not about how your website looks, but more about what you want it to accomplish. What does your website mean to you? And more importantly, what value will it have to your customers? You’d be amazed how elusive that seemingly simple answer can be.

And the hardest question of all is this one: Why do we even have (or need) a website? If you want some true enlightenment, don’t just ask yourself, but ask three or four of your co-creators. Chances are, you’re going to walk away with three or four very different modus operandi. But the resultant conversation will result in not only a solid reason for being online, but the foundation for a set of actual requirements.

And once you know what you want to do and why, get buy-in on those requirements before stepping into considerations of how. And that way, when your hows shift and change, your what and why remain a dependable constant.