Establishing user needs is vital but it is often taken for granted. It's typical for programmers and other project members to assume they understand a certain user need without really digging into the details, so it's useful to have a process to fall back on. For each ostensible need or problem, we should ensure that we understand the following aspects:

• Who are our users?: What characteristics do they have? What devices do they use? 
• What are they trying to do?: What actions are they trying to carry out? What's their ultimate goal? 
• How do they currently do it?: What set of steps are they currently taking to reach their goal? Are there any notable issues with their current method? 
• What problems do they experience doing it this way?: Does it take a long time? Is it cognitively expensive? Is it difficult to use? 

At the beginning of the book, we asked ourselves to consider why we wrote code, and we explored what it means to truly understand the nature of our problem domain. Ideally, we should be able to step inside the shoes of our users, experience the problem domain ourselves, and then craft working solutions from firsthand experience.

Unfortunately, we are not always able to talk directly to our users or walk in their shoes. Instead, we may rely on intermediates such as project managers and designers. And so, we are dependent upon their communication efficacy to relay the user needs to us in a way that allows us to build a correct solution.

Here we see how the needs of our users, combined with the technical and business constraints, flow into an idea that is built into a solution and iterated upon. The translation of User Needs to Idea is vital, as is the process of feedback that allows us to iterate and improve upon our solution:

Since user needs are crucial to the process of development, we have to think carefully about how we balance these with other constraints. It is usually impossible to build the ideal solution, catering well to every single user. Almost every piece of software, whether presented as a GUI or API, is a compromise in which the average user is well catered to, inevitably meaning that the edge case users are left being only partially served by the solution. It's important to consider how we can adequately accommodate as many users' needs as possible, delicately balancing constraints such as time, money, and technical capability. 

Following our understanding of user needs, we can begin to design and implement prototypes and models of how a system may work. We'll briefly discuss the process of doing this next.