Thursday 3 June 2010

Living prototypes

Recently on a project we had the pleasure to work with a colleague of mine Alex McNeil, in what I thought was a very interesting and successful way of developing UX friendly designs.
The story starts off with a familiar tale, we had just been given a set of designs from an external design agency, which according to the client developers had a history of excruciatingly painful changes. Even more so, was that the so-called "web" designs, were semantically incorrect, ie having a radio buttons for optional choice fields, or standard editable text fields for static read only data.

The marketing department loved this design agency and would fall into the habit of requesting 1001 changes, which would ultimately blend changes in behaviour as well as aesthetics. The poor developers would only find this out through constant revision after revision of print outs of the designs, just to notice that "that check box is now a radio button, because the field is no-longer optional". You get the picture...

So how did we turn this around?
  1. Taking control of the designs - almost day zero of the project we took ownership of the designs and proclaimed that all changes must now go through our designer Alex, the BA and developers. Changes were still welcomed, but now we could control their arrival.
  2. A Living Prototype - this idea was born from chance more than anything during the project inception after estimates were presented to the client. In short, our estimates were far too long, in fact they needed it done "next week", an impossibility! The client would not move on this date, and when asked why the date could not be moved it was due to a national sales conference. They needed something to demo. Ahah! What we needed was a living breathing working prototype (more than a wireframe), that looked and behaved like the real thing but could be done in a week, whilst the real application proceeded along it's merry way.
So how did this work technically?

Although we were using Asp.Net MVC and string template, this same technique can apply to any templating engine that allows you to partition and include sub-templates within other templates.
We first created a "Demo" controller, from which Alex could begin working from and creating static html templates, styling and any "fake" javascript functionality. The master page and sub templates which were to be shared later on, were placed in relevant view folders matching the expected future controllers.

/static/js/demo.js
/static/css/real-style.css
/controllers/DemoController.cs
/views/Shared/master.st
/views/Demo/index.st (drives out sub-templates, master.st and real-style.css)
/views/Demo/page2.st
/views/Demo/page3.st
/views/Real/indexSectionA.st
/views/Real/indexSectionB.st
/views/Real/page2SectionA.st
/views/Real/page2SectionB.st
/views/Real/page3SectionA.st

As stories were picked up and played and "Real" controllers introduced, the new pages could pick up the shared sub-templates (with styling) and inherit all of Alex's goodness. More and more of the sub-templates were included as more and more functionality delivered.

/static/js/demo.js
/static/css/real-style.css
/controllers/DemoController.cs
/controllers/RealController.cs
/views/Shared/master.st
/views/Demo/index.st
/views/Demo/page2.st
/views/Demo/page3.st
/views/Real/real-index.st (uses sub-templates, real.js, real-style.css)
/views/Real/indexSectionA.st
/views/Real/indexSectionB.st
/views/Real/real-page2.st
/views/Real/page2SectionA.st
/views/Real/page2SectionB.st
/views/Real/page2SectionB.st

As complexity grew in the "real" controllers and changes in the type of data sent to the sub-templates, the demo controller was brought up to standard so that it could send equivalent data into the view.

The greatest benefit of this living prototype method is that, because the app could be demonstrated working much sooner, it enabled many iterations of feedback before the actual stories had even been played. This lead to far fewer changes in behaviour at implementation time. Given the chance this is a technique I would definitely use again in the future.

5 comments:

  1. Funnily enough I had been playing with a similar idea for a similar project...

    I really like the idea of using string template for prototyping as it has some useful features (like sub/master templates). However, unlike webforms/SSIs you don't get a servable website without having a site yet (or at least a demo controller with all the right actions).

    I came up with this:

    http://github.com/jennifersmith/stringtemplate-prototyping-mvc

    The idea is, it matches paths (like /Sample/Home/Index) to views under the view folder (Views/Sample/Home/Index.st). Then the prototyper can just go on sticking more and more templates in and you can view them in the browser.

    ReplyDelete
  2. Looks interesting Jen. This would have worked well for us for the first week or so however, as many of our sub-templates grew reliant on form data being passed of a certain type. Renderers would then render the associated template for that type. Therefore a "demo" controller or in your example "Sample" was required to pass dummy objects to the view.

    However this did enable our living prototype to continue all through-out the project and provided to place for Alex to rapidly showcase changes.

    ReplyDelete
  3. As a hands-on UX designer, I've always worked this way and am glad to see more people adopting this methodology. IMO this is the only way to really get agile and UX playing nicely together (although it's hardly sufficient for success, but that's another story).

    ReplyDelete
  4. The poor developers would only find this out through constant revision after revision of print outs of the designs, just to notice that "that check box is now a radio button, because the field is no-longer optional". You get the picture.
    RevitaDerm

    ReplyDelete
  5. Your post have the information that is help full and very informative.
    alluria

    ReplyDelete