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