Part 2 of how I work, describing the practices I’ve used throughout my career.

Photo by Austin Neill on Unsplash

Menu of activities

For design projects, one or more of the following activities might be appropriate. For some of the most ambiguous and high scale projects, all of them might be necessary.

Audience research

  • Data analytics, directional A/B tests
  • Polling, interviewing, focus group
  • Persona creation/alteration

Problem and solution definition

  • Taxonomy and terminology
  • Content and design strategy
  • Feature and journey maps

Idea gathering

  • Trending patterns research
  • Charrettes and Design Studio
  • “Gut testing” for look and feel


  • Wireframing
  • Mockup or prototype creation
  • In-code design

User testing

  • Automated user testing
  • Interview user testing
  • Functional A/B testing


  • Design system, style guide, pattern library
  • Coding standards

Audience research

Data analytics, directional A/B tests

No matter how much experience I have with a subject or an audience, I’m always hungry for data. Behavior is conditional and whether you’re searching for a problem or a solution—the answer can frequently be found by looking at data on hand. That may be from traffic, click/tap tracking, tests, polls, or otherwise. If it’s there, I want it. If it’s not there then we need to start recording it.

Polling, interviewing, focus group

With some types of questions, just asking people is the best way to get answers. Qualitative info can’t do a lot of things but it is great at getting sentiment, gut reaction, “why”, and “what would you expect to happen if you tap this?” about your product.

Persona creation/alteration

I make personas specifically for Experience. Often they’re made either for Marketing or Sales but those don’t contain the info I need for a product team. I focus on motivations and personality quirks — things that make them seem enough like real people that my team can make similar predictions about preference and understanding. I prefer to inform them with trending data but I‘ve also based them on team assumptions.

Problem and solution definition

Taxonomy and terminology

With all new and larger projects, defining this early can save a ton of money down the road in bug fixes and re-writes that never need to happen. Why? Because probably around 80% of what software engineers do all day is name things. If I come to them with loose idea of what everything should be called and files named oddly, they’ll default to writing code in either an overly generic or specific way. When things get better defined or rebranded later on, that usually only gets applied to the new code they write, because #fast-paced-workplace. They then have to mentally translate between the new and old names of things across areas of code. The result in that common case is a giant mess of code that is rife with bugs because it’s such a fertile ground for human error.

Content and design strategy

A lot of the experience of a thing is a product of its tone, look, and feel. Sometimes it’s up to me to define that and other times it’s a collaboration. Either way we need to be running in the same direction with regard to the strategy because otherwise it can easily appear tone deaf to our audience.

Feature and journey maps

Having really gotten into these with my Agile work, I find them to be really great for strategic negotiation and planning on larger efforts. I’ve also added my own secret sauce in the form of MVP ➜ MLP ➜ RVP ➜ RLP. For anyone who hasn’t seen feature and journey maps, they generally look like this:

Idea gathering

Trending patterns research

This can be finding patterns in unrelated realms or “competitive research”. In either case it’s about finding insight out in the wild. I’m a big proponent of cross pollination from seemingly different industries and fields. The more I’m exposed to different information, the more connections I make… kind of like A Beautiful Mind but without the schizophrenia (I hope!).

Russel Crowe as John Nash’s imagination in Universal’s film

Charrettes and Design Studio

On projects where I need a lot of buy-in, I find it best to facilitate group activities where stakeholders materially commit to aspects of it. That way, differences of opinion can get ironed out without playing telephone and everyone feels more ownership in the end result. Besides guiding the session, this leaves me free to maintain focus on my design/po concerns.

“Gut testing” for look and feel

What’s more efficient than doing work? Showing other people’s work.


Describing what to build often comes in the form of a document—either static or interactive. I favor creating documents that are open, light weight, and version controlled for the following reasons:

  • I’m not a bottleneck because anyone on the project can add to my documents.
  • Good ideas don’t get lost in edits.
  • Rolling back changes and removing mistakes is easy.


To me wireframes should be low fidelity. The focus should be on the information architecture and avoid anything shiny or pretty that could distract the team from making good decisions about what elements should be promoted and what flows contain the best balance of elements. In times when my teams or stakeholders do not process wireframes well, I use something else like conversational sketching or jumping straight to mockups.

Mockup or prototype creation

Often these are a great tool to communicate a design but not always. It’s important that I keep an eye on the point of diminishing returns: Is the work I’m doing to mocking up or prototyping this feature actually saving the team time and money—or is it creating a lot of work with no business value?

In-code design

Sometimes it’s more efficient or effective to design in whatever the development environment is (html, an SDK, etc.) to communicate the design. In the case of what I call Live Design then this can be the same work that ends up being checked into the code base and shipped.

User testing

In the presence of too many good ideas, something has to be done to pick a single way forward and trials are often the answer. If the infrastructure is available, I prefer to test in three different ways:

  • Comparative cohort tests
  • Impromptu testing (great for options that might have otherwise slipped through the cracks)

Automated user testing

People will always behave differently when they know they’re being watched but if you’re testing for the right thing, it can still be quite valuable. I’ve also had a good deal of success with screening questions, so participants can self-select into tests where they really do have some interest in what you’re showing them. It’s also quick. Within an hour I can often run a dozen testers through a concept or page and get results.

Interview user testing

When I need to test in a more open-ended or freeform way, interviews in an individual or focus group setting are appropriate. It’s a lot more coordination to set up and conduct but the insights can be more personal and take the tests in directions I wouldn’t have predicted.

Functional A/B testing

“User unaware” testing of 2 or more options in your product, particularly at scale, is a powerful tool for optimizing design options. It’s also the safest way to deploy changes. The results are as real as you can get and they’re especially valuable when contrasted against qualitative user test findings.


Design system, style guide, pattern library

Pattern libraries can save a lot of time and fragmentation. While static versions are still useful, they’re really best when “live” and tied to the code base. Being able to ask a developer for “this widget (a named component) with this modification (light-weight design)” is a goldmine of streamline. It means wheels don’t get re-invented by accident, designs are consistent across teams, and the product itself can be consistent across teams.

Coding standards

Collaboration speed gets better when developers agree on structure, flexibility, and how self-documented code the is. This is another aspect of internally-facing experiences that are both important to me and beneficial for my team. I’m able to be more helpful when pairing and they’re able to deploy with less chance of bugs. Keeping people out of silos and able to pick up each other’s work at any time is incredibly valuable for highly capable teams—and those are the teams I most like to be part of.

Experience Designer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store