Prototyping is Like An Onion – It Has Layers

Recently, I’ve had to create several in-depth interactive prototypes, and keeping all the various designs and interactions straight was a bit of a daunting task. Especially when the level of interactive fidelity was high. To ensure that I hooked up every piece of interaction and wrote every logic case needed, I took the development of the prototypes step by step, or layer by interactive layer. This post is  a brief description of the process I followed. I’d be interested to know how this relates to your own process and any other comments you might have.

My first goal was to make sure the prototype was a complete click-thru of  all the designed pages. Now, this doesn’t mean I made just the main navigation click-able, but I also linked up any cross link opportunities too. Once I verified that all of the pages were linked together and could be traversed, it was time to move on to the next layer of interactivity.

Developing the various states for each page was next. Since I was using Axure, this meant I broke out the Dynamic Panel and used it anywhere particular components of a page changed given the right conditions. This was the part that took the longest, as I had to work out all the various iterations of the same controls.  I didn’t worry too much about the specific conditions needed for the various states, as keeping track of all the logic in my head was distracting. At this stage in the game, it was  important that I got all the finer details of the interactions designed out.

Now that all of the pages were linked up, and the states created, I got started with the really intensive stuff. Getting the detailed interactive logic done was the final layer to my process. The first bits of logic I tackled were those that effected the whole prototype. A prime example of this was the logged in/logged out states, which requires multiple layers of logic to ensure that it properly affected the whole prototype. Once these general logic cases were covered, I tackled the individual cases present in each page and state. These prototypes were of decent size, so I kept a checklist handy to ensure I didn’t miss anything.

This entry was posted in Interaction Design and tagged , , . Bookmark the permalink.
  • http://www.scottcorgan.com Scott Corgan

    True. It seems there are several sites posting on prototyping today…

  • http://twitter.com/mattrea Matthew

    Nice post. Conceptually I think you're right on – and I think you could extend the “layers” analogy up a few levels.

    Prototyping itself is a tool that lets you find the “unknown unknowns” in designing any interactive system. If an organization or group relies solely on specification documents or static requirements, there is a good chance only the outer layer of the onion has been peeled off. Only when the system is actually in the implementation phase, will most people see the inner layers and challenges. Unfortunately, by this time it is often too late, schedules can slip, or corners are cut to quickly “solve” the problems.

    Building in time for prototyping and refinement can seem like a waste of time to people building project schedules and spreadsheets. I believe there is a misconception that if you just think about these problems hard enough, you can uncover all the possible issues and design a great experience. However, the truth is that when you are creating a rich experience within very complex and sophisticated underpinnings, you need that prototype to inform your design decisions.

  • http://bnunnally.tumblr.com Brad Nunnally

    Thanks for the comment Matt, and you are spot on.

    I must have failed to mention that this whole process is down “at once”. Before handing off the prototype for detailed design, or development, all the rich interactions and logical states are documented. Plus, the prototype itself doubles as it's own documentation.

    Great points though about the importance of refinement. That's one step in the process that gets cut out way too often.

  • http://twitter.com/PimpIA Pimpformatn Archtct

    This might be obvious, but what you described is exactly the sort of way most software engineers would tackle implementing a solution. You took a top-down approach.
    (http://en.wikipedia.org/wiki/Top-down_and_botto…)

    Although you make a passing reference to it at the end, keeping some sort of checklist is crucial. Coders sometimes keep these notes as comments in the code itself, especially if multiple people are collaborating on it. (Prototyping tools don't seem to really offer that level of functionality yet.) But even if I've left notes in code, I always prefer to keep my own list too, just to make sure I don't miss something that can come back to bite me later. Plus, it's satisfying to mark things off!

    Thanks for posting. It made me realize that my previous career is actually kind of useful at times. ;-) It's always great to see how people approach things too.

  • http://profiles.yahoo.com/u/FGXK75FYDDFFL356ZP2DI54LEQ Robert

    Sounds like a sensible approach. I also use Axure to build prototypes of varying complexity. My top tip when dealing with a lot of dynamic panels is to use the 'move' interaction rather than 'show' and 'hide'. This allows you to layout all your overlaying dialogue boxes in a visible state, making it much easier to edit them.

    I blogged about this in more detail here: http://www.ux-press.com/2010/04/remove-clutter-…