I know that this topic is one that has been written about before, but in being true to my own advice, I’m going to raise it again here, today. That topic is the importance of having and being prepared with solid rationale for the designs that we create. To explain further what I mean, as designers we create some pretty awesome design solutions for the problems that we help define. We are creatives by nature, and whether we are designing solutions to holistic experiences or to detailed interfaces, we are continuously challenging ourselves to come up with something new and appropriate. These problems include things like “how do we increase page views?”, “how we we increase conversions?”, “how do we get more people to successfully complete this form?” and the list goes on and on. However, what I notice is that some of us are not always designing these solutions based on design knowledge, testing, or due to a combination of user behavior, business need and technical constraint. Instead, some of us go solely with opinion, misled gut feel, or just with what solutions are new and cool at the moment. This type of behavior leaves us with a big problem on our hands.
Let me give you an example of what I mean. Stop me if you’ve heard this one before. A designer walks into a review meeting with their larger project team in which they are showing some new designs that they have worked on all week and that they are sure will be accepted and praised. After looking through the designs, the larger project team begins to throw out questions like “This solution seems to be heavy on the server load, can’t we do
However, this outcome could be completely avoided… if only the designer was equipped with solid rationale. Thus, instead of talking solely about the page being cleaner, the design educates the audience on form design, references the materials they’ve read in order to create their solution, and points out the behavior of users and how this solution is best. In response to questions about what the project team thought the design would be, the UXer can break down the problems with or successes of these ideas and how they relate to the rationale they have provided. Whatever the answer, the designer knows from a non-opinion, fact based standpoint why they designed what they have, how this helps the user, maps to business requirements and takes into account technical complexity.
Having and designing with this information brings the conversation to an entirely different level. It allows everyone on the team to talk about solutions and not just opinions. It allows the designer to lead the conversation and to have the most important voice, while making sure they are listening to all others. It gives you, as the designer, points from which to design, instead of that uneasy feeling you get when you walk into your project meetings afraid that your designs will be turned down. You will have all the ammunition you need in order to defend your solutions, or update them based on the conversation. Designing in this way, by looking at why you are making the solutions that you are, also forces you to be a better designer. You will begin to think differently about the solutions you are creating, why you are creating them, and who they benefit. Without rationale, though, it is simply one opinion versus another, and nobody wants that. Opinion based design only leads to erroneous compromises for the people creating the product, and that does nothing for the people that really matter… those using it.