I just finished reading the book Elements of User Experience Design by Jesse James Garrett, and oh man, I wish I had read this book years ago while struggling to figure out a good design process on my own.
This book defines five elements, or planes as the author calls them, of the the design process and my main takeaway is that having the right process in place matters, and it’s important that you stay consistent and true to your goals throughout it.
There were three lessons I especially wish I didn’t have to learn the hard way. I recommend reading the whole book, but here is a summary of the three lessons I hope you learn the easy way:
Lesson 1: Work On Your Strategy And Create Structured Flexibility
Set yourself up for success - get the foundation right.
In startups we often shy away from documentation or spending too much time on creating a strategy for how to accomplish our goals, if we ever get to defining a goal in the first place. Everything changes so fast, so why spend so much time today on something that may be of no relevance tomorrow?
But you are probably shooting yourself in the foot if you’re trying to save time by not prioritizing developing a strategy before you do anything else. And I definitely think there is a way to create strategies that are flexible enough to handle curveballs and pivots. If anything a good strategy enables you to better handle the unpredictable nature of startups, because no matter what life throws at you, you know clearly what problem you are trying to solve and who you are solving it for. If that changes, at least you’ll be aware of it and able to redefine your strategy, not end up realizing that you’ve built a product for someone else than you intended it for without any runway to adjust any of the other dials of the machinery accordingly.
A good example is the Military. Their emphasis on scenario simulation planning and deep rooted understanding of goals and values make them capable of adapting quickly when new information is brought to the table or the conditions suddenly change.
So before stepping up to the next plane, every member of your startup should have a clear and explicit understanding of the underlying strategy and be able to answer these fundamental questions:
1. What do we want to get out of this product?
2. What do our users want to get out of this product?
Lesson 2: There are 3 whole planes in between strategy and the surface!
Once you have a clear foundation, make sure all the decisions you make throughout your process are aligned with your defined strategy, both your own goals and user needs.
At startups we often rush to get from idea to launch. Build fast and break things! Be lean! There is a lot of emphasis on being fast in the startup community, but I often wonder if people are conflating the idea of lean with just being fast. Shipping a poor product fast is not the goal. Then you’re just misapplying another of Eric Ries’ maxims, but I don’t think he meant it this way; Fail fast. I believe it's more about getting it right as fast as possible.
This book is emphasizing the importance of getting each plane right. Not necessarily before you move on to the next plane, but absolutely before you declare a plane for finished.
It's natural to already have an idea in your head about what the finished product will look like when you're at the strategy plane, often something similar to the standards that are already out there.
But we sometimes get too eager and rush to just get something built without thinking specifically about meeting our specific users' needs. Maybe we don't even need to build half of the features that similar types of products might have. The only way to find out what the right set of features are for our users or which navigation architecture to choose, is to delegate sufficient amount of time and energy into defining the scope, and building the right structure and skeleton. And every decision has to be rooted and aligned with the planes above and below. If not, what’s on the surface won’t matter.
Lesson 3: How To Get It Right? Be specific and be consistent.
On the strategy and scope plane it’s critical to be as specific as possible to build a strong foundation to build on top of.
One example is when defining who your target users are. Is it young people? Young professionals? Young professionals between 20-30? Young married professionals between 20-30 with a dual household income? As you can see the more specific your user definition is, the easier it would be to make the right decisions later in the the design process when the time comes to prioritize features and make tradeoffs that would meet the user needs.
Another example is setting specific indicators to know whether the product is meeting the company's objectives and your users needs. What does success look like? When do you know you have reached your goal? How do you even know you are finished building the product?
Being specific when defining your success metrics helps you understand when you are doing something right and when you need to make changes.
For User Experience design it's important that the metrics you set are tied to what you can actually affect with your design. Conversion rate is one example of a metric that could be a reflection of your design. A bad metric would be how many new visits the landing page got after a redesign you did. It’s a poor metric because people would have landed on that page with any redesign, they would know if they liked it or not until they got there. But if they are convinced by your design and messaging, and sign up more after your redesign (ie higher conversion) yes, you know that you did your job.
The third example is being specific when writing your requirements. Your team members are not mind readers and everyone comes in with their existing norms and ideas. Being specific when writing your requirements removes the possibility of differing interpretations.
Especially at the Structure plane and onwards, being consistent is key. Therefore it’s important to think through the language you are using, from your visual signals and wayfinders to navigation flows, all the way to your error handling. To help yourself and your team staying consistent, creating a style guide, a thesaurus or other supporting documentation can be helpful.
I hope this has been as useful for you as it has been for me. Feel free to leave a comment and let me know what you think.