A few things I believe about design & process.


  1. Designers are at their best when they function as a lens, focusing the needs of the business and its customers.

  2. “Genius” design (vertical expertise) has its place, but doesn't scale.

  3. Designers should work in public, and should actively seek out ideas from all corners of the company.

  4. Designers should know how to say no, how get their work in front of customers as quickly and easily as possible, and how to iterate and improve upon their work.

  5. Designers should always be looking to communicate better, remove friction, and improve outcomes with their work.


My Process


Framing the Problem

  • Frame the project as a user problem
  • Define a measurable success outcome
  • Determine personas
  • Collect insights and ideas (Maybe a design sprint or maybe customer & stakeholder interviews)
  • Build a story map
  • Define a minimum deliverable that can generate useful feedback
  • Establish a project journal to document decisions along the journey

UX Sketching

Consider potential solutions across several contexts:

  • What's the:
    • potential business impact?
    • cost/complexity to develop?
    • potential customer delight?
  • How does this fit within the existing information architecture?
  • Are there engineering/development considerations?
  • Can project scope be constrained to ship quickly?
  • How will the feature be user tested?
  • Are there analytics in place?

UX review

As soon as the initial problem has been scoped, and wireframes created to illustrate possible solutions, the project should move into UX review, a conversation where the team examines whether the work:

  • Is thoughtful? Does it meet needs of personas, does it follow established design patterns, are success metrics defined?
  • Is the deliverable correct? Has a story map been created? Is a prototype required? Are there special testing needs?
  • Are the right collaborators and stakeholders involved? Is there another project that might impact this one?

Prototypes & Testing

Once the wireframes are vetted, they should be prepared for testing/feedback. This can happen in many different ways, but typically a prototype or screens are prepared and tested either with a remote testing service or through in-person interviews. The goal here is to uncover major flaws and issues so that the flow can be refined. Whatever the process, it should be fast and easy to integrate into the teams' workflows, to ensure research is being done early in the development process.


Development

Typically, the designer will follow a project into development, helping the product manager remove roadblocks and answer developer questions, to ensure the expected experience is what's being delivered. Communication is key here, as well as the recognition that design is a team sport (meaning everyone on the team contributes).


Design Tools

A selection of sketches from a recent design sprint we ran.

Design Sprints: I really love the process of digging into a problem and generating lots of solutions with markers and sticky notes. It's fast, easy, and inclusive. These work best when there's a variety of perspectives in the room. Again, Design should be a lens, focusing the input from individuals across the business.

We use a lot of sticky notes in our workshops.

Story mapping: Again with the sticky notes! Story mapping is a great way to prioritize elements of a new feature with the user in mind, so you can get to a "walking skeleton" — the most basic, complete version of a feature — faster.

Personas: These are critical to the product design process. They should be based on real customer data, and as fleshed out as possible. They can always be "more" real and "more detailed", but it's most important to have them in everyone's hands, guiding design decisions.

Empathy Maps: We've been exploring empathy maps as a way to distill user interviews into major themes that influence a particular product context. These help give the personas life, as the empathy map details what a persona is thinking, seeing, feeling in a situation. We're hoping these will be more effective in guiding design.

I like testing flows and interactions in simple prototypes.

Prototyping: These days, I think prototypes are invaluable for communicating designs. I have used simple Invision-style prototypes for linking mockups into a flow; FramerJS prototypes for exploring interactions, animations & movement; and fully interactive Web prototypes for testing with users. It all depends on what stage the design is in, and what questions need to be answered. Typically, it's the simplest prototype that can answer the questions at hand that determines what gets built.

User testing: I'm a big fan of the ease and quick results of remote user testing. I need my team delivering results, not wrangling test participants. I also really love beta testing new features with small subsets of real users. With continuous deployment and 'feature flipping' functionality, getting real data on how new features perform with small groups of real users is very easy. For fast, quick-n-dirty results, testing within in-house employees or recruiting in a coffee shop can deliver good results easily when you've got a prototype that requires moderated testing.

User research: I'm also excited for a future with more resources dedicated to UX research. One of the most transformative activities you can do within a team or organization is increase everyone's exposure to users. Seeing feedback and frustration tends to radically change everyone's focus and perspectives — I've watched stakeholders go from focusing solely on their own opinions of a design to prefacing their comments with, "let's be sure and test this with members". And truth be told, there's a lot lost in the one-way conversation of remote user testing. Being able to guide the conversation in a new direction often uncovers surprising new insights to inform personas.