A number of people have written asking how to develop personas for paradigm shifting products that take years to develop. It sounds like people are falling into a couple of common pitfalls:
Pitfall 1: How can I anticipate the technology of the future and my users’ skills with it?
Pitfall 2: How can my users possibly tell me what their needs when I can’t share with them what I am building?
To answer the first half of Pitfall 1, technology can only be anticipated so much. We know CPUs will get faster, disk will get cheaper and smaller, and data will be more mine-able. Other than that, most bets are off. (Though I personally wouldn’t bet against Windows… .) So, while your technology may be paradigm shifting, ask yourself this question:
Is your product going to make use of existing technologies and existing platforms, such as the Xbox or Windows, or does it require new technologies and platforms like the iPod (which in addition to paradigm shifting interface includes funky heads that park when dropped)?
If your answer is that it uses existing technologies, then from a technology standpoint I would recommend you work with safe assumptions (never trusting a company’s planned delivery dates for its new products) and create your UI last, over an existing API, so you will have the most modern interface possible. If you are driving new hardware or system technologies, then drive them to meet the users’ unspoken goals. For example, I doubt lots of people said, “hey, I get scared when my laptop fails after I drop it.” since that’s expected and frankly understandable behavior of a laptop, but who among us didn’t cringe and pray when we dropped our laptop? So, the technologists who created that new hard drive recognized it as a feature that would address users’ unspoken desires and concerns.
The rest of Pitfall 1 and Pitfall 2 address how to get the users to tell us their needs. The short answer is that they don’t and won’t. It’s the rare user who accurately assesses the technology, time, resources and business goals of his/her vendor. And they rarely accurately gauge their own (or their company’s) willingness to pay for a feature. If we were to build what they tell us to build, they won’t like it and they probably won’t pay for it. We’re the experts. The users need us to listen and observe carefully and empathetically so that we develop a product that meets their fundamental needs and goals. There are no shortcuts.
Comments