The basis of every user interface and every user experience to be designed are the requirements. That is, what you - the user - should be able to do with the thing we - the agency - are actually building. Ideally, this has little to do with what individual decision-makers personally think, but rather with what the users really want.
How requirements are received by us
A few examples from the last 12 months:
- Powerpoint with bullets like "Filter content catalog by genre
- Productbacklog lists (Hello Scrum!) with entries like "Deepening the content diversity
- Overviews with "Functional requirements" which, for example, request this: "The user has access to lists which allow a selection of films and which can be filled by the system or the user".
- Lists with many user stories, such as "As a user, I want to be able to navigate the content of a category in a visually appealing, informative and fast way.
- Use Case documents with countless Use Cases à la "When the user selects navigation point 1, the system presents him with an overview of all available subcategories.
- Handwritten notes on which the "Watch TV" function is set in relation to a device such as the "smartphone
- …
Request for technology ≠ Request for use
All these requirement descriptions have in common that - even if in the pure notation apparently user-oriented (User Stories) - they generally reflect what a system should be able to do technically.
Now is not to be said per se against it to formulate requirements to the technical system, also requirements from view of the market, an organization, the legislator or the specialized department are relevant. The only question is: when in the project cycle is the right time for which type of requirement?
The user does not even know what he wants
If the focus is placed too early on non-user-based requirements - and these are all the above-mentioned requirements - the danger is enormously high that technical feasibility or perceived functional differentiation from the competition will form the basis for the product/service. And no longer what the users actually need. Or who really needed 1000 storage spaces for phone numbers in his Nokia bone back then? Exactly.
Sure, a product manager has a feeling for what users might need, maybe even qualitative mafo data on it, which gives him the top 10 functions. It is good and fair to define some of the requirements from the product managers' point of view, but please don't define all of them. Real potential users and professional "requesters" have different opinions about which feature is especially important, when and in which form. Expressed as a feature, the user does not necessarily know what he wants. But behind every function there is a need, the user knows that and that can be elicited.
So let's include the user already in the phase of requirement definition - this is faster and cheaper than commonly assumed (my colleague Anja Lange has explained this very nicely here with the help of an example). And it also has an extremely positive side effect: HiPPO decisions can be minimized in discussions with stakeholders
It is then said less and less often "I think the feature is the most important" - but all the more often "Of course you can leave it out, nobody is interested anyway".
.jpeg)
.jpg)
