Enterprise User Research — Part 1
One of the biggest challenges of designing professional apps is to get the right data from users. There is only one situation worse than designing expensive and complex professional app with no data — to design it based on false or biased data without being aware of it.
I am still trying to develop a set of techniques and tools to gather relevant user feedback at each design phase — from initial research to prototype validation.
In Part 2 of this article, I am evaluating some of the known research techniques as the only source of relevant user feedback to be used in product design practice.
Challenge
In the world of enterprise software, even contacting the actual user is a challenge. The software is used by an organisation, not by an individual. It is difficult to figure out, who exactly manages authorization engine for one of the General Motors subsidiaries, even when you know that your company sell this software to GM.
Suppose you have the contact info to a professional, who is using this specific software product. All humans are social animals, and the general assumption is that people love to share their feedback. Talking about a negative experience will help users to solve their current issues, and talking about positive experiences make them feel pride in their craftsmanship.
But this behavioural concept cannot be always applied to all professional domains.
Jim the crane operator
Jim works as a crane operator. It is not just a job, it is a passion. Jim is very skilled in his craft and has a lot of experience with various types of crane machines. Because of his responsibility, he regularly needs to pass quite a few certifications.
Once Jim’s daily shift is over, he rushes home to see his family and enjoy his time with friends. His personal interest is not crane improvements — he likes dogs and motorcycles.
Jim never felt an urgency to seek and join any crane-operators organization or forum. Jim is not even sure what is the vendor of his machine and why the company is using this type of machine. The company bought the machine years before he joined and trained him to use it.
There are a lot of things he dislikes on the crane and the cockpit UI, but he is used to work around it. After all, the building site will not stop for a day because Jim needs to consult some crane cockpit UI improvements. It is his job to figure it out.
Sometimes strange people are asking him naive questions about how he is getting things done. Jim doesn’t know what to answer. Jim does not want to look incompetent in front of his manager. They are even asking him if he would recommend this crane to a colleague. Jim has no idea what that means, he doesn’t know any other crane operator but him. But he says yes, I would recommend it.
Software design
You might think that Jim's metaphor cannot be applied to professional software domain. But the biggest Enterprise User Research challenges are coming from the areas, where very skilled and focused professionals work in a very similar way to Jim.
They are busy. They do not want to spend work hours on tasks they cannot immediately benefit from. And product managers and designers expect them to have some strange motivation to improve something, that they have no control over.
Conclusions
The best technique to gather unbiased research data from users is to observe them in their natural environment. Unfortunately, for most of the areas, this is almost impossible. These are the situation where the designer just can't sit in a crane cabin with the operator, observe his daily shift and ask questions.
When it is not possible to perform repeated qualitative ethnographic user research, it becomes extremely important to explore other user research techniques and validate every design assumption.
Liked it? Please recommend it and continue with Part 2.
