Bringing sanity to swat-team design projects
In a perfect world, interaction design would begin when a product was still just a twinkle in a venture capitalist’s eye. In reality, many software products make it all the way through the development cycle with little thought to the users’ experience, and when executives, sales people, or QA testers finally get their hands on the functioning product and start sounding the alarm bells, interaction designers are brought in to clean up the mess. With increasing demand for design “swat teams” to rescue fully developed but flawed software that is scheduled to ship within months or even weeks, the critical question becomes: how can you avoid getting caught up in the chaos that frequently permeates “crisis-mode” engagements?
Making Goal-Directed Design work in swat mode
Following a tried-and-true process is one of the best ways to ensure that you can stay focused on your design effort (rather than getting bogged down with project management tasks) and deliver a consistent level of quality regardless of the length or urgency of the project. We talk a lot about process at Cooper, and for good reason: earlier in our careers, most of us learned the hard way that it’s nearly impossible to consistently deliver good results without taking some kind of structured approach. But that structure needn’t be so rigid that we can only help product teams who have the time and budget for a robust, months-long design project. The key to delivering successful short-term, swat-team engagements is to retain the basic structure of the Goal-Directed Design process, while adapting it to the situation at hand.
At the highest level, the Goal-Directed Design process is comprised of three major phases: problem definition, framework design, and design refinement. When time is tight, there’s a strong temptation to roll up your sleeves and jump straight into detailed design. Don’t. Diving into detailed design without doing the necessary foundation-setting work is every bit as perilous as diving into development without a clear design. So when you have to cut corners to accommodate a tight timeline, condense steps in the process, but don’t eliminate them.
Once you understand the objectives that lie at the heart of Goal-Directed Design, you can customize it to fit your next swat-team project by taking (you guessed it!) a goal-directed approach. I’ve provided some suggestions below, but you’ll want to re-evaluate tasks throughout the process and make changes, additions, and deletions as appropriate for your organization - just be sure that as you tinker, the spirit of each phase remains intact.
In this first phase of a project, we define the problem that must be solved by the product. The key here is to ensure that designers and stakeholders are in agreement about:
- The business and technical issues that are driving and constraining the project
- Who the users are (including how they think and behave, and what their goals and contexts are)
- The high-level requirements that emerge from those insights
Each of these factors will heavily influence your design, so it’s critical to directly address them up front so they can be discussed at the conceptual level, divorced from any particular design solution. Uncovering a fundamental disagreement about core principles while presenting a refined screen drawing results in exactly the sort of churn you can least afford in a time-crunched project.
Making it work in swat mode
While the activities in this phase typically span a month or two in a classic project, they also lend themselves very well to time-compression. Within a few days to a week’s time, you should be able to:
- gather information on users
- assemble a small set of provisional personas
- develop a common long-term vision through aspirational context scenarios
- describe an improved but immediately achievable user experience through near-term scenarios
- define high-level requirements that emerge from the near-term scenarios
When time and money are tight, research is often the first thing to go. But given that every design decision you make will be informed in part by your understanding of the user population, it’s worth making time to talk to even just a few users to ground your thinking. If possible, dedicate at least one day to talk to users on the phone, and ask stakeholders and subject matter experts to share their understanding of users as well. Armed with these insights, you can quickly develop some provisional personas which, while not based on definitive qualitative data and therefore not as powerful as real personas, are still useful tools to clearly communicate assumptions about who users are and what they need, and to focus and guide your design.
Next, explore key scenarios describing the personas’ ideal experience interacting with the product. While you’ll likely not be able to achieve this level of user delight in the current release, it’s important to make sure that designers and stakeholders agree upon the ideal experience, so that the design improvements you can make in the short term aim to get as close to it as possible given the current constraints. You can then step back from this ideal experience and develop a less aspirational set of scenarios that describe the best user experience that can realistically be achieved in the short term, and map out the corresponding requirements.
The goal of the framework phase is to define the design structure and flow. To accomplish this, we explore design ideas with increasingly detailed and varied scenarios, drawing solutions in a low-fidelity manner without specific detail, and sharing them with stakeholders as early as practicable so that our approaches can be vetted and adjustments can be made quickly and easily. Once designs are rendered in pixels, changes to the underlying design framework become time consuming and costly. By working through these foundation-level design decisions while they are still easy to change, designers and stakeholders alike can stay focused on the fundamentals: ensuring that the overall design serves the personas’ goals and requirements.
Making it work in swat mode
Often in swat team projects, the software has been completely (or at least almost completely) developed, and some foundation-level features of the application (such as the overall navigation structure) can’t be modified. That’s no reason to skip over this phase, because its rough and sketchy nature empowers you to produce time-saving, low fidelity drawings that are incredibly useful tools in time-compressed projects. Even if your design changes won’t impact major structural elements, there’s plenty of design work that should be tackled at a framework level. Before you commit anything to pixels, take some time to quickly assemble hand-drawn sketches of scenarios that:
- Communicate key concepts
- Step through state transitions
- Demonstrate the flow of specific interactions
If you discuss and gain consensus around design changes at the conceptual level up front, you’ll be well positioned to execute them quickly and efficiently in pixels during design refinement.
While in a classic project we typically recommend rendering sketches in pixels as the framework progresses (using a visual style that communicates the sketchiness of the proposed solutions), this is a good example of a step that can be omitted for swat team projects where the basic structure of the product will remain unchanged.
This is the detailed design phase, where we tackle the nuts-and-bolts refinement of behaviors, form, and content. Designs are rendered in pixels, screen elements and interactions are documented in text, and scenarios are fully illustrated. These activities serve two critical functions:
- Fully exercising and validating the design (because the true test of a design comes when it is rendered in pixels and described in words)
- Clearly documenting the design for the stakeholders who must approve it and the developers who must build it
Making it work in swat mode
One challenge with swat team projects is that the development team needs the most detailed and precise screen renderings and documentation in order to immediately execute on your recommendations, but you’re working with considerably less time to produce these materials. The key is to vary the level of detail according to the complexity and priority of the design topics. Work with developers to determine which behaviors must be specified in detail, which they feel comfortable building from a more shallow specification, and which specifications they need first. Setting up a shared and living document to house the interaction specification is the best way to ensure that everyone is working with the most current information, and that communication is flowing freely between the design team, the development team, and project management.
Structuring a successful swat-team project
Because you’ll be working quickly, with limited (if any) research, your analysis and design work is guaranteed to not be perfect. Your stakeholders and subject-matter experts will be key partners in helping you test out the validity and feasibility of your work and identify any flaws, so be prepared to share materials with them early and often (even daily, on very short projects), and make revisions based on their feedback.
With each phase of the Goal Directed Design process, you build consensus with stakeholders and narrow the scope of issues that can be in dispute in each subsequent phase. To borrow a term from the world of pickup artists, each phase walks stakeholders up the “yes-ladder,” increasing the likelihood that they will respond positively to detailed design decisions because they are based upon already established and agreed upon beliefs about users, scenarios, and basic design concepts and flow. Particularly when time is tight, steadily building this common foundation across designers and stakeholders is critical to keeping the design effort on track and avoiding churn, rework, and delays.