Seven Things to Do for Creating Trusted Designs
It is a good challenge for product design team within product company.
Recently talking to couple of design friends in the field of UX and one issue comes up: how to get your design trusted?
There are couple of ways that I have been trying to do to influence the decision making for the sake of great UX designed product. In most cases they should work except when the truth voices of user can’t be heard:
1. Prototype. The best way to get you idea across if you could create the experience that match as close to the final product as possible without tapping into the engineering effort.
It’s important to know when to do hi-fi prototypes V.S low-fi prototypes. Pick your battles and don’t waste time on producing prototypes that are just for the sake of prototyping. I found it is much more efficient to do prototypes for small key design patterns, a micro-interaction prototype for example. It is easier because you can have people’s focus on short/small piece of idea rather than a big long journey that is trying explain every related design points you wanted to make. Secondly, small prototype is much easier to be managed and can be easily altered/updated without trying to make the whole thing working perfectly.
2. Ask around in the office. Internal interviews and internal user testing are your closest friends.
Especially for product that has specific interaction design that can only be validated through interactive prototype.
2. Validate the ideas. This point along can be a big long post. There are things to do in order to validate a design. It also depends on what you want to test so you know how to approach with your limited resource at hand.
Knowing what to test and how to test are also important part of the testing. Are we testing some specific micro-interactions or a big overall design system? How could we conduct the test without injecting our own bias? Always try to stand on the fair ground and to be open minded because you could received many good recommendations from the testing as well. Use it for the benefit of the user.
3. A/B Testing. There are true moments when two ideas could work and the team just can’t make the best call without some concrete support. This is When we use A/B testing. Unfortunately, A/B testing is not as easy as it would be if you are designing the UX for lower level application design (C++, Java, and even Objective C). Saying so, it still a valid task to do if the result can generate some good support data.
4. System first approach. When design something new, I have found that designing the system on overall how the product work can help to reduce tons of confusions and bring people together much quickly. Often there are times some key stake holders are so tied with their own experiences or belief. They could take a wrong analogy for inappropriate references. They could still in a deep relationship with an older version of the software. Keep reminding the team how things have changed and why we need to have a different approach. Make the team forget about what they have get used to is tough battle. So give them a refresh high level design solution on the system level and tell them why the change is needed.
5. Design like playing chess. There were moments when people asked me solutions on the spot and I could not have answers right away. It is ok. I rather give an answer that will solve the problem than trying to prove I am smart(er). What most people don’t understand is that it take some deeper thinkings to step through use cases and flows for a good answers. It’s like playing chess. You need to think 10 steps ahead with couple of possible scenarios in consideration. An inexperience chess player see 3 steps ahead while an experienced chess player could see more than 10 steps ahead and you don’t see then rush into actions.
6. Cut short the command lines. Have direct engagement with CEO if possible or at least have a regular touch point with the key decision makers. Great designers want to hear the first hand business and user challenges. They are great listener. They take in and digest then pull out. Have a direct communication channel will greatly reduce layers of interpretations. Let’s not play the telephone game. We know how different the message become when it gets to the other end.
7. Have a good product management partnership. I can be very honest. There are times when I disagree with product manage and it make me feel helpless when a PM takes his/her own opinions and proposes that to the CEO without a consent from the team. It misses the approvals from the designer and hurting the relationship to form a healthily collaborative team. When it comes to design decision making. Often it can be the issue of trust or miscommunication on how PM interpret business needs from CEO or key stack holders. Especially when the CEO is pushing for GREAT DESIGN, it often is not clear on what that means since everyone can have different standards.
Therefore, if an experienced designer can take the feedback paired with PMs together. This will form a good decision making process by helping the PM digest the message from stack holders and have the PM communicating the business needed/background to the designer.