At breakfast yesterday, a company's UX (User Experience) colleague talked about their current project ....
Background: the previous day, their UX project team held a meeting with the customer to review the design they have completed. However, customers are not satisfied with the design, but they cannot clearly express their desired solution. The lead of UX asks, what kind of user base is the project oriented? What business purposes and effects does the project mainly aim to achieve? And so on ...... so I had a long and painful discussion with the customer, but at the end, all the problems were back to the origin ..... when the UX Leader asks again .... the customer finally broke out when the user group for the project was targeted. The customer was very upset to ask his colleagues whether they had heard him and he had already answered questions repeatedly. Why? As a result, the project team was completely speechless... it is said that this project has changed several leads, but it is always unable to meet the requirements.
At first glance, there is nothing wrong with the UX group during the whole process, but the customer's old saying is not clear, and it cannot be clear what is the most important and important to this project... haha...
My analysis is as follows:
This is a typical undereducated customer. Obviously, such customers do not understand the software development process, and do not know why we ask such questions? I don't know whether his answer to the question will affect our work in the future? Even he thinks they do not have to answer these questions seriously and comprehensively. First of all, I am not a UX user. If the content mentioned later is inappropriate, please forgive me. Welcome to the discussion. -- Joyyuan97
In the face of this kind of user, we should first give him a preliminary software requirement survey process training... to determine, he knows what we do, our work is meaningful...
Example: How to Train customers: compare a website project
1. We should first tell the customer that we need to determine the business purpose and target users. However, we need to explain to the customer that weWhy?Are you sure you want to determine the user first?
For example, if our website is intended for young people, the website should be cool and cool .... even, you can do the same thing as entering the game interface... haha ..
However, if the website is intended for the elderly, the website should be as simple as possible to minimize unnecessary interference... in addition, the website font should be as big as possible to adapt to the situation where the eyesight of the elderly is generally low.
After explaining this, we can ask the customer about the target customer group of our project? Accuracy .....
2. As in the example of the above website project, we need some design guidelines for different target customers. The second step is to identify the design criteria for each target user. It can also be considered as a persona analysis. Similarly, after talking about what we want to do, we should also tell the customer that weWhy?Do you want to do this?
We need to define design principles. On the one hand, UX will be designed on this basis during design. On the other hand, when we propose multiple solutions for a certain part, we will use the benchmark as the selection criteria to determine the final scheme. Finally, when design reviews are conducted, we will use this benchmark for acceptance of the design.
3. After the task analysis is completed, you can start to analyze the specific requirements and functions. Similarly, we need to tell the customer how to analyze the functional requirements andWhy??
First, the customer will randomly propose the functions, business objectives, and target groups that they think should be implemented. For internal management software, customers also need to talk about their daily work models, business constraints, personnel work location, and process-related information. In this step, we need to classify the demand items. Each requirement should have its importance, priority, and remarks (success criteria, etc ). The criteria for determining each requirement attribute are weighed based on the commercial value and design criteria analyzed above. Finally, we will classify and summarize each requirement item, review both parties in the requirement list, and confirm the requirement scope and requirements.
4. In the subsequent steps, the people who need it should know all about it. People who do not know can look for books on the demand side.
5. FinallyRequirement Signature. Speaking of requirement signatures, I feel particularly interesting... I feel that both software developers and customers have serious misunderstandings about requirement signatures. :-) There may be some bias ....
As software developers, it is usually too important to sign the demand to restrict the customer from changing the demand. However, when you encounter a strong customer, your signature is very weak. If we emphasize too much demand that cannot be changed, we may develop a non-practical software. I once saw a project where the project manager tried to prevent the customer from changing the demand, after the requirement is signed, the project team will return to the company to build a closed door and no longer communicate with the customer ..... the final result can be imagined. after the project is completed, it is found that the process provided by the project is not the customer's daily process, and no top-level leaders participate in the survey, the system did not provide the statistic comparison section at the highest level... crazy ....
As "smart" customers, they are afraid of taking on the negative effects of demand changes, and sometimes encounter delays in signing. Or the signatory is not the real owner of the project...
In fact, the above phenomenon is mainly caused by the fact that the significance and role of the signature is not cleared. My personal experience in requirement signing is: requirement signing is one of the tasks at the demand stage.Mutual affirmative actionWhy does the customer just sign and acknowledge the content we need, instead of signing together? In fact, there is no need to sign the demand so seriously. Haha... For requirement signatures, we need to clearly inform the customer that once the requirement is signed, it does not mean that the demand cannot be changed, but the price of the change will be much higher than our intuition. Therefore, after signing, we need to change the demand. We must evaluate the impact of the demand change and consider it. If you need to change the workload, we can take the following measures: 1. put the requirement in the next iteration cycle; 2. reduce other project modules; 3. adjust the project plan and delay the project delivery time. In fact, it is very easy to explain the cost of demand change to the customer. We can give you a question in our daily life. For example, when we renovated the house, you may say that the walls of the room were white at the beginning, so the contractor went to buy a white dye. However, on weekends, you and your family went to a friend's house and saw that the walls of their children's room were very warm, so your wife and children strongly demanded that the main bedroom and children's room should be different colors, decoration has never been done several times in a lifetime, so you will definitely want to change it. Most of your ideas are as follows:
1. Propose your solution
2. Check whether the contractor team is feasible.
2.1 If the contractor has not started to build walls, we only need to remove some white dyes and buy some color dyes. (Because the purchase is divided and the return behavior occurs, the price of your final purchase of dyes will be higher than the price of your one-time purchase of dyes)
2.2 If the Contractor is already working on the wall, do we need to check whether the master bedroom and children's room are ready?
If the master bedroom and children's room are not started, the processing result is as follows.
If the master or children's room or dye has been partially deployed, you need to see how much loss will be incurred if I forcibly modify it? Including material and labor costs... if the loss is not large, you may force the modification. If the loss exceeds your expectation, you may regret to give up the modification.
In fact, in the software, the management of demand changes is also basically similar, but a little more complex, need to consider associated requirements and other factors. First, let the customer understand our work process and let the customer recognize that our analysis is not perfunctory, but a professional behavior. Why are we talking about the same truth and the same words different from what the customer thinks of experts? Haha... in many cases, we are very unprofessional. Experts usually conduct a short or several-sentence training for the customer and then induce execution. We thought that the method of software development was something that everyone on Earth knew. Therefore, we forced customers to follow our path and felt that you were very aggressive. My favorite point is: if a project manager criticizes a customer who has been working with him for three years and does not understand the software process, most of them, the project manager did not educate the customer on the development process. If you say that the customer does not understand the software development process or the software development process in the first month or even the first year, you still say that the customer does not understand the software process three years later, that's your dereliction of duty... haha... it is normal for customers to understand, but you are an expert in software. Why didn't you teach him? After you add a professional trademark to yourself, you will find that the software is not so difficult, and the customer is not so hateful, more often, they will point out your negligence.
Well, the above is what I said when chatting with my colleagues. I wrote it out without sorting it out. Besides, I didn't go to the book to see if I was correct. If not, please correct me... I try to correct it to avoid mistakes in the future.