I’d like to talk about the Nintendo Wii.
Earlier in the month I wrote about how approaching software design from the perspective of an anthropologist was a good idea in Project Management Software Development: A Fresh Look From a New Perspective. I’d like to continue that discussion by talking about how we, as software users, sometimes struggle with what we really need vs. what we think we need—and how software designers need to somehow figure out the best way for us to interact with the software. (I think this applies whether or not we are talking specifically about project management software. As an industry, PPM software just happens to be a really good example of a failed development process.) As I describe in the previous post, human behaviors are pretty complicated things to measure. There are so many variables associated with how we react to different situations that it’s difficult to quantify our behaviors in a way that can be illustrated in a graph or spreadsheet.
Love it or hate it, the way my Nintendo Wii was designed is a good case in point. Genyo Takeda*, the general managers of Nintendo’s integrated research division, said the following about the possible consequences of allowing convention thoughts about video game design to control the development of the Wii:
Could the project management industry learn from the Wii?
Most project management software development is driven by feature requests (what end users and developers think they need), without really observing how they interact with the work management process. It doesn’t help that the people buying the software aren’t always the people using the software either. Most of the PPM practices we use today have evolved from the assembly lines of the industrial age. They may have been great processes for building the Model-T, but they are not effective at helping today’s knowledge worker deal with the creative problem solving that goes on within most project teams today.
Of course anthropologically driven contextual inquiry is expensive. It takes dozens of customer visits and hours sitting beside users, watching them interact with the process. Until the industry starts paying more attention to discovering what users really need, verses what they say they need, what the analysts say they need, or what the designers think they need, the industry will continue to produce unimaginative software that is tedious and cumbersome to use.
I agree completely. This has long been a problem with technical/computer driven systems and especially companies who consider them selves “technology” companies and not “business” companies. So how is @Task going to address this? As a user, I see many areas that need to be evaluated in light of your last sentence.
Purpose of adding a feature is important, Wii may be successful, even I have it and to be frank is is different experience to play interactive games. Having said that would it mean I would not like a superior graphics display, is wrong. At some point of time i might have to purchase a game console which offers me a better graphical experience and trust me it is equally important. This could have been avoided by a simple task of using some graphics card (Nvidia cards) and make this a complete experience. Different thoughts have different conclusion, Wii may be a success but if this is fixed it will be a revolutionary. Just think about it. Pleas Note:- This is purely my thought. Cheers Alok
Thanks for your comments. John, the process I described is how Stream was developed (www.attask.com/stream). It is a first step towards taking this approach to software design. We recognized that there were some of the issues I described within our own product, I believe the demo will give you a good idea where we are going and how we are applying contextual inquiry into our product. If you have a minute, watch the video and feel free to comment again here. Thanks again for participating.