次の方法で共有

Be the Software

  • [アーティクル]

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 ....

  • how to filter a large picklist of items
  • how to optimize views based on type of item
  • how to integrate social software features (tagging, rating, ...)

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:

  1. Build modular slideware for visual walkthroughs of task-based features.
  2. Be the software.

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:

  1. We prioritized scenarios that were the most risk for user experience.
  2. We created modular slide decks.  Each deck focused on exactly one scenario-based task (and scenarios were outcome based).  Modular slide decks are easier to build, review and update.  Our average deck was around six slides.
  3. Each slide in a deck was a single step in the task from the user's perspective.
  4. Each slide had a visual mock up of what the user would see
  5. To paint some of the bigger stories, we did larger wrapper decks, but only after getting the more fine-grained scenarios right.  Our house was made of stone instead of straw.  In practice, I see a lot of beautiful end-to-end scenarios decks that are too big, too fragile and too make believe.

For example, here's the slide list for one deck:

  1. scenario - User subscribes to a guidance feed
  2. summary of steps (flat list of the steps)
  3. Step 1.  user finds a relevant item
  4. Step 2.  user subscribes to view
  5. Step 3.  user displays view in RSS reader

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.

Comments