“Checklist Thinking” for UX Professionals: Retaining your sanity in a complex project

A few years ago, we were working on a complex business-to-business ordering website. We never seemed to be able to leave the wireframe stage and move onto development. The “discovery” of new requirements seemed endless.

Related posts:

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)?
User Stories

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.

Sample ScenarioSimplest Option

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.

Greg Laugero

Greg Laugero is a digital product strategist and Co-Founder of Industrial Wisdom. He helps companies turn their ideas into real products with great user experiences. You can follow him on twitter: @prodctstrategy.

17 comments on this article

  1. LG on

    Nice post, thoughtful and insightful.

  2. Kathryn on

    Love this post. I can literally see the clouds parting and hear the angels singing. This is a great, consise way of explaining how all of the deliverables fit together.

  3. Totally agree with this type of thinking, checklist thinking is very useful for complicated projects and can be extracted & extrapolated into smaller and smaller checklists.

    A great example is the Experience Design Framework I created & implemented at a few big agencies. You can see the checklist/ process here:

    http://www.slideshare.net/thejordanrules/experience-design-framework

  4. Nice article, but what you’re describing is essentially requirements traceability – a well-known notion in software engineering and business analysis.

    It would be helpful (and more honest) if you referred to it as such, rather than making it seem as though it’s a concept you’ve invented by using buzzwords like “checklist thinking”.

  5. Pingback: Best thing I’ve read recently: Checklist Thinking for UX Development « Xun and Interaction Design

  6. Pingback: “Checklist Thinking for UX Professionals” on JonnyHolland.org | Industrial Wisdom

  7. Pingback: Användbara länkar v. 18 | Samir Fors

  8. Gaby Prado on

    Nicely put. However, in the middle of all that, the site in question has endless amount of content which needs to be organised before presented to the user. Oh, and need to throw in taxonomy, controlled vocabularies (assuming you too consider AI to be part of the UX universe).
    How do you see these activities fitting in your scheme?

  9. Pingback: NextDigest Design – May 6, 2011

  10. Nice article. I use checklists for just about everything but I enjoyed reading how you are using them in such an integrated way to tackle requirements gathering and seeing that all the macro and micro pieces fit together. You’re using them to achieve an overall alignment. Good stuff.

  11. Martin on

    Great abstract but where’s the article?
    You put into words a very important and at times frustrating part of our work – the need to coordinate expectations between us and the client.
    I couldn’t agree more with the general concept of the article, but I wish you elaborated more:
    * what exactly comprises a good scenario?
    * how can we assist the client to deliver clearer requirements?
    * what comprises a good use case and how does it differs from a scenario?
    * what’s the advantage of flow maps? why not just go from use case to prototype?

  12. rob on

    Hi, just wondering what software you use to create your documentation and charts? It looks fantastic.

  13. Pingback: Обзор свежих материалов, апрель-май 2011 « Юрий Ветров. Проектирование интерфейсов и управление проектами

  14. Pingback: Обзор свежих материалов, апрель-май 2011 - Бламаблум

  15. Pingback: Managing Complex UX Deliverables « jpreardon.com

  16. Pingback: Checklist Thinking for UX Professionals « Greg Laugero