In this, my last post in the series (continuing from Part I and Part II), I explore what questions we’ve been asking when considering rapid prototyping tools (not just purely for mobile applications) and what we’ve learnt from it.
You’ll certainly want to ask some questions before investing a rapid prototyping tool for mobile applications. Every tool has its own features – weaknesses and strengths. Explore these fully before making the (not large) investment.
- Is the tool easy-to-use? Or does it have a steep learning curve? Would users need training, and of what sort before becoming proficient with the tool?
Can it be adapted across a variety of design projects?
While answering these questions can definitely point you in the direction of the right tool, you’ll want to involve all stakeholders in the discussion and decisions on the final purchase. While the design team will be the primary users, it’ll need support from all quarters to be up and functioning smoothly. Be clear in setting expectations, both from the prototyping process and the prototype itself. You don’t want to get into an endless cycle of changes to the prototype. As you go along some way with using the tool and have built some prototypes consciously reuse component to reduce the time spent on prototyping. Know where you are going with the prototype – that it’s a prototype and not the actual solution. You may find that some of the expectations on fidelity are unnecessary.
Don’t include imaginary elements and controls in your prototype that may be impossible to recreate on the actual target mobile platform. An example – the use of multitouch, when the device touch capabilities do not offer support for it. While this may seem really obvious, speak to developers before prototyping; better still, involve them, their developer’s view will offer insight that might just lead to a more realistic prototype.
Prototypes are reviewed by multiple stakeholders, be clear about what review is expected, and what is acceptable and what is not. Try to get stakeholders doing reviews to be objective rather than subjective. It’s easy to say ‘I don’t like the text style for the title’, difficult to say ‘why and offer an alternative’.
Lastly, a prototype doesn’t really need to include every bell and whistle the application might possibly have. Keep in mind you don’t have to prototype everything.
_____________________________________________
Here’s a link to some interesting tools you might consider using when prototyping for the iPhone or iPod Touch – http://www.henkwijnholds.com/sketching-prototyping-tools-iphone-apps/sketching/
