Process ↓

I believe that designing meaningful solutions for people begins with asking the right questions.

I’ve learned that my passion for building great products is an extension of my WHY… of who I am. I love taking things apart, digging in to understand where things are broken/could be improved, and working hard to deliver simple solutions to meet those needs.

Though I still love to design, I’ve spent the last 10+ years exploring who I am as a Design Leader. In that time, I’ve come to three truths about Design:

1. You need to know whom you’re designing for.

Sounds simple enough, but is often enough simple to forget. In his book, the author Eric Ries states:

“If we do not know who the customer is, we do not know what quality is.” 

The Lean Startup

A modern definition of quality defines it as, “fitness for the intended use” (i.e. meeting or exceeding customer expectations). Quality is a perception that relates a person using a product to that product and is, therefore, not absolute, but relative. It follows that without knowing who our customers are, we cannot know their needs and can therefore neither meet nor exceed their expectations.

We must ask:

• Who is our customer/user?
• What problem are we trying to solve?

Where there is no quality, there is no value. Where there is no value, there will be no customer engagement (effort).

This simple truth leads to my second one…

2. Great design is an outcome of radical prioritization.

In my experience, products often fail when the teams build experiences without a clear understanding (or assumptions even) of who they are building for (see above). Only then, can you begin to make some decisions on the customer’s behalf. When you know what a person cares about and values, you can make better decisions about what to put in front of them.

When trying to cut through the clutter, I will ask my team to put things into three groups. I love the number three. When exploring any options, I will always ask for things in threes from my team. The next thing I’ll ask: prioritize the use cases. What do people need to do most often? Less often? Almost never? The answers to these questions will directly correlate to your design decisions.

• Things you do most often: Should be obvious in the UI. Likely persistent.
• Things you do less often: Should be easily accessible in the UI. Likely in a menu.
• Things you rarely do: Can be tucked away into settings (e.g. a menu).

There are exceptions, of course, but those are often unique/conditional situations requiring other solutions (e.g. a first-run experience).

Exceptions bring me to my third (see? I do like threes) truth…

3. There is no one-size-fits-all design process.

There isn’t. I’ve always tried to treat “design thinking” or “big D design” or whatever the Design Process du jour is as a guideline rather than a strict template. This is where things sometimes go sideways.

The point here is to LEARN and let that learning inform the product and to do that as quickly and efficiently as possible.

I’ve been designing long enough to have seen many, many iterations of the ‘design process’ come in and out of vogue. At Frog, we had a 3-D process: Discover, Design, Deliver. IDEO had a triple-I process: Inspiration, Ideation, Implementation. Popular at the moment, is the Design Council’s “Double Diamond” 4-step variation:

In essence, you start with not knowing much about your task or problem. You move on to knowing enough to develop some educated guesses. From there, you can begin developing a solution that will ultimately get built. Along the way, there are phases of divergent and convergent thinking, there are interactions with users, there’s the validation of assumptions, there’s (a lot of) rework and finally, there’s a resolution. This is, more or less, the design process.

What about… MVPs? I’m good with MVPs… as long as we are clear on what it is we want to learn and have a process for folding that learning into what we are building.

For me, it’s more about knowing when to use a certain tool or process, understanding the trade-offs when skipping a step of the process, tailoring methodology to where a company is at, and being able to strike a balance that propels the business forward while delivering a great product experience.

The Tools of the Trade

Having said all this, here are some of the skills I am experienced in (by phase):

Discover

• market research
• user research
• competitive analysis
• value proposition development

Design

• personas
• empathy maps
• user flows
• design principles
• information architecture
• wireframes
• visual mockups
• prototyping

Deliver

• assets (graphics, bitmaps, 9-patch)
• visual QA
• functional specifications
• style guides

Deploy

• usability studies
• bug testing
• A/B testing
• HTML audits
• Champagne bottle opening

Keywords: Approach, Design, Process, Product Design, Philosophy