Getting excited

Recently we started a new freelance role as an Experience Architect at a top London digital agency. We've been working across numerous challenging e-commerce projects. One particular project involved exploring the user experience for a responsive checkout as part of the wider e-commerce redesign.

Our first reaction was to get excited about the prospect of being able to push the boundaries, not only in terms of redefining the user experience but also in the way in which we approach the development and documentation of it.

Due to the responsive nature of the project we didn't want to create multiple static wireframes to illustrate the way in which the interface would respond to different user and device contexts. So we decide to develop an HTML prototype instead. Enter Twitter Bootstrap.

Enter Twitter Bootstrap

There are many responsive HTML/CSS frameworks out there, but one of our favourites is Twitter Bootstrap due to the ease/speed of development, the quality of documentation and also its slick visual appearance.

We began the process of developing the prototype by sketching with good old pen and paper. After various revisions we opened up Coda and started scribing some HTML. After various iterations with feedback from key team members the initial release was ready.

Documenting user journeys

After the initial prototype was completed we moved onto documenting the different user journeys. Now you could argue that this step is a little redundant. But it's almost a case of appeasing the client by bridging the gap between old skool wireframes with loads of annotations to having a prototype with no documentation.

There were two main user journeys for registered and guest users. As part of the documentation process we simply took screenshots of the different states of the prototype, dropped them into OmniGraffle and annotated the key interactions along the way. The purpose of this was to have a document that supported the prototype that gave key insights into how the prototype served the needs of different users, rather than to document how a menu/navigation item works.

In our opinion it is much better for both the client and us to build prototypes for them to play with than to mock up a static wireframe and annotate it to describe how it works.

The benefits

By developing a prototype with Twitter Bootstrap (instead of creating static wireframes) we managed to:

• Speed up the UX design process, cut costs and the pain of amending a large static wireframe document.
• Produce a consistently styled interface.
• Produce a reusable codebase for the development team to work from.
• Improve the client's understanding of the UX though the creation of a more tactile artifact (rather than a static wireframe).

Conclusion

We love prototyping and having the chance to bring our coding skills to the table and integrate them into the UX design puts a big smile on our faces. We're slowly seeing more and more agencies come round to our way of thinking and get their clients on board the prototyping train.

We're not saying you should abandon static wireframes, but with each subsequent project we work on we're seeing more and more value being created though the refinement of our process.

We'd love to hear what you think? Are you a prototyping guru? Or a staunch static wireframer? Let us know via the comments form.

Posted in: BlogDevelopmentInformation architectureUser experience

Tags: Information architecturePrototypeTwitter BootstrapUser experienceWireframes