次の方法で共有

Experience-Driven Development

  • [アーティクル]

Note: This article is updated at Experience-Driven Development.

Features don’t necessarily aggregate up to “experiences” and I would argue that today’s winning approach is …

… Experience-Driven Development

… Where experience means user’s can perform their goals successfully… the software makes them feel good and succeed at their goals.  It’s an integration of scenarios + experiences … and persona-based scenarios with goals.

This shifts the focus to lighting up experiences over just shipping features or scenarios.  It also means a focus on “Experience Step-Throughs” to model and prioritize what you ship.  It seems like today’s software success is about shipping the vital few experiences that make an impact.  I know it seems like a subtle shift, but I still come across too many glitches that get in the way of great software … … I think we need “experience-first” … or more “experience-driven.”

Experiences are the differentiator ... you can have scenario parity or feature parity, yet miss the boat on experience.  It's beyond user stories and scenarios with acceptance tests (though that's a good start.)  It's about measuring efficiency and effectiveness of the user experience.

Comments

  • Anonymous
    September 18, 2009
    I agree completely, JD, but I have a question for you. You said that user stories and acceptance tests were a good start. Provided those were written by or with the user, would you say that usability testing is the only missing piece?

  • Anonymous
    September 18, 2009
    @ HL It helps, but users don't always know what they want (latent needs). If the usability testing measures user efficiency/effectiveness against the goal, that's a good start.