To understand what problem we are solving and for whom we are solving the problem. Even though I read so many case studies explaining we did this, we did that; a crucial step many overlook is understanding the type of users they are defining and the actual problem. It could sometimes be just a tiny part of a process flow of an app or a complete user experience revamp of the app. These are not something we can understand by just jumping onto the requirements or from one client meeting.
As designers, we are sometimes guilty of not doing so. When we receive requirements from the client, we immediately assume what needs to be done, jump into the so-called UX design process, and get into brainstorming, ideation, design, etc. Even studios/agencies jump on defining the steps they will need to work on the project without completely understanding what needs to be solved (Ignore those fancy case studies, everything can be made fancy pretty quickly – beautiful images, wireframes, etc.). They define unnecessary processes and stages which might not even be necessary for the particular project (cue all those heavy post-it-filled images and workshops).
Understanding what problem needs to be solved is crucial before we get into the heavy details of the process, sessions, deliverables etc. Delve into the requirements document and understand what is going on. If you are working alone, do your research – either online or offline; if with a team, involve the research department to look into what can help you get more clarity on the problem and who the users might be for the particular problem/project.
When you have all the information that gives you an understanding of the users and the problem, then and only then you can kick start your process. Having all the information upfront helps you or your agency decide on the steps and procedures to follow to arrive at the solution.
