On Data Driven Design

Lately I’ve began to really internalize the importance of utilizing data on current, expected and optimal usage patterns during any re-design or user flow optimization phase. When doing a redesign, design-driven decision making means looking at what is happening on the site today in order to inform where the product goes tomorrow:

  • Make the optimal usage patterns the focus of the user flow (during onboarding, critical actions, or any phase really)
  • Subtly suggest and drive users into new/more desirable usage patterns, if the current ones don’t align with the larger goals

This is easier said than done. Before we even start, we need to answer these (and more) questions:

  1. What is the current most common user flow, is it optimal > if so — why?, if not — why not?
  2. What are the current barriers, or most common blocks in the flow?This could take the form of drop-off points, bounce points, points where users spend unnecessary time and/or cognitive load making decisions about how to continue, etc. The goal should be simplicity and value driving the user forward
  3. Based on business and design objectives, is the current flow satisfying the companies needs? Will it cause too much friction to change? How necessary is any major change, and is a minor change worth the time and effort? Basically, is it a nudge vs. a push.
  4. What does the new flow, if any, look like, what are the mechanics, who and what does it involve (marketing, email design, content, etc.)? What is the key metric you are optimizing for (activation, retention, etc.)?

When we talk about the new flow, it’s not always purely visual but rather in terms user movement at first. Is any proposed change significantly different than what the user is doing today? Will it cause friction to switch? If so, how much?

Once that has been determined, visually and structurally, what changes are required to facilitate the new method(s) of interactions?

Now the design can begin, with:

Putting something down on paper > wireframe > user testing > mockup > user testing > design > user testing > code > user testing > redesign > user testing > coding & debugging > user testing > cohort analysis > A/B testing > Metric tracking > Final deployment (woohoo!)

Obviously small companies and teams that need to move fast (cough us cough) will need to short circuit this process a bit, the long development cycles and continuous testing are luxuries afforded to larger teams with significant development and design staff(s)/capabilities, but even small startups can implement something like:

Paper > Wireframe > Small team testing > Mockup > Small user survey (via a newsletter or incentive, depending on scale of design) > Design > Small team internal testing > Code & debugging > Launch

The core idea is to use the current data and other heuristics you have collected to inform the decision making process as opposed to simply choosing new designs, flows or features because they look pretty or because you are getting bored of looking at your old design.

Boredom in design doesn’t necessarily breed contempt. In many cases it breeds familiarity and affection (RIP the old Instagram logo).

Changes designers like to make because it “refreshes” the company are many times upsetting to users and using current data and thinking critically of the larger impact of any proposed changes is key to minimizing friction and optimizing outcomes on any new redesign.