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 (2)
  1. HL Arledge says:

    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?

  2. J.D. Meier says:

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

Comments are closed.

Skip to main content