Thursday, May 17, 2007

Iterating user interfaces

Posted by Simon Baker

I like this article about HTML prototyping and agile development . While I wouldn’t call it prototyping, it does advocate building the real user interface iteratively, evolving behaviour based on received feedback, and adding functionality incrementally rather than produce a variety of static mock-ups such as wireframes. We’ve been building user interfaces iteratively. It works best when the creative and Web people are part of the team and are colocated. The benefits include:

  1. Tangible progress is visible. A working application is the only true measure of progress. Clients and stakeholders love to see results, even if they’re evolving. The sooner you have something real to show off, the happier everyone is going to be.
  2. It’s more engaging. Because it’s tangible people can play with it. Their understanding of how it works improves and they can provide better feedback.
  3. It bridges communication gaps. A common vocabulary emerges as people discuss and interact with the prototype, rather than interpret a design document. Communication and feedback are focused and less ambiguous.
  4. It’s more thorough. It’s better to invest a bit more time developing the prototype to gain insight into many variables that are overlooked by wireframes, e.g. state, security, error messages, level of effort, page flow, scripting, etc.
  5. It’s a reality check. You have to consider factors contributing to the total experience, which you might ignore when creating wireframes, e.g. response time, ease of implementation, cost of maintenance, interfacing challenges, etc.
  6. It helps you avoid document debt. You achieve more because you can spend more time with developers evolving a working prototype and receiving valuable feedback, rather than writing and then having to maintain documentation.
  7. Talk is cheap. Typically, meetings and design documents are waste. Start writing code immediately. The sooner you uncover issues, the sooner you can understand them and adjust your estimates, and the sooner you can resolve them, avoiding impact to the timeline.
To develop user interfaces iteratively using HTML prototyping you need to expect and embrace change. You need to write good code because high quality code is easy to change, and you need to maintain a working interface, always. Start small, and employ varying levels of detail as required. And let things evolve.

Being able to change user interfaces quickly gives you an advantage and contibutes to your ability to compete on the basis of speed .

1 Comment

I have mixed feelings about static prototypes. This includes wireframes, paper models and static HTML pages.

The big issue is that they convey a false sense of agreement on the requirements.

In my experience, it is the dynamic nature of an application that causes the most debate - and this is precisely what is left out from the static prototypes.

If you remember the dynamic aspects rather than treat the prototype as a complete requirements document I think it might have some merit.

However, I have also seen many organisations that do extensive photoshop/powerpoint/etc design upfront that is pure waste. This is especially true with enterprisey organisations where it takes months or years to release anything.

So I am skeptical - but just remember the "inspect-and-adapt" principle and you will be fine. Use it only if it works in your context.

Comment by Martin Jul

Creative Commons Licence

Recent Posts

  1. Spark The Change - Innovation Governance
  2. Lean Day London 2014
  3. The Mechanics Of Meaning
  4. Engineering Design
  5. Debugging Grails Database Performance
  6. Grails for Hipsters
  7. Governance - Friend or Foe?
  8. The Energized Work lab is moving aboard ship
  9. Gus Power on the future of software development at The CW500 Club
  10. Agile On The Beach: Session: How Are We Doing?


  1. 2014 (4)
  2. 2013 (2)
  3. 2012 (27)
  4. 2011 (24)
  5. 2010 (31)
  6. 2009 (41)
  7. 2008 (69)
  8. 2007 (152)
    1. December (11)
    2. November (7)
    3. October (17)
    4. September (8)
    5. August (7)
    6. July (13)
    7. June (15)
    8. May (24)
      1. Product Owner and business marksmanship
      2. Say something
      3. 7 faces of leadership
      4. Scrum Master pulls the trigger
      5. Left leg or whole body?
      6. Additional values
      7. Layman's Manifesto
      8. Brian Marick wants to stir things up
      9. Iterating user interfaces
      10. Lessons are learned ...
      11. Quality is ...
      12. How did it get to be so wrong?
      13. Does standardisation suppress innovation?
      14. Is there a better way?
      15. Wake up and smell the complacency
      16. It takes 1 woman 9 months to make a baby
      17. You, organisational hierarchies, avast there!
      18. Story test-driven development
      19. Agile estimation techniques
      20. Fixed-price contracts don't work
      21. Competing on the basis of speed
      22. Testing in agile projects
      23. Jeff Sutherland on tuning Scrum
      24. Talking about agility
    9. April (14)
    10. March (19)
    11. February (7)
    12. January (10)
  9. 2006 (128)
  10. 2005 (63)
  11. 2004 (2)


agile (43) big visible chart (15) conference (43) culture (18) extreme programming (22) leadership (18) lean (47) people (27) planning (17) retrospective (18) scrum (41) story (19) team (30) testing (19) xpday (19)