Mike Heavers

Before getting started I try to establish a mutual understanding with key stakeholders about what problem we're solving, who we're designing for, and what the working arrangement will be like. To help establish that, this Service Definition Worksheet, from the book "Lean UX", is helpful to me to establish those.

I then like to establish a scope of work and a timeline. My experience is primarily in small, collaborative, cross-disciplinary teams using Agile methodologies, with sprints of 2 weeks that start with outlining goals and responsibilities and addressing concerns, and end with a retrospective on how to improve and adjust.

Clarifying what we already know and what has already been attempted is important, in order to avoid reinventing the wheel. Looking at objective metrics, like data summaries, is helpful.

IDEO has a great Design Thinking Toolkit that helps in the Inspiration, Ideation, and Implementation phases of a project. A good start is to talk to people - the audience, experts, and people from analagous fields who might reveal unique insights.

One of my favorite parts of a project is the idea generation phase. Getting a bunch of people in a room to brainstorm everything from the obvious to the impossible, then throwing those up on a wall, grouping them, finding themes, and culling them down to something we're excited about and feels relevant.

You can't solve all the problems of all of the people all at one time. I find it helpful to identify key user personas, and try to imagine what their experience might be. Or better yet, ask them to imagine it themselves.

Once the problem is clear, we start to think about how that user journey applies to what we're building, via low-fidelity user-flows and wireframes.

On the design side, mood boards and reference imagery helps keep us excited and gives starts to give visual shape to all that data.

While thinking about design is helpful, I find a common tendency is to want to embed that in the UX, but at this stage its important to keep wireframes low-fi, in order to keep the focus on the concept, and not the design. This makes things easy to understand, change, and avoid deliberating over stylistic preferences.

Where it makes sense to help illustrate the implementation, or make the abstract more clear, higher fidelity wireframes start to emerge.

With physical components, I almost always build schematics, then workable code "snapshots" that build out the simplest functionality first, creating a record of the evolution of functionality over time. This makes it easy to step back where the need for simplification arises or unexpected complications emerge.

I love when projects allow for something tactile. Screens are amazingly effective, but once things gain physicality, you can really appeal to the five senses.

At right, a low-fi sensor based prototype and app using arduino, react native, and laser-cut foam core, dubbed the Christmas for its stand and red white and green wiring.

When designing for environments, I often create a simple systems diagram that quickly helps to indicate where components sit in the space and how they interact.

Visual renderings of the physical space help think through scale and feasability.

By this point it can be easy to get tunnel vision, which is when it's helpful to get things in front of the potential audience. You almost always discover that they use things in ways you never expected, uncover issues you never thought of, and provide input that makes things incrementally better.

Afterwards, you can start to summarize key learnings.

The last step is the first - take what you've learned, figure out what your next goal is, and repeat the process.