[UX] How can we analyze user requirement effectively at UX work?
Gathering user requirement is very essential process in the entire project steps. We should listen to the user’s requirement and translate them to the features in the IT service. That is the commitment as a UX worker. If you don’t analyze the requirement well at this step, some of the steps will be delayed, or you should roll back to the previous step.
I am going to talk about how we analyze user requirements at UX work, but you know this is important in every IT project work not just only UX work.
1. When do we need this work?
As I show the step in the whole project, I think this work is in the very beginning step. this requirement sometimes includes end-user’s requirement of the service, or this sometimes includes service provider’s requirement. Ideally UX designer should consider only end-user’s one, but we also have to consider provider’s one because if there is no way to make some profit from the service, that service can’t be longer so much. We should consider both of them, and be sure that we find out the best point between them.
2. How can we define the process of the user requirement analysis?
We need to step inside of the process at this time. By the way, there must be a clear limitation to get them from the real users. Honestly most of real users can’t know what they really want at this time. That’s so true because even our counter workers like the developers or testers also don’t know about that well, you know that’s why we design the wireframe at the very beginning step to communicate with them.
If you can’t get user’s requirement based on your circumstance, recommend to follow the standard procedure, but if not, I just recommend you to define them first and review them very quickly with all decision makers in your team. At this point, reviewing them with others in your team is very important point. I have seen lots of cases that the designers were under the delusion that they were almost the same with the real end users.
Don’t think about you are the one of the end-user, or someone in your team may insist that the one is a real end-user. However, I don’t believe whatever it is. When we work in the team, we can’t be objective so much to review something related to your circumstance. Mostly they try to define the easy way and no one want to suffer from the hard work. That’s why I think reviewing them with others in your team is very important even if whatever you should decide which requirement would be chosen or not.
In this point there will be a question like “How can we analyze them structuredly?”. I believe top-down way can be the best in this case as always. At least, we can imagine some service structure, and make something like a service menu tree. Here is an example of the menu tree. I defined this for the Youtube player application in the car.
After then, list-up the requirement that you can guess along each menu. As you can make the list in detail more, you may be able to clear the requirement with the less cycle communication with your team members. Be creative and try to imagine lots of user scenes as much as you can in this step.
Otherwise, you may have some good resources from this step. If so, there is a methodology for the work. The reason that we use the methodology is what we don’t miss some steps as we follow the way. This kind of way usually have been invented in the product development industry, but I think this is still good enough to be referred in UX works.
In this point, you can understand what the needs are, what the requirement is, what the function/feature is, and what the specification is. This definition is very useful and make your work much better as long as you know this methodology for sure.
3. Conclusion
I have been lots of project that the requirement is just managed at the very first step only, and then they just ignored the management of them. This means you may work the same thing again and again, or you miss some requirements at the right time. This also affects resource management. I mean they may not able to balance the use of the resources.
Plus, if you don’t track the history of the requirement or specification, that can be nothing to refer in the future. That is the reason that we need to manage them consistently not only at the first time if you just waste of your efforts for them.
댓글
댓글 쓰기