Here’s my response to a thread on Catalyze about people blaming the users for not knowing what they want.
Users always know what they want, but you need to work how ‘how’ they want it!
Firstly, the word ‘User’ is ok. It is an age old discussion, I used to ban the word in my business! Now I’ve changed my mind. When people say ’users’ at least we all know that they are talking about the people in front of a [computer].
Users are best described in the context of what they are doing and tasks, scenarios, workflows (Human decision making) and personas are better at defining this than user cases. At least we can all easily empathise with ‘things people do’. It is a common communication tool.
In terms of user needs, what people need is common. It is as simple as Food, Water, Shelter, Sex and something for their BIG brains to chew on. What people want is determined by their previous experience. When we look at what a business is trying to achieve with technology it is almost always dealing with things that people already do.
The fundamentals of interactions that humans make are all the same. Offices work in the same way. They all have resources, money and information to manage. Looks at banks they are all the same at a fundamental level. If we don’t understand this then we will continue to make stupid design decisions that people (users) don’t understand.
Therefore the need already exists and the user knows exactly what they want. The problem is, have you appealed to their current or future need in a way that they expect based on their previous experience? Before ERP existed we did things on paper, before internet banking existed we did it on the phone and before that in a branch. It’s all the same.
Because we are all the same at a base level, things can be modelled and broken down into common patterns. Patterns of interaction, workflow, interface design, code, architecture, the list goes on. It is these patterns we have to thank for the reuse we always try to do in technology design. It just that the things we are trying to reuse were not designed the right way at the beginning.
The only differentiatior for a system that delivers the same fundamental business need is a 1) brand externally to an organization and 2) a culture internally. I’m not writing off innovation here. We can still do things better. But at the fundamental level we are all humans and there is a core set of expectations that must be met. Otherwise we get confused.
Things should work as people expect and if it is new then their should be indicators in the process so that people learn as they go. Just look at the ipod, a completely new interaction process for music but it works the way we expect based on our fundamental experiences with wheels, lists, stop and go buttons. It even knows we are lazy and doesn’t need to be turned off.
Senior execs should know exactly what they want! And you must ask them!
If a business customer doesn’t know what they want be very scared. If they don’t then you must drill them for it. They are smart and they are sure to have a strategy to achieve positive outcomes for the business. You must understand this to make any useful decisions about their technology. However, don’t expect them to tell you how their staff work or how technology should be designed. They are managers…
I unequivocally showed in my Masters of Organisational Psychology these that the senior management of a 300 strong Australian organisation had a completely different perception of organizational culture to employees. They have very little idea about how their staff work, particularly if the system is poorly designed and staff go about their day with work arounds that make sense to them. The only way, in this case, to find out about this is to ‘watch ‘ them. As someone said what people tell you IS different to what they actually do. Just think about the last time to taught someone to drive a car. Could you remember the detailed processes? No, you had automated it.
Also, you can’t just show management pictures and expect them to get it. If the pictures are coloured in then they will likely dwell on the ‘design’ not the ‘function’. Instead you need to get them invo vled and make them think. I engaged some executive stakeholders with a simple card sorting exercise last week and my did they change their tune after that. In another case I engaged them by getting them to watch a video of their customers (users) wth their system. That also go them off their asses.
What rigorous process?
Combing two screens into one is possible if the workflow is consistent with the expectations of the user. Before deciding to combine, delete or add screens you must find out exactly what people expect and how they go about the tasks involved. Only when this is documented in a worlflow can you work out what screens to put things on. Find this stuff out by engaging the person ‘on the ground’ not their boss.
1) Start with the executive
• Find out what their business (unit) does?
• What are their issues and concerns?
• What do they want to achieve next and what are the KPIs?
• What is the status of the existing technology?
• What do they think they want to do - the innovation?
2) Confirm these needs with the users
• Look at the context and choose the right kind of research. You will need to see how well defined is the problem space. Is it a common tool? How long have people used it? Are there other solutions available (check them out)? How well is it understood? If the tehnology is new how similar is the interaction process to existing technology?What are the risks?
This will help you understand how and how often to test during the SDLC.
3) Feed it back to the executive and tech team and update your requirements
4) Plan the interface with the whole team to leverage usability, business, technical and design innovation.
5) Flesh it out and test it if you like – no surprises is my motto!
6) Work out the technology requirements to deliver that interface
7) Build the technology and manage quality
8) Test it with users
9) Keep testing and measuring
