Focusing Design with Design Strategy

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.

Enter design strategy

After reading books on information architecture, interaction design, and project management, I couldn’t find a consolidated tool to focus my 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. Like any other UX tool, this document is only as valuable as the ongoing processes it drives.

Think of a Design Strategy document as a a design blueprint outlining the operating assumptions and intentions of the project team: why are we doing what we’re doing? who will use our application? what are their goals? what interactions (and underlying functionality) do we believe is necessary to facilitate those goals?

Keep in mind that this document is based on assumptions. In order for a design strategy document to truly facilitate a user-centered design process, those assumptions must be validated and informed by user research.

Stakeholder interviews

All design processes begin with stakeholder interviews, whether informal or not. After all, it’s their baby you’re creating. All you need is a conference room, your client(s) (preferably in person), and a dry-erase board. Make sure that you bring an information architect, interaction designer, or some other “systems thinker” to the meeting. Next, simply ask clients basic questions about their website or 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.

In other words: don’t focus on implementation details. Don’t talk to your client about HTML5 or how you’ll use a modal box to do something. They likely don’t think in these terms (just yet). Instead, ask “what people are going to do with the system?”

Identify “working” personas

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 based on current behaviors, not demographics. 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

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, you’ll need to hit the pause button on the project and conduct more thorough user research. I recommend following along with Indi Young in her book Mental Models, where she gives practical advice on how to really nail down who will use an application and how they will conceptually approach it.

Identify use cases

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.

Identify interactions to design

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.

Final words

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:

  • Team members can see the application’s presumed user groups, perhaps doing research to validate underlying assumptions.
  • Interaction designers, information architects, etc. can begin wireframing the major interactions in the system to get an idea of what kinds of UIs will facilitate the desired interactions.
  • Stakeholders & project managers can get a high-level view of what the application does and what interactions will need to be built to make that happen.

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 design.

Further Reading

Write for UX Booth

Contribute to UX Booth

Contribute a guest post to UX Booth and let the community know what's important to you!


  1. This is a great article Andrew. Great information here and written so well. Thanks!

  2. 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.

  3. 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.


  4. 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.

  5. 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.

  6. Thanks guys for the feedback. I’m always tweaking the formula to have design preempt development without making the process resemble waterfall.

  7. 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.

  8. Thanks a lot for this interesting article.

  9. @deholandadesign October 26, 2009

    Awesome! Great information that designers should know. Thanks.

  10. 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 :)

  11. 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.


    • 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!

  12. 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:

Related Posts