Thanks mate! That is a nice and reflected way of approaching the subject.
Could you maybe provide an Example for your third point? I think this will help the understanding how this could look like.
Could you maybe provide an Example for your third point? I think this will help the understanding how this could look like.
In practice, sometimes I abbreviate these to just the Goal: * I want not to be surprised by topic starvation. * I want to be able to look at the report and right away know if there’s anything I should fix. * I want to be able to see what configuration changes have been made recently.
Or, let’s take this for a simple product feature: * I want my alarm to go off at 7:15 every morning. * I want my alarm to wake me in time for early meetings. * I want never to be woken early by mistake.
You can see that those goals may conflict. What if their first morning meeting is at 7am? Then we’ll need to override goal #1. What if they’ve been invited to a meeting but not accepted it? That surfaces a conflict between goal #2 and goal #3.
So a user may give you those three goals, and then as you design you’ll see the conflicts. That enables you to have a principled discussion with the user — which goal is most important? How do you want to handle goal conflicts?
The anti-pattern here is to design one UI that solves all problems with equal difficulty. A better solution is to prioritize those problems, and solve the common ones easily and the rare ones perhaps with extra work, but not at the expense of clarity.
Start with this list of goals to keep the work honest and focused. Update the goals as you learn more from users to keep the product responsive to their needs. Make sure, before each release, that the product/feature actually does meet these goals. Use the goals as focus points for user testing.