when you talk to someone about their process and their frustrations, all of those issues are very real, and you should take note. However, they probably also have ideas about how the workflow/interface/etc should be built differently, but they are probably wrong about that being the best solution. (View Highlight)
your first attempt at solving it will also be wrong. (View Highlight)
how freeing it is to know that you won’t get it right on the first try!) (View Highlight)
User research is observing the existing processes that people use to complete their task, identifying frustrations (pain points) and hypothesizing how to make the tool better. (View Highlight)
the idea of paper prototypes is literally the above image, where you draw out a UI and ask people to “navigate” through it by tapping their fingers on boxes. (View Highlight)
The real dataset will almost always have some idiosyncratic patterns that don’t work with your design process, which is why it’s important to bring in real data as soon as possible. The two images above area meant to illustrate this with graph data — when designers draw a graph, it’s almost always a curve like the one on the left: continuous and smooth. (View Highlight)
A common pitfall that I’ve seen in prototyping is the prototype creator spending too much time building out the prototype before showing it to anyone, worried that what they’ve built isn’t substantial enough (View Highlight)
The most important part of a user test is to not start the meeting by explaining why you built the tool the way you did. Instead, put your prototype in front of the user, and ask them to complete some task with the UI. It can be a real nail-biter when they get stuck on a task, but that confusion is the most instructive part of a user test (View Highlight)
(View Highlight)
(View Highlight)
(View Highlight)
(View Highlight)
(View Highlight)
(View Highlight)