Software Engineering, Project Management, and Effectiveness
When you're working on an R&D project, how do you shorten the cycles around testing your user experience models?... Be the Software
That's the advise John Socha-Leialoha, father of Norton Commander, gave me and it worked like a champ.
We faced a lot of user experience design issues early in our R&D project. For example ....
Initially, we did a bunch of whiteboard modeling, talk-throughs, and prototyping. The problem was the prototypes weren't efficient. I had a distributed team so it was tough to paint a good picture of the prototype, even when we all agreed to the scenarios and requirements. The other problem was customer reviews were tough because it was easy to rat-hole or get distracted by partial implementations. The worst case was when we would finish a prototype and it would be a do-over.
We experimented with two techniques:
This radically improved customer verification of the user experience and kept our dev team building out the right experience.
Mocking up in slides is nothing new. The trick was making it efficient and effective:
For example, here's the slide list for one deck:
What originally took a week to prototype, we could mock up in an hour if not minutes. Do-overs were no longer a problem. In fact, mocking up alternate solutions was a breeze. The beauty was we could keep our release rhythm of every two weeks, while we explored solution paths in the background, with less disruption to the dev team.
The other beauty was we could use the same deck to walkthrough with customers and the dev team. The customers would bang on the user experience. The developers would bang on the technical feasibility. For example, show a catalog to customers and they evaluated the the best way to browse and filter. Sow the same screen to the devs and they would evalute the performance of the catalog. We would also brainstorm the "what-ifs", such as how will the catalog perform when there's a billion items in it ... etc. We got better at teasing out the key risks before we hit them.
Building the software became more an exercise of instantiating the user experience versus leaving too much to be made up on the fly.
To "be the software", it's as simple as letting the user walk through the user experience of performing that task (via the slides), and, as John put it, "you be the software ... you simply state how the software would respond." If slides are too heavy, draw on paper or use a whiteboard. The outcome is the user gets a good sense of what it's like to use your solution, while you get a sense of the user's more specific needs. The interactive approach produces way more benefits than a simple spec review or 1/2-baked prototype.
PingBack from http://paidsurveyshub.info/story.php?title=j-d-meier-s-blog-be-the-software