Here’s how it went as we reviewed the designs for the shopping cart with the client:

Stakeholder 1: What about when the customer realizes they are purchasing using the wrong contract? Can they change it here?
Designer: Not in this design. Is that something that they should be able to do at this point?
Stakeholder 1: Yes.
Designer: But then their prices will change. Right?
Stakeholder 1: That’s right. And they might have products in the cart that they won’t be able to buy on the new contract.
Designer: [internal dialog] #$%!
Stakeholder 2: What about the ‘prompt pay discount’? I see ‘discounts’ but does that include prompt pay?
Designer: What’s that?

It’s common knowledge (or it should be) that discovering requirements during page design  is a recipe for madness. But no matter how much we believe this and strive to avoid this, it still happens. We’ve come to terms with the fact that it’s quite natural for clients to recall an infrequently-used feature or edge case when they see a page design. In this case, it’s easy to blame the customer for not having their requirements defined and communicated. Surely, we’re the victims here.

The reality is that the problem is ours. We rush into the creative process without fully understanding everything that our solution needs to do. If we are going to be successful, we need to figure out how to hold our creativity accountable to the full demands and scope of these complex projects. Unless we take the lead in defining the full scope of these projects, we will never be successful.

Checklist Thinking and Accountability

Last year, one of our clients mentioned to me Atul Gawande’s “The Checklist Manifesto”. She was reading it for its insights into health care. My insight was this: for our creativity to really deliver a solution, our deliverables cannot stand alone; they must work together as a related set of checklists. “Checklist thinking” makes the complex, enterprise-wide digital systems we work on much more manageable.

At my company and with our clients, I talk a lot about deliverables being “accountable” to other deliverables. I’ll use an example. In an Agile process, everything that takes place in a sprint is referenced back to one or more user stories. Our page sketches must address all of the user stories in the sprint. In other words, our sketches and page flows are held accountable to these user stories. Similarly, many software projects involve some listing of requirements. User stories should be held accountable to those requirements.

Checklists enforce accountability among deliverables. Framing our deliverables as checklists helps us do three things:

• First, we can lead our customers through the process of defining the full scope of complex digital systems.
• Second, we can hold our creativity accountable to everything required of the solution called for.
• Third, we can hold the customer accountable to their inevitable changes. We can always go back and say, “That’s a new user story that we haven’t discussed. Let’s get that on our list.”

This accountability allows our creativity to be truly effective.

Types of Checklists for Complex Digital UX Projects

A checklist can take many forms, but there are five that we find crucial for ensuring that design projects don’t spin out of control and that stakeholders and customers are held accountable to their earlier decisions.

Checklist #1: Scenarios
Checklist #2: Business Requirements
Checklist #3: Use Cases (or User Stories if you’re using Agile)
Checklist #4: Flow Maps
Checklist #5: Wireframes (or prototypes or sketches or whatever you use to define what happens on a page)

These are not new deliverables, and some of them are certainly not typically the domain of the interaction designer. Nonetheless, the trick is treating each as sequence of checklists and not just an exercise in siloed documentation or your own personal creativity. For example:

• Do the requirements (checklist #2) account for all of the scenarios (checklist #1)?
• Do the use cases (checklist #3) account for all the requirements (checklist #2) and scenarios (checklist #1)?
• Do the flow maps (checklist #4) address all of the use cases (checklist #3)?
• Have I created all the required wireframes or page prototypes (checklist #5) reflected in the flow maps (checklist #4)?
• Does my prototype (and any associated documentation) illustrate all the use cases (checklist #3) and scenarios (checklist #1)?

Key to success is public visibility of the connections among deliverables. For instance, when showing page flows, start by showing the user stories as a setup for the flows. Or if you are developing user stories, start by reminding everyone of the personas and scenarios. This ensures you have the best chance of making sure the next deliverable is as complete as possible. You also can more readily identify new scenarios, requirements, and user stories without feeling defensive, or like you missed something. If you’re doing this right, you should start to hear your clients say, “This sounds like a new user story!” when new functionality inevitably comes up.

Final Thoughts

The work we do does not yet have a clear place in the well-worn processes of complex digital systems. Others will not define it for us. We have to do it. Embracing the art of the checklist means figuring out how our deliverables fit with others. Treating deliverables as checklists for other deliverables is one way to ensure that what you do not only addresses the work that came before, but will inform and shape the work that is yet to be done.

These checklists are method-independent. If you’re doing waterfall, then use them for waterfall. If you’re doing Agile, then integrate them into your sprints. Checklist thinking allows you to slip into any of the reputable software-development methods without being “certified” in any of them. Checklist thinking keeps you focused on 1) what your deliverable needs to cover to be complete and 2) what your deliverable will be used for downstream.

In our previous article, we focused on the first step to developing a User Experience (UX) strategy by presenting how user stories are generated, themed and prioritised, as a means of helping us to understand the shape of the project (what) and its purpose (why).  In this article we focus on the use of scenarios and paper prototypes to support a rapid and collaborative exploration of potential implementation approaches (how).

An Approach to UX Strategy

The goal of the strategy phase is to ensure that all stakeholders are similarly focused and aligned around project goals, i.e there is agreement in principle about the purpose of the project and the priorities for implementation.  A high level agreement to what the project is, why we are doing it, and how it will be achieved reduces the risk of budget blow outs or conflicts in the design phase by ensuring that all project stakeholders have similar expectations. In addition, it is only through an understanding of the scale and complexity of the project that the design team can accurately, or at least confidently produce a budget or estimate for the project.

Our approach to the development of a UX Strategy is motivated by three interrelated, pragmatic and theoretical drivers:

1. Firstly, getting the client team on board and in agreement during the strategy phase relies on these stakeholders having a shared understanding and vocabulary. Tools like scenarios and prototypes help to externalise issues and make them available for shared conversation.
2. Secondly, they also allow the project team to collaboratively and rapidly investigate options and expose constraints. The tangible and visual nature of these tools allows us and the client team to think, explore and discuss the potential project in a more concrete way by grounding conversations about the project in its context of use. This ensures decisions about approaches and priorities contained in the strategy are appropriate to the opportunities, boundaries and constraints of the particular project.
3. Finally, the third and perhaps most important reason is that tools like user stories, scenarios and paper prototypes frame the discussion about the project strategy from the perspective of the user experience. Doing this collaboratively is an opportunity to expose, explore and align the various agendas and perspectives of stakeholders and work through how they might come together in design. As a result clients are better able to understand the implications of project objectives and priorities, and refine them based on the impact this will have on the potential user experience.

From User Stories to Scenarios

Any of the high level user user stories generated as part of the early strategy phase could be implemented in any number of different ways. Different approaches to implementation will require different levels of investment and be more or less appropriate given the project context and constraints. So, once a list of user stories has been developed (as described in the first article) the next step is to identify the key scenarios. The intention is that by fleshing out a few specific key scenarios (combinations of user stories) during the strategy phase, it is possible to expose enough detail about the nature of the website that we can agree in principle to an approach with a shared understanding of where we are investing our time and why. In our experience fleshing out 4-6 scenarios will allow us to explore enough of the key aspects of the site/application. If not, then this is a sign that the project may need to be divided into smaller phases.

The intention of doing this work is not to find the solution or define the architecture per se, but rather to explore possible approaches and agree on an appropriate UX Strategy. We also hope to expose risks or contradictions between expectations and constraints (e.g budget).

… by fleshing out a few specific key scenarios (combinations of user stories) during the strategy phase, it is possible to expose enough detail about the nature of the website that we can agree in principle to an approach with a shared understanding of where we are investing our time and why… to explore possible approaches and agree on an appropriate UX Strategy.

Selecting Key User Stories

The user stories fall, more or less, into two categories. The first are that those that are simple, familiar or unambiguous enough that we can feel confident about budgeting them and resolving them as part of the design phase. These might include user stories that use common UI patterns that we are familiar with or that we have resolved many times before. The second group are more like ”black holes”. By that we mean ambiguous, complex or particularly unique to the project; if not better understood they will pose a risk to meeting deadlines or timelines in the design phase. Our goal is that by the end of the strategy phase we can a) be sure that they can be implemented and b) put a cost against them.

The process of fleshing out this latter group in more detail allows the scope and nature of the project to emerge through a focus on user experience. At the same time it exposes and challenges some of the assumptions and expectations held by stakeholders, or embedded in existing documentation.

The following is an example of a key scenario from the redesign of a university website:

As a potential student I can find out about the application process, find an available supervisor and apply.

This scenario is derived from these user stories:

• As a potential student I can find out about the application process
• As a potential student I can find an available supervisor
• As a potential student I can apply to study

The example scenario above was chosen because it represents a complex pathway that would be completed by a potential student over several weeks or months. Walking through such a scenario forces us to explore and confront a number of strategic, political, technical and user experiences issues.

Mapping out scenarios as user pathways

Once the key scenarios have been identified and agreed upon with the client, they are mapped out as user pathways.

Initial pathways are generated using a walkthrough process represented by post-its. We take each scenario and ask ourselves what would we would need to provide in order for that scenario to be achieved. We have to hand personas, business objectives, content examples, accessibility guidelines, and any relevant technical specifications to assist our decision making about how people might proceed and what they might need to do so.

Each step gets a post it/sketch to represent it, as shown in the image below. We aren’t working at the level of pages yet, just creating a trail of things that would need to exist in order for it to be possible to fulfill that particular scenario. This process allows us to think about the experience as a dynamic thing that happens over time.

Mapping Pathways

Analysing pathways

All the scenarios are mapped out in the same physical space and in relation to each other. If there is some cross over between the scenarios then that is shown physically by an intersection in the pathways.  It is likely that the pathways of earlier scenarios may have to be adjusted in response to what emerges out of the later scenarios. It is an iterative process and depending on the scale of the site, might take a few days to complete. In the image below, intersections in pathways were exposed via clusters of different coloured post-it notes.

Identifying Pathways

Rather than exploring or defining the approach to design or user experience from the perspective of features, this process allows the shape of the site to emerge through an exploration of user activities. Particular patterns about potential use can then be identified, which feed back into the strategy development process. For example, we are able to see that particular areas of the site, or pieces of content contain information relevant to most stakeholders, while others have value for only a small number. These patterns can inform decision making about priorities for the site and help clients to come to agreement in principle on approaches to various aspects of the project, including where time and money is best spent in the short term.

Drilling down through prototypes

Visualising the user pathways also reveals underlying technical and content needs and raises questions around feasibility, content and functionality. In some cases the issues and questions raised are better understood at a more granular level, i.e how they impact on specific interactions via the interface. Paper prototypes or mock ups are then used to rapidly drill down into these “high risk” areas. The image below displays an example of a paper mock-up used to explore possible ways of supporting a searchable index of university scholarships.

Sketch Prototypes

Seeing the potential user experience mapped out in this way provides the client with a different perspective on the project and this allows them to discuss the project the different ways. For example, this process will  expose how a scenario or user story, currently prioritised by the client team translates in design into a potentially very complex requirement, or requires the availability of a certain set of content not currently available. It can expose tension or conflict between a priority objective and what it would actual take to make that happen.

Often at this point, project realities begin to sink in and project teams are forced to realistically assess what could be achieved in the allocated time frame and budget. The visual pathways, mock ups and paper prototypes become visual and tangible aids to explain the issues and options, and support discussion, negotiation and resolution about appropriate approaches and priorities. We have found this technique is very effective for generating and supporting constructive discussions with the client when decisions about priorities are needed. The client has the opportunity to understand the impact of various decisions and requirements about technology or content in relation to the user experience. This supports the development of design principles and guidelines, and helps clients come to an agreement on approaches to particular aspects of the site or application. It can also lead to a revision or shift of emphasis for the project objectives.

The process of thinking through actual prototypes provides these stakeholders with a new way of seeing and new language for describing what is most important. As a result the client team is better placed to decide and describe the most valuable outcomes and confidently direct resources towards the most important elements of the project.

Summary

Creating an effective User Experience Strategy requires the alignment of perspectives such as technical, business, content and brand with that of the user experience. In this article we have described how we support clients to develop a User Experience Strategy that takes into account all these perspectives, based on an understanding of how it will translate into design.

We believe that a core part of developing a design or User Experience Strategy is about interpreting how ‘abstract’ business goals are translated into a specific design project. Scenarios and prototypes are light weight, visual tools that can be used to assist clients to rapidly envision the potential experience for users. They bring a tangible quality to conversations that can otherwise be ambiguous, allowing team members to collaboratively think through project goals and approaches to implementation. They force us to deal with the concrete issues of use in situ, provoking and facilitating critical conversations about overall strategy, opportunities and constraints prior to moving into the design phase. Most importantly they frame questions and decisions about functionality, brand, content and technology in relation to the impact this will have on the potential user experience.

As designers, we deal with users perspectives and the concrete situated issues of use as part of our daily practice. These collaborative tools enable the user perspective to sit at the centre of the discussion and decision making for our clients as well.

Acknowledgments
The reflection on methods outlined in this article was largely made possible through project work completed on behalf of Digital Eskimo, a social design agency in Sydney whose Considered Design methodology makes embracing these methods and approaches possible. We would also like to thank our clients UNSW, Melbourne Journal of International Law and Inspire Digital and our project partners Zumio and Redrollers for their generous commitment to sharing the design experience and process, and to all the participants who give time to our projects.