Many designers are used to using their own experience and subjective feelings to propose solutions, but experience and subjective feelings are likely to be wrong. User-centered design needs to be implemented based on objective facts related to user psychology and user behavior, rather than the designer’s “self-reference”.
Don’t say “I think…”
Many designers are used to using their own experience and subjective feelings to propose solutions, but experience and subjective feelings are likely to be wrong. User-centered design needs to be implemented based on objective facts related to user psychology and user behavior, rather than the designer’s “self-reference”.
Designers who use the “self-reference” method often get caught up in the entanglement of multiple options, which will waste a lot of time and energy. If the design is based on facts, we should collect enough data, research and test conclusions, and make decisions based on these facts. This will allow us to make the right decision without wasting time.
Team members’ discussions and challenges on design are usually in a “self-reference” way. At this time, if there is no objective facts as a basis, designers can easily fall into a passive state (which makes many designers have the ridiculous concept of “territorial awareness”), and even conflict with other team decisions, affecting the efficiency of cooperation. And if the design is based on a certain factual conclusion, then these doubts are not to be feared, and the designer can better work with others.
Therefore, design based on facts is our goal. However, in actual implementation, we will find that designers have very limited resources for obtaining factual basis . In many cases, the data and information that have been mastered are not enough to provide a sufficient basis for a new requirement, and it will take too much time to conduct rigorous user research and testing in the early stage.
So in the whole process, how do we efficiently collect facts?
Inspired by Test-driven Development in software development, I thought of a radical design process called Test-driven Design , which I can try.
Under traditional design methods, designers spend a lot of time on their own plans. However, Test-driven Design requires us to reverse our thinking, shift 90% of our energy to the process of seeking evidence for facts, and use the remaining 10% for rapid iterative solutions, so as to achieve zero entanglement and zero disputes. Time is saved and put on multiple schemes, iterations and verifications.
Prototype in the shortest time
Our goal is to build a Minimal Viable Prototype (Minimal Viable Prototype, inspired by the concept of lean entrepreneurship) in the shortest possible time, so that it can be used in design verification. Never output a complete, documented solution with all the details at this stage (even if it looks more “professional”).
How to do?
1. Be fast first. Use the tools you are best at, maintain a highly reusable personal template library, establish the most efficient workflow and tool collaboration system, and keep the design files clean and organized (for example: Visio element grouping, PS and Sketch levels And layer naming) to facilitate subsequent rapid iterative modification.
2. When you encounter a design point that you cannot determine, or a design point that has different opinions from others, first look for the existing data and facts to support it. If not, avoid too much discussion, quickly output multiple feasible solutions, and then prepare to put them into the next step of the verification process. To avoid quarrels where neither side can be persuaded, factual basis is the key to solving everything.
3. From an objective perspective , avoid “self-reference” or “boss-reference” designs. Always remind yourself: “What I know and observe is not necessarily right.”
4. Avoid delving too deeply into undetermined details. Remember: What is needed now is not a complete solution document, but just a prototype for testing and verification. Too fine may be harmful, which requires designers to balance through subjective judgment.
In my experience, usually interactive design can complete the rapid construction of multi-scheme prototypes within 1-2 hours. For small-scale needs, this time can be reduced to minutes. For visual design, it will take longer, but the longest should not exceed one working day.
Prototypes are best to be dynamic, actionable, and high-fidelity. But this also depends on the specific needs.
Validate as you do
Designers need to contact data, experts and users to verify and evaluate the quality of multiple solutions. Design verification needs to be interspersed in the program process as an immediate and strong support to the program.
Data search is the easiest way to obtain facts and can solve many entanglements. Designers should have certain data analysis capabilities, be familiar with the back-end data system of their products, and often go there to find useful information.
We can use the lowest cost heuristic evaluation (Heuristic Evaluation) , through experts and design leaders to screen and recommend solutions. Heuristic evaluation can give designers a process of openly explaining and discerning the plan, and can discover some elements that may be overlooked.
But heuristic evaluation is still subjective. In many cases, we still need objective user research methods. The reason why these research methods are feasible is that we have saved the time that was originally used to entangle the details of the plan and conduct invalid discussions.
1. Use fast, low-cost, and easy-to-implement research methods, such as user interviews, prototype testing, etc.
2. It is necessary to perform user research and testing in a comparative way, not only can compare the designers’ multiple plans, but also compare competing products.
3. The test should be carried out around targeted indicators closely related to the demand goal, such as: the time spent in a certain process, short-term PV statistics of a certain branch, and so on. The performance of the program in targeted indicators can be used as a direct basis for decision-making.
After the design verification is completed, use the obtained factual basis to modify and refine the plan. If there are differences in the plan, then a small iteration is carried out to prepare for the next design verification. Every time the design verification should be lighter and faster, until the divergence points are all eliminated, we have come to the ideal plan. This is the rapid iteration process of Test-driven.
Test-driven Design differs from traditional design methods in that the solution is no longer the purpose of research, on the contrary, research is the purpose of the solution , just like Try & Catch in programming. The plan is a tool, not a goal. The goal is to grasp the facts and get the insight of the entire requirement at the user experience level . The solution is just an accessory in this process.
Long-term research
Now that we have raised our horizons from the solution level to the insight level, we can see that the designer’s work is not a temporary content, but a continuous work throughout the product life cycle.
So what can we do after the design has been developed, implemented and released?
1. Observe the data and see if the previously drawn design scheme is successful? If unsuccessful, what elements caused the reflection? Are these elements on the product, on the market, or other aspects?
2. Start long-term user research from various channels, such as: A/B testing, data observation, path analysis, user feedback, social media public opinion, etc.
3. Try to find new problems!
In the whole process, the core of what we do is to form more and more perfect insights for products and users. Every application research and every analysis will deepen our insight into the product and strengthen our grasp of needs and solutions.
To sum up
We found that: with sufficient factual basis and insight, the plan is just the result of letting the flow go! This is the most powerful point of Test-driven Design: it is not only a design method, but a mechanism that allows designers to generate insight and allow solutions to emerge naturally. So we can also call it Insight-driven Design.
This is a preliminary and radical idea, which has not yet been verified in practice. But today’s designers need to quickly build an understanding of unfamiliar areas, and they need a self-renewal and collaborative mentality of playing, walking, and learning while doing. The traditional scheme-centric approach is no longer applicable. And Test-driven Design is definitely a way of working worth trying.
