I believe that designing deeply meaningful solutions for people starts with connecting deeply with their challenges.
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.
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. 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. hamburger menu).
There are exceptions, of course, but those are often unique/conditional situations requiring other solutions (e.g. a first-run experience).
Exceptions brings me to my third (see? I do like threes) truth…
3. There is no one-size-fits-all design process.
There isn’t. Not realizing this will lead to every problem looking like a nail that a design hammer can fix. This is where things sometimes go sideways and end up giving well-meaning designers a bad rap.
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 which 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.
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.
For me, it’s more about knowing when to use a certain tool, 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.
A good friend of mine recently stated, that “… design leaders should spend a little more time finding out about the organizations they hope to lead” before jumping in with Design. So true.
The Tools of the Trade
Having said all this, here are some of the skills I am experienced in (by phase):
- market research
- user research
- competitive analysis
- value proposition development
- empathy maps
- user flows
- design principles
- information architecture
- visual mockups
- assets (graphics, bitmaps, 9-patch)
- visual QA
- functional specifications
- style guides
- usability studies
- bug testing
- A/B testing
- HTML audits
- Champagne bottle opening