Recently, I encountered a sudden change in requirements when I saw that the interactive document that had been painstakingly designed and reviewed and revised was delivered to the vision, and the solution was facing a redesign situation. “Improving requirements” has always been something that designers and developers hate and hate. Although sometimes this is indeed a pot that the demand side did not think clearly, and objectively it is unavoidable, but as user experience designers, we may be able to do more Things to better prevent and reduce the occurrence of such situations.
Cultivate strategic thinking
For some user experience designers, it is the basic skills in the early stage to be able to clarify the product business goals corresponding to the current needs, restore the user scenarios, derive the design goals and then think about the plan after communicating with the business side. But it is not difficult; but if When it comes to the long-term direction of the product, core differentiated competitiveness and other non-pure user experience thinking, they will become hesitating, or will only relay the answers given by the upstream PDs, and lack their own opinions.
The lack of strategic thinking makes us only see and respond to short-term needs, and it is difficult to think about product design from a longer-term and overall perspective. When PDs made mistakes in their judgments and deviations in direction were getting bigger and bigger, we were unconsciously continuing to implement their requirements. When the mistakes were found to be stopped by a big Boss, the design plan was basically completed, and finally we had to Overturn and start over.
When we receive a request to design a product, in addition to thinking and giving suggestions from the perspective of user experience, we must also have a sense of thinking and questioning from a business/commercial perspective: What will this product look like in the next 1-3 years? What are the core competitiveness and differentiation highlights? Can this short-term demand fit with long-term business goals? Is the design input/output ratio for this requirement reasonable? Where is it in the overall business product link map? In the process of communicating and confirming the needs with the business side, we should also dare to ask a few “whys” in succession, instead of getting a superficial answer.
Although this time I was stopped by the big Boss after completing the interaction design, I was still convinced by the reasons given by the other party, such as the high input/output ratio, which cost a lot of design and development costs, but it was used in actual scenarios. The frequency is too low; you can consider the entrance design in combination with the long-term optimization of the overall product information architecture, instead of rigidly adding a module to the hidden secondary menu. Why can’t I find these problems, or have a similar idea but have no confidence to convince the business side? Probably because the thinking and understanding of the product strategy level is not thorough enough.
But fell into the details early
It is true that attention to and ultimate pursuit of experience details is an important quality of designers, and clear and complete annotation documents with detailed descriptions are also an important help to help designers better win the trust of development. But the designer also needs to judge the right time to get involved in the detail design. Falling into the detail too early will have a greater risk of being overthrown, causing a stronger sense of frustration.
As a perfectionist, I sometimes habitually draw high-precision design documents, and then communicate with the business side to confirm some of my own questions and ideas. In the process, I will find some uncommon copywriting, which I did not realize before. The problem of design details has caused the entire module to be overthrown and rebuilt, and some detailed design considerations and expressions corresponding to this have also vanished, consuming excess design costs.
In retrospect, the communication confirmation process between me and the business side should be missing an intermediate link. My model is once before and after the Prd review (pure language, text-based communication), and once before and after the completion of the high-precision interactive document (based on the design draft or even high-fidelity Interactive Demo), the former will lead to inadequate understanding and expression in some links due to the lack of graphical expression, and only find something wrong afterwards, while the latter will have a greater cost of modification, and will be more resistant when it has to be modified. If you can use low-precision graphical expression tools such as whiteboards, sticky notes, and hand-drawn wireframes to help you think, find doubts, and communicate and confirm in the middle, you can confirm all the questions and disputes before investing in high-precision detailed design (of course, in actual China may face design-the formal review cycle is tight, and the business side may not be able to do so ideally except for the situation that it is difficult to find time for the review), and may not have to frequently fall into the embarrassment of “finding out the details and finding all is for nothing” situation.
Necessary strength
Sometimes, the business side lacks a clear understanding of the specific completion cycle of the design, and feels that the designer only needs to spend a little time to solve it, and the need to change will not increase too much time cost, but the actual situation may not be the case. . At this time, necessary explanations and strong adherence to the time limit (including seeking help from superiors) are even more important.
I also talked about this with the boss in the previous performance interview. The situation at that time was that the business side’s needs were urgent and the plan had to be determined within three days. My response plan was to improve my design efficiency as much as possible, shorten the internal audit time, and make it appropriate. Waiting for overtime, and then being challenged: What should I do if the deadline for the next time becomes two days?
In this regard, I think the development classmates are generally better than me. They can clearly inform the business side of the time cost of changing requirements, so that the other party clearly realizes that this is not something that can be dealt with by just changing it. In the face of unreasonable demand, I dare not take the initiative to fight for it, but squeeze my design time at will. Not only will I be exhausted, the design quality will also become more difficult to guarantee, and ultimately affect our own credit.
