According to the User-Centered Design (UCD) philosophy, actual users should be involved throughout all stages of a software or product development project. Firstly, users are indispensable while the project team learns about the users and their work (requirements gathering), and secondly, users can help test and validate the designs and prototypes, to ensure that the product is effective and usable.
UCD makes a lot of sense, and yet in many corporate environments, there is extraordinary management resistance to involving users in the product development process. Let’s examine some common objections to UCD and how you might address them.
- “You can’t do that! That’s not the way things are done here. That’s not our standard practice.”
Gently identify flaws in the company’s current products that could have potentially been avoided if a user-centered design approach had been used. If it’s too politically sensitive to criticize the company’s products, then try finding examples in your competitors’ products, or in mass-market products you’re familiar with.
If you’re forced to use a company-wide standard project methodology, ask whether the status-quo approach has always delivered flawless results, or whether there’s potential room for improvement. Lean, competitive organizations are often willing to entertain and embrace ideas for doing things more effectively and efficiently.
- “We don’t need to talk to users. The team has experts with all the knowledge to design the product.”
You’d be surprised at what you can learn from observing users doing their work, asking what problems they have with their current system or approach, and getting their ideas on what could be done better. It’s virtually guaranteed to challenge some of your long-held assumptions.
For enterprise applications, it often sounds like a good idea to only talk to the managers who oversee the users. But it’s important to talk to actual users who work with the system, and not just their managers: The reality of the way knowledge workers really get their jobs done frequently involves workarounds and special cases that their managers may overlook (or may not even be aware of).
- “We have a very tight schedule. We can’t afford to spend all that time talking to users and involving them in testing.”
Getting the requirements right is important so that you build the right product. This will prevent the team from wasting valuable time on unnecessary features and rework. Likewise, testing the product as it is developed to ensure that it really meets the users’ needs will avoid costly disputes with the customer (for bespoke enterprise systems) or failure in the marketplace (for mass-market products) after the product is delivered.
- “We don’t have staff experienced in these user-centered techniques.”
Your developers and business analysts can learn the techniques from books or training courses, or you might consider hiring a usability consultant.
- “Marketing is responsible for talking to the customers.”
Some organizations suffer from ugly and unproductive conflicts between competing managers and departments over their areas of responsibility. Try to build consensus around the need to establish the best process for ensuring a quality product, as all departments will benefit if the product is successful.
- “We don’t want to lose face in front of our customers if our staff asks questions that we should already know the answers to.”
Users and customers are usually more impressed that the team is taking the time and cares enough to understand their needs and provide a great product. If this is still a concern, then assign experienced senior staff to be involved with the users.
- “If we involve our users and stakeholders, they will all have different ideas and opinions that will divert our project’s focus off track.”
Ensure that all proposed user requirements undergo a proper review process to ensure that everyone’s wished-for features don’t gradually sneak into the product scope (this is known as scope creep or requirements leakage) without analysis and confirmation by an authority. A process such as the Quality Gateway described by Suzanne and James Robertson in Mastering the Requirements Process is recommended for controlling the quality of proposed requirements.
- “We can’t afford to let our competitors find out about our product development.”
Confidentiality is an important concern during the development of products to be sold on the open marketplace (it’s usually less of a concern for in-house enterprise applications). Consider non-disclosure agreements. Or, if possible, instead of working with users at your customers’ sites or recruiting users “off the street” (depending on your type of product), try to find users within your own organization.
- “I don’t want someone on our team to make promises to users that we can’t keep.”
Ensure that users understand that their suggestions and feedback are important, and that the project will try to accommodate as many reasonable ideas as possible, but that no guarantees can be made for any particular feature requests. Explain that the project has deadline and budget constraints and must satisfy multiple stakeholders, and that compromises must be reached.
- “We can’t afford to test with users. They might find a fatal flaw that will impact our deadlines!”
(Seriously?) Much better to find serious flaws early, when they can be corrected, than to discover them after delivering the product!
[ad#AdSense_Banner]
