himalia.net | community blogs

From a long time ago I wanted to post about this topic because it is one of the features I love about the way we can build the user interfaces with Himalia.

Iterating From Paper

Many studies have shown the importance of early prototypes. Actually, recent articles point to paper prototyping as one of the best tools for the development of user interfaces, in a cost-benefit point of view, because it helps to point the UI in the right direction from the beginning at a very low cost (if you don't use it, you may be very wrong, too late).

But paper prototyping has some problems, most of them related to accuracy and imagination:

1. you can't test interaction in a reliable way
2. what you see is not what your get; but mainly, is not what the user see
3. once you have started with the development, paper-prototyping becomes more and more expensive
4. once you have prototyped, you have to translate it to code (and you know that translations produce errors)

I think it's similar to the problem we used to have with integration of software before Continuous Integration, so, a similar solution could make sense also here. Note that what makes continuous integration possible, is the fact we have a tool who knows the process used to create software. That is, our integration server knows about check-ins, tests, fails, people, etc and use them as first-class citizens in the process. I think that more and more tasks in software development should be made as frequent as you can, and automatically when it's possible.

If we wanted to take this approach in the user interface field, I would like to have a tool who knows about prototypes, and let me:

1. start with a little one
2. load most used layouts and patterns from a repository
3. change the initial prototype through many steps
4. test interactivity from the beginning and in each step
5. iterate in seconds from the changes to the user-feedback
6. build the final version as an evolution of the initial prototype (I don't want to throw more paper to the bin)

Getting feedback

One main aspect that should be considered, is that the prototyping task is not finished once you release your application. In other words, usage analysis and statistics have changed the way web applications are built today (and probably part of the commerce' history), turning marketing into a tangible discipline.  World-class web enterprises are already doing "continuous prototyping", regardless if they use this term or a specific tool in the process. Sites like Netflix, Amazon and Facebook are continually modifying the user interface in order to better adapt it to the user needs or/and add new functionalities. 

I think it is obvious, but I will say it anyway: not only web user interfaces should adapt itself from users. The user is the same, regardless he is watching the application inside a browser or not. However, while in the web we can just add a simple javascript to all the pages and get a good analysis, you can't achieve it easily in the desktop (mainly because it lacks of the "addressability" concept).

Putting All Together 

So, in order to accomplish both things, we need not only a good tool in the developer side but also a good framework in the user side to make the full story available for us, because feedback is -at least- as important as early-prototypes.

Prototyping should not be seen as the task involved in building an artifact, but as the continuous process of adapting the user interface to the users needs.

In this way, everything we can do to reduce the time from the development to the user feedback, is going to give us more time to do more iterations, and as with continuous integration, each iteration will increase the quality of our "final" product. 

Labels: Guilder, Himalia, Prototyping

# posted by leovernazza : 10/15/2007 11:17:00 PM