A process I went through a lot in my years as a flash developer went approximately as follows:
- The client/agency would supply a finished design of a flash site (with complex interactions specified)
- I’d question the interaction ideas, but my questions would be dismissed and I’d have to build the entire site to a full working version
- The client/agency would see the finished version, but be unhappy with the interactions (which they had designed)
- 50+ rounds of changes that involved me rebuilding and refactoring huge chunks of code until the client was satisfied
What caused this problem in most cases was the lack of allowance early on in a project for prototype time.
I love prototyping – it’s great to be able to get a working model of an idea up and running and iron out (or dismiss totally) any issues that arise well before you get in to production.
So… right now I’m working on a few different iPad concepts that involve the same general principles:
- Adding items to a scrollable list from the a library of items
- rearranging said items
- dragging an item onto another area of the interface to update its properties
While I’ve espoused the advantages of paper prototypes in the past – I’m finding it difficult to model complex interactions like multi-touch and drag+drop using lo-fi models. With complex interactions speed, responsiveness, and device limitations are extremely important things to test.
To get around this issue I’m trying a new prototype workflow: as I come up with an interaction that doesn’t suit a paper prototype, I’m building a small, standalone prototype that I can use to test the idea accurately without investing too much time building fully-functional parts of the interface:
The additional advantage of working this way is that while I’m in the design phase of these projects I’m still keeping up my coding practice (I’ve still got a lot to learn with Objective-C) – each little prototype is a discreet programming challenge that I can commit to without worrying or getting overwhelmed. Each prototype I make is also helping me build up a library of interaction code that I can use in the future if I decide that the idea doesn’t suit this particular project.