Design has a reputation for being one of the more ambiguous areas of product development. I don’t know how many times I’ve heard clients say: “first we’ll get the application functionally correct and then we’ll put a skin on top of it.” This gets my blood boiling.
As Whitney Hess stated earlier this year: UX Design isn’t just “a step in the process.” Users themselves experience much more than just the look and feel of an application. By the time the aforementioned client addresses their application’s aesthetics, many decisions will have been made that have affects the user experience of a project.
Therefore, I engage clients as early as possible in the course of their application’s development, preferably before any code has been written. As a consultant first and a designer second, I work hand-in-hand with my clients—because building a website isn’t easy. I know this because I build websites for a living. With that in mind, empathize with your client: all they want is an application that does “what it says on the box” from day one. This is the reason why functionality is so important to them.
But as interaction designers, we know that the ideas behind the design are much more important than the depth of a dropshadow or the size of the copy. Jeffrey Zeldman addressed these kinds of concerns in his latest presentation at An Event Apart Chicago: A Site Redesign. The ease-of-use and learnability of our application must supersede the vacillating predilections of entrepreneurs (unless, of course, those selfsame entrepreneurs are the application’s target demographic). In other words: our designs should help real people do real stuff.
To promote the overarching goals of the interactions used throughout a web application, I’ve created a tool that I use throughout the application development process, called a Design Strategy document.
So what is a Design Strategy document? Many things. I like to think of it as a design blueprint. A Design Strategy document is a document created by the project team, informed by user research, which explains who is using the application, what their goals are, and what interactions (and underlying functionality) will be created to facilitate those goals. After reading books on information architecture, interaction design, and project management, I couldn’t find a consolidated tool that I can use to drive the design process. So I created one. The method I’m sharing here has worked for me over the past couple of months, but it’s certainly an evolving one. A design strategy document is a UX tool like any other; only as valuable as the processes that it drives.
The best way to conceptualize your client’s new web application is to conduct stakeholder interviews. After all, its their baby you’re creating. The process itself is fairly straightfoward: all you need is a conference room, your client (preferably in person), and a dry-erase board. Make sure that you bring an interaction designer to the meeting. Next, simply ask clients basic questions about their application.
To facilitate conversation, take a cue from Alan Cooper’s “About Face 3.” Namely, think of the interface as magic. When you’re brainstorming solutions to a problem, don’t get specific. Just assume that an interface that will make something happen exists.
This means that you shouldn’t get bogged down in implementation details. Don’t talk to your client about HTML5 or how you’ll use a modal box to do something. They don’t think in these terms (just yet). Instead, just ask your clients what people are going to do with the system.
Although guesses will be rough without proper user research, ask your client to describe who will use their application. Do they know? Have they talked to them yet? Based their responses and audience segments you may have used or seen in previous applications, segment your users. Sometimes you’ll end up with one group. More likely, though, you’ll end up with two or three. Create a table for each of these user types in your document
But don’t share your groups just yet. Once you believe you’ve sussed out what kind of users this application will target, ask leading questions about these user groups: how will this application behave differently based on which kind of user is using it? Will one type of user (an administrative user) see a different interface than another type of user? Make sure that your ideas about the kinds of users of an application match up with your clients’ ideas.
When you think you’re on to something, share. Odds are you’ve identified the audience segments that your client is approaching in a broad way. If, however, either you or your client can’t identify user archetypes, conduct thorough user research. Follow along with Indi Young in her book Mental Models. Indi gives practical advice on how to really nail down who will use an application and how they will conceptually approach it.
Once there is agreement on who will use the application, it’s time to figure out what these users are going to be doing. Inside of each persona’s table, create rows enumerating the overarching goals that they are trying to accomplish. Stick to as few “major” goals as possible. Each user only has a couple of things that motivate their interactions with your system.
A table helps you parse the major goals that your application will accomplish for each of its user groups. On the right, we list the interactions that will be required.
Invariably your stakeholder will list things like “feel good”, or “make money.” Cooper refers to these broad objectives as “life goals.” That’s okay at this point. If it’s believed that a persona will hav this goal in mind, make sure it’s captured here.
Next we go from abstract to concrete, in essence, laying the blueprint for interaction design. In order to accomplish the goals that users have, they will need to take part in a number of high-level interactions—jot these down. Next to each goal that a user group has, specify the interactions that users will have take part in to drive them closer to that goal. Don’t worry if you repeat some; sometimes users do the same things for different reasons.
At this level, what you’re really defining are use cases. Wise Sage Wikipedia sayeth:
A use case in software engineering and systems engineering is a description of a system’s behavior as it responds to a request that originates from outside of that system. In other words, a use case describes “who” can do “what” with the system in question. The use case technique is used to capture a system’s behavioral requirements by detailing scenario-driven threads through the functional requirements.
Optionally, you may choose to create a separate spreadsheet orf each user group that to elaborates on that group’s use-cases. This can be especially useful if the information/system architecture of the application is complicated. If users have to “trek across” their portion of the system (for example, say that have to take part in a multi-step process) to get something done, elaborating how a user gets from “a to b” can really clarify how the system should function as a whole.
So there you have it. After 2-4 days worth of stakeholder interviews, what do you have to show for it? Our design strategy document is a patchwork of different thoughts, providing insight for a variety of different roles:
In addition to jumpstarting the roles of your colleagues, a design strategy document brings structure to your design process. Done correctly, it manifests a a unified thought process across your projects’ handoff points.
Each interaction that your designers are called upon to create can be shown to directly drive a user towards a valuable goal—something that can’t be said for the broad goals themselves. Said another way, we can’t say that an application makes people “feel more social,” but we can say that, as a collection, a group of interactions drives a user towards that sensation.
Design strategy helps remove the “fog” clouding the path towards user goals. And as farfetched as it might seem, sometimes a spreadsheet of goals and interactions is the most effective thing we can do to prove the value of our design.
When CNN approached Fi it was a thrilling moment here at the agency. Since 1999 we saw the world famous news brand pioneer within the digital …
I was invited to speak at the MonkiGras event this week where getting a little sweary and ranty is kind of encouraged (it goes well with the c…
This is vitally important people so listen up. The web now connects a third of our planet. Over 1.2 billion people [1] use the web on devices,…
Contribute a guest post to UX Booth and let the community know what's important to you!
The community is the lifeblood of UX Booth. If you enjoyed this post, please consider sharing it via a social site, or leaving a comment below. Thanks.
Documenting a project can go a long ways in planning current and future projects. A whole-project document can help your team avoid repeating mistakes, organize ideas, and improve your working process among other things.
Designing websites is an art form as much as it is a science. That’s why here at the UXBooth, we like to occasionally take a break from sharing our opinions to highlight the experiences of others. This month, we’ve asked Travis Schmeisser of nGenWorks to share the secrets of his company’s trade.
Sticking with high–level concepts allows designers to implement a UX strategy without disrupting a traditionally development-heavy workflow. In this post, Lis Hubert and Gabi Moore recount their story creating a UX process at AnyClip in just three weeks.
This is a great article Andrew. Great information here and written so well. Thanks!
Nice article Andrew. Working with clients who know little to nothing about Interaction Design or User-Centered Design can be a challenge and I like the way you address some of these potential challenges. Soft skills are a huge asset during the client engagement process.
Great article, I’ve been usin a method similar to yours, and my focus and most important step of the proccess is your first one: “stakeholder interview”; get the information from the client itself is the most valuable and creates from the beginning a closer relation, and a potencial co-worker.
congratulations.
Nice article.
In my experience, it is extremely difficult for most of my clients to turn over core interaction design, especially if the application is already coded.
It’s funny, even though most people watch TV, they don’t think they could direct a TV show. But EVERYONE thinks they are a UI designer.
Great article.
Another nice thing about conceptualizing a project this way is that it scales very well. Larger projects will just have more user groups, goals, and interactions.
Thanks guys for the feedback. I’m always tweaking the formula to have design preempt development without making the process resemble waterfall.
Fantastic!
A good article, for sure, but I’m not sure it’s necessarily interaction design, no?
These pre-design steps could work just as well (and should certainly be used) for a static brochure web site with no complex interaction or dialogue, or no impression of time at all.
Regardless of whether we’re calling web design interaction design, interactive design (with the emphasis on technology) or something else entirely, it’s always good to document how you arrive at the decisions you’ve made, and it’s a benefit to UX Booth readers to de-mystify the user/client research that’s so critical to achieving success.
Thanks a lot for this interesting article.
Awesome! Great information that designers should know. Thanks.
This is a very clear and well written article, and I think covers the case for very simple applications.
However I do feel that you’ve neglected users too much. Early stage user research while generating Personas and Use Cases can lead to insights that will be far more valid than guesswork. I can’t imagine writing down User Goals without involving users.
Something deeper here is troubling me… Design Strategy cannot be taught in such a short post, and perhaps it’s unethical to present it that way. I feel a longer response brewing, and will save it for my blog. Thanks for getting me thinking :)
Ok, so this isn’t something for my blog. But here are my problems with this article:
It feels like Cliff Notes for design strategy.
It severely understates what it takes to make a successful design strategy. The process can perhaps be summarized in 1500 words, but no article can replace the depth and editorial vetting provided in numerous books on the subject, written by established luminaries. While you link to these books on Amazon (the sales from which, I believe, UX Booth receives a referral fee), this here feels inappropriately like a self-standing primer on the subject.
It regurgitates established UX processes and deliverables with new names, adding to the already silly amount of confusion about the names of things in this field. What everyone else calls Personas, this calls “User Groups”. Use Cases become “Interactions”. Sure, these alternate names are understandable, but why change them? Perhaps because phrasing it that way makes the article sound redundant to anyone who practices IxD / UX. Personas, Use Cases, User Goals? Are these news to anybody? If they are, then they should get a whole hell of a lot more education before calling themselves an Interaction Designer or proposing that they can make a good design strategy.
Finally, and criminally, the article leaves the user almost entirely out. There is a passing mention of user research, which I will paraphrase as “if you have too much trouble making up Personas yourselves, consider doing user research to build them”. An article on the UX Booth that discusses strategy without discussing the user, in your words, makes my blood boil. I’ll avoid describing why the user is important because it has been written about so extensively, and is believed so thoroughly, that the profession is called User Experience (and UX Booth is named after it).
I think that this blog has put out some very solid articles, and therefore I care enough to voice my concerns here :) Keep up the hard work.
Cheers,
Loren
Loren, I agree with your response. Over the next couple of days I mean to go back and edit the article to adjust for the terminology that you suggested. Indeed, I’ve been practicing Interaction Design for a number of years, but introducing user research at the strategy level has been difficult. Only recently (in the past couple of months) have I had more success. I’ll introduce my more recent insights as time permits. Thanks for your feedback!
Andrew-
We’ve been honing our design strategy for the last 3 years- I think the business units/groups/roles have to play an equal part in the thinking.
Here is our rough outline we’ve been using:
http://www.zurb.com/words/design-strategy-framework