In typical UCD we begin requirements with methods that enable us to capture the wants and needs and get a fair idea about the user's mental model. Which helps us in developing the requirements for the product or service design. How do we do the same in absence of user involvement?
1 Answer
For various reasons I have to deal with this issue almost constantly. What we do here is:
- From the outset make it clear to the team that the subject matter experts and the domain experts will be needed for the requirements gathering. Meetings & interviews with them will occur.
- As we write the requirements I always note what user need is being addressed by the requirement (when appropriate).
- Make sure everyone knows that the requirements gathering will be iterative - avoid the trap of "having the requirements complete on xx date". When features get released into your test environment (even earlier is better - ie. dev if you have access) review the requirement with your SME or domain experts. Revise the requirement if necessary clearly stating the user needs.
- Work closely with your QA people. Get them to hold off on the use cases until one iteration has passed, then work with them to get the use cases established. This will hopefully mean the use cases will have clearer user needs embedded. If possible, get a dialogue occurring directly between your experts and the QA people.
This is by no means an ideal situation. To be honest, it's often like herding cats - you will spend a lot of time keeping things simple, relying on heuristics and best practice. But start early and challenge often.
-
"subject matter experts and the domain experts will be needed" - if you can't get the real end-user at least get the persons which know the users really well, or know the domain, task and problems really well. they might not be available easily, but are your best resources...– patricsCommented Jul 6, 2011 at 6:07