Buy Articulating Design Decisions, by Tom Greever, currently in early release. Note: this post is an excerpt from the book.
While every project is different and every client has unique needs, I’ve found that there are some ways of explaining design decisions that I seem to use over and over again. I often say the same kinds of things to defend my projects and, I’ve compiled them here for reference. Some of them are similar or related to one another, but they should give you a good basis for the kinds of responses that are effective in design discussions.
These are the key messages that you need to communicate in order to deliver on your strategy and achieve the objective. So, with your strategy and tactics in mind, find the messages that apply most to your situation and modify them to accommodate your particular context. The goal for this chapter is to give you a list of common ways of describing design decisions that you can use and re-use at each meeting: a set of templates to give you a head start on forming the best response.
I’ve organized them into four categories, in no particular order: business, design, research, and limitations. This is a list of re-usable responses, whether you are appealing to the business, pointing out important design logic, addressing research and data you have, or noting the limitations you face. Use these messages to make your case for a better user experience.
Business
One of the best ways to make a case for your design is to directly connect it to the needs of the business. Three of the most common ways for appealing to the business are:
- Helps achieve a goal
- Facilitates a primary use case
- Establishes branding
Helps achieve a goal
Stakeholders always appreciate connecting your solution to the goals of the business. This is a solid way to make the case for your design by appealing to a nobler motive. This may very well be your answer to the question, “What problem does this solve?” — because, usually, the problems we want to solve with the design are the same as the goals of the project or business overall. Whatever the source of the reasoning, always be sure to call out when your design is intended to help the company achieve its goals.
It can be difficult to know with certainty how a particular design will affect your goals, especially for smaller interactions that may not affect the overall use of the entire application. The point here is not to know with certainty. If we always knew with certainty what would definitely accomplish our goals, then we wouldn’t need to even meet. So, have confidence that your experience leads you to believe with all reasonable certainty that this design is at least one step of a larger approach that will take you where you need to go.
In order to do this effectively, make this connection clear and provide an explanation for how your solution solves this particular problem. Since you’ve already written down each problem alongside your solution in Chapter 2, and part of your strategy is to appeal to a nobler motive, it should be a simple matter of making a statement that clearly communicates these connections. A pattern for expressing this is: “[design] will affect [goal] because [reason].” Here are some examples:
- “Moving ‘Related Items’ above the product description will increase product engagement because users will have more opportunities to see more products.”
- “Putting ‘Recent Projects’ at the top of the home screen will improve data quality because users will have easier access to keeping their data current.”
- “Removing the login requirement will reduce abandonment because users can bypass registration and still see promotions even if they aren’t logged in.”
This doesn’t mean everyone will agree. After all, you might think that using a toggle switch for “Remember password” will improve engagement by keeping users logged in, but I might think that a tried-and-true checkmark will be a more effective solution. The purpose isn’t to expect automatic agreement. The purpose is to be intentional and purposeful with all of your decisions, and this is one way you can communicate that to your stakeholders. As often as you can, connect your design decisions to the goals and objectives of the business.
Facilitates a primary use case
This may be the most obvious and common explanation for any design decision because everything we do is about designing around a particular use case, user story, or feature set. Depending on your stakeholders, they may not be aware of how you use these techniques to create a structure and logic for your decisions. Pointing out which use cases benefit from the decision is a good way of demonstrating your thought process and will get you talking through the decision in a way that makes sense to them.
Just as often, we try to optimize the primary use case by minimizing and limiting secondary or edge cases. For example, while any user is encouraged to maintain his account profile information, it might not be the main purpose of the application; so, that would inform the decision to put account management functions under a drop-down menu rather than a large call to action. Noting these justifications can help you keep people focused on making sure the primary use case is always optimized, even in the face of other needs and features.
While designing for a use case may seem obvious, it’s surprising how often teams can make decisions in a group setting that completely ignore the main use case of the application. Since you’ve already identified that your decisions are tied to that use case, remember to do a quick gut check and make sure you haven’t lost sight of it in the process of moving things around. It’s always useful, even after a decision has been made, to circle back and double-check your decisions against the documented use cases that you hope to design for. When you find your team getting off track, bring them back by reminding everyone what the use cases are and how your decisions affect them.
Establishes branding
While less important to the overall user experience, I often find myself justifying design decisions based solely on the branding standards of the organization. Sometimes things are the way they are because the company has a specific image it’s trying to establish, and your applications have to reflect this as well. This is more true with the use of color, fonts, or language than with specific interactions, but it’s important to call out. If you chose a particular style because that’s what the marketing department told you to do, be sure to bring that to the attention of your stakeholders.
Sometimes application design can be a good opportunity to work with and help an organization develop its brand identity. While it’s not usually an explicit part of the user experience process, some organizations don’t have standards that include styles for things like buttons, drop lists, and checkboxes. So, you may have a chance to help them evolve their standards documentation with your own style guide and move their visual identity in a positive direction. Marketing people probably aren’t thinking about interface controls and are usually happy to have your voice in the process of updating those standards with a common design language. The standards they create will be based largely on their needs, like print ads and direct mailers. Helping them understand where they’ve run into problems can shape the conversation of branding to expand and include other elements that may have not previously been considered. The end result is better collaboration and a more comprehensive branding guide. That makes stakeholders happy, too.