ARTS & FARCES has specialized in user experience for many years, but I’ve been reluctant to write much about the topic. For a variety of reasons, that’s changing now and I’m adding a new “User experience” section to Hasten down the wire.
What better way to kick-off the new section than to publish the basic process the company has been using for more than 30 years to architect information, first in video and print and now most recently on the web. The process has evolved over the years and while I’ll begin with a brief skeleton, my intention is to expand it using Hasten down the wire‘s wiki and eventually publish it as a book-length work.
Important note: This is a work in progress, an attempt to make years of notes understandable to a broad audience. I’ll be adding to it regularly, as time allows, so bookmark it and come back often. In a break from my usual practice of being fully transparent in changes made after initial publication, I’m just going to integrate changes and additions into this article in order to keep it easier to read. And don’t forget to check the project wiki.
First a word about “experts” and expertise.
I’m a fan of Malcolm Gladwell‘s work. n his book Blink Outliers, which opens with a story about an apparently ancient marble statue. When the statue is evaluated by experts in Greek sculpture, each determined it was a fake without any evidence—scientific or otherwise—except their individual expertise. The experts were able to make their determination simply by looking at the statue. Furthermore, the experts were unable to explain how they reached their determination, they just knew.
The experts were able to do this because each of them had individually spent thousands of hours refining their skills and sharpening their instincts through research and practice. The experts had studied their craft to such an extent that each of them was able to make an accurate determination almost instantly.
Gladwell’s book is about rapid cognition: thinking that happens in a blink of an eye. This isn’t about intuition (in fact, the word “intuition” never appears in Blink) but it’s not entirely rational, either.
In his book, Outliers, Gladwell investigates the properties of high levels of success. The core of Gladwell’s investigation is the “10,000-hour rule,” finding that the key to success is a matter of practicing a specific task for about 10,000 hours. Or about 10.5 years (10,000 / 4 hours per day / 240 average working days per year = 10.416666666666667). Gladwell puts it at 20 hours of work each week for 10 years.
Even though I’ve been a practicing user experience professional for many more than 10 years, I’m not sure I’m an expert. I just know certain things, but I’m still practicing. I offer this process with the caveat that it’s worked successfully for ARTS & FARCES over the years, your mileage may vary. Got something better or improvements for mine? Let’s hear them.
Conduct initial decision maker meeting
Any web project—larger enterprise systems or tiny brochure sites—must begin with a meeting of the decision makers. While it’s workable to do this via email, I’ve found it orders of magnitude more effective to get the principals in a room and just hash out the answers to three deceptively complex questions:
- What is the purpose of this website?
- What are the metrics we’ll use to determine the success of meeting the website’s purpose?
- Who is the audience for this website?
- Do you know who your target audience is, what they want, and how you will give them what they want through the website?
- Formal or informal language?
- Will the website be for a wide audience or a specific niche?
Jared Spool’s “three questions:”
- Vision: “Does everyone on your team know what the experience will be like interacting with your offerings five years from now?”
- Ignore the specifics of the design or the system; strive to understand the experience of the user.
- Looking five years out encourages ignoring the immediate realities and limitations and puts the focus on possibilities.
- Only those teams who are not too busy putting out daily fires and do not have different individual visions will be effective.
- Feedback: “In the last six weeks, have your team members spent at least two hours watching people experience your product or service?”
- If you’re not watching your users, you’re not learning from them. Spool maintains that this is usability testing or field studies, not surveys or satisfaction measures. The latter are flawed because they return only disjointed pieces of the picture, e.g., users are frustrated, but no one knows why.
- Without valid, direct data from users, team members can speak only to their own user experience which is likely to be unlike the audience’s user experience.
- Culture of failure: “In the last six weeks, has your senior management held a celebration of a recently introduced design problem?”
- Spool writes, “In a culture that pushes for frequent small changes, problems become opportunities for improvement.” Failure is an opportunity to learn about users’ needs.
- Begin to establish content governance policy
Decision maker meeting deliverables
The sole deliverable for this phase of the process is:
- The project charter
It’s important that you leave the room with at least the promise of a draft of the project charter to be delivered as soon as possible. It doesn’t matter who drafts it, only that it gets done and signed by the decision makers as quickly as possible. Don’t get hung up in this phase of the process. You may not reach unanimity; broad consensus is enough to move on.
Conduct user research
Once those questions are answered completely and integrated into a signed project charter, you can move on to the tricky bit of user research. Here you assemble small groups of representatives of each of your audience groups and ask them three questions that are even more deceptively complex than those posed to the decision makers. And here’s a hint: The answers of representative members of each audience group will almost never match the answers provided by the decision makers. The purpose of the exercise with the decision makers is to simply ascertain who the audience(s) are; the purpose of the exercise with actual members of the audience is to really find out. The questions for which you want answers are:
- What information do you want or expect from this website?
- How do you want that information presented?
- How do you want that information labeled?
User research deliverables
After surveying representatives of each of the defined audiences, you’re ready to create your first set of deliverables for the project:
- Audience definition
- Personas
- User goals
- Functional inventory
- Component requirements
- Initial (draft) content governance policy
Don’t let this scare you. I’ll provide explanations and examples of each deliverable later.
Plan content strategy
- Gather business requirements
- Determine content requirements
- Participate in initial planning meetings
- Establish content governance policy
- Set criteria for success
- Tie in with communication plan, which includes key launch dates for new products/events, etc.
- When you have an idea for a new article or section, write it down now. It’s easier to come back to a list of stashed ideas than start fresh with a blank page.
- Save interesting bookmarks you come across and wish to reference later
- Star interesting items in your RSS feeds
- If your project involves a team of contributors, you could try sharing a plan of articles or sections (e.g., with timeline and responsible authors) using collaboration tools such as Basecamp or a wiki (I prefer the wiki method)
Content strategy deliverables
- Content brief
- Content inventory
- Content audit/value matrix
- Content governance policy
- Gap analysis
- Project plan
Again, don’t let this scare you. These are huge deliverables and I’ll provide explanations and examples of each of them later.
For the rest of this project, please refer to the project wiki on this site.
0 responses. Comments closed for this article.