Articulating Design Decisions

Product Information

Greever makes the point that UX designers’ frustration with the perceived dismissiveness of stakeholders may arise from a lack of empathy. People are sometimes invited to meetings because they have a unique perspective on our product, even if they aren’t directly involved.

You may find that you don’t have to do nearly as much talking to express yourself because other people will do it for you. Using data to support your design decisions is the golden ticket to getting agreement because it is the most scientific way of demonstrating that your designs are having the intended effect. The stakeholders asked you to make some changes—despite your best efforts at convincing them otherwise—and now you must show them that design. Help your stakeholders understand that because this consistency in the experience is so important, changing an expected pattern in one context will have the ripple effect of needing to use the same pattern in other places throughout the app.Product owners and project managers are usually the ones who will help you with this effort, but it’s entirely likely that you will need to do the work of combing through the chaos and drawing connections between elements of your design and the behavior of the user. For example, if you know that someone is going to ask you about the icon you chose, then bring a batch of alternative icons that might also communicate the same concept. This demonstrates that you value everyone’s time by only showing them the important parts while also giving them the opportunity to participate in a real user session.

Although limits in resources are usually just a matter of money and people, there are four main areas that seem to affect web and application design more than others: Support There is a lack of support, infrastructure, or internal processes to handle the added requirements. If we always knew with certainty what would definitely accomplish our goals, we wouldn’t need to even meet.I quickly picked up on this and discovered that every time I gathered data to support my proposal, she would agree.

We usually begin with a no-limits design that, as soon as implementation is underway, gets whittled down into what’s actually possible, given our desire to make the app work for everyone. 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. I paused the discussion and took a few minutes to go back and ensure that everything was properly aligned.

Greever suggests utilizing a horizontal chart or timeline—similar to what you might use to show progress in designing a sign-up process. Your teammates can be there with the same list and interject when they see an important part of the logic is missing from the discussion. I recommend doing all of them every time, but the degree to which you spend time on it differs in each situation. On the other hand, they might be compelled to fight on your behalf for additional resources to make it happen. We need to communicate that we’re not only putting things on the page in a way that looks good, but that we’re trying to draw users into the application and lead them to action with an appropriate placement of design elements.

Because you’ve already identified that your decisions are tied to that case, remember to do a quick gut check to confirm that you haven’t lost sight of it in the process of moving things around. When it comes to usability, getting users to successfully complete a task is all about their available brain space: their cognitive load.These people should always be prepared to come to your defense if things take a turn that you’re not expecting. Even though this is always a risk, approaching our meetings with this fear actually undermines the purpose of articulating design decisions. The types of decisions a designer makes during the design process will vary depending on an organization’s size and the product’s maturity.