Usually, I start with the question “How would you be able to tell that this problem had been solved?” and repeat it two or twenty times in different words until someone actually tries to answer it.
What a true and hilarious depiction of life. I have the exact same problem doing web development. Because the people giving me projects are not IT people they tend to come up with totally dysfunctional solutions. Yet they almost always start by telling me how they want the problem solved. I have to dig to find out what the problem is first but I just ask them “What result do you want?” or “What purpose do you want this to serve?” and say “I can’t make it serve the purpose without knowing what the purpose is.” That works for me, without me having to ask them 20 times. Then again maybe you’re doing projects in radically different contexts all the time, or with completely different people who vary in their ability to see the point in answering that question. I work with a limited number of people and contexts, all of which I understand pretty well, so my problem clarification process is pretty simple.
What purpose do you want this to serve
…
I work with a limited number of people and contexts, all of which I understand pretty well, so my problem clarification process is pretty simple..
In my experience as a programmer (who wore all the software-related hats), I found that even when I understood the domain quite well, inquired about the purpose multiple times, and wrote little stories illustrating my interpretation of the users’ desires, I could walk away from early usability tests with major changes to the project.
In one particularly memorable instance, I got all the way through making paper prototypes and making pretend e-mails. Then, I convinced my manager to try out the system. The process started in a pre-existing e-mail package and then routed stuff to the proposed custom software. He sat down, opened up the pretend e-mail, and started to save the attached files. At that point, we discovered that there was no need for the custom software and killed the entire project.
What a true and hilarious depiction of life. I have the exact same problem doing web development. Because the people giving me projects are not IT people they tend to come up with totally dysfunctional solutions. Yet they almost always start by telling me how they want the problem solved. I have to dig to find out what the problem is first but I just ask them “What result do you want?” or “What purpose do you want this to serve?” and say “I can’t make it serve the purpose without knowing what the purpose is.” That works for me, without me having to ask them 20 times. Then again maybe you’re doing projects in radically different contexts all the time, or with completely different people who vary in their ability to see the point in answering that question. I work with a limited number of people and contexts, all of which I understand pretty well, so my problem clarification process is pretty simple.
In my experience as a programmer (who wore all the software-related hats), I found that even when I understood the domain quite well, inquired about the purpose multiple times, and wrote little stories illustrating my interpretation of the users’ desires, I could walk away from early usability tests with major changes to the project.
In one particularly memorable instance, I got all the way through making paper prototypes and making pretend e-mails. Then, I convinced my manager to try out the system. The process started in a pre-existing e-mail package and then routed stuff to the proposed custom software. He sat down, opened up the pretend e-mail, and started to save the attached files. At that point, we discovered that there was no need for the custom software and killed the entire project.
Yeah, it’s different people and a different context every time.