Rapid Prototyping Tips and Techniques

There are not many resources on rapid prototyping out there – and it’s often very difficult for anyone who has come from a development background to understand what to scale back on and where to cut corners. So here are some of my technical tips and techniques I’ve picked up along the way.

It’s Only a Prototype!

I suggest that you print the phrase ‘It’s only a prototype’ and paste it to the top of your monitor. Don’t get over involved in the minor details and intricacies of design or functionality where it’s not necessary. Keep in mind the objective of the prototype, and make sure you don’t spend time on parts that won’t be tested. You should rationalise with your IA what details to focus on. It’s all too easy to forget your building a throw-away prototype! Not the real thing!

Use a Framework

With companies wanting more web 2.0 style features and functionality, it makes sense to approximate your prototype to what the final website will be using. If you can find out what library the final website will use, then try to use it as well. It’ll be like a trial build and help find any problems you can pass onto the developers that they may not foresee. You may also be able to implement the actual functionality that the site will eventually be using - making the user testing much more accurate.
If it is undecided or you don't know what the site will use, libraries such as jQuery and YUI which have excellent range of pre-built plug-ins allowing you add common patterns in place within minutes.
For server side, things like scaffolding features can do most of the heavy lifting for you for proof of concept prototypes where the usability isn’t being tested.

Build for Firefox

It’s only a prototype! You shouldn’t waste time with cross-browser compatibility. Make sure you know which browser the testing lab you will use, and that your clients also view in the same browser. It’ll be easier and cheaper for them to install Firefox, than for you to build a cross-browser prototype.
Firefox is very forgiving for rapid coding and CSS, and the Firebug plug-in will make your life much easier. Also Firefox on the PC and Mac are similar enough to not worry about too much extra compatibility for people only on a Mac.

Don’t Cut Corners

Just because it’s a prototype doesn’t mean you should write scrappy code. In fact you should spend extra time to make your code immaculate. Make heavy use of unobtrusive objects, commenting and keep good organisation. Your prototyping will probably need to adapt and have constant drastic changes made to it throughout its life, so keeping you code organised will help you take out or adapt things quickly without ruining other parts of it. You won’t be able to predict how it will be changed, so make your code is as adaptable as possible – and that means keeping it readable, using objects and being organised!

Cut Corners

Prototypes generally have a very short life-span, and are used or seen by a few people, so don’t worry about things like rendering time, delivery time, cross-browser, code optimisation, accessibility, scalability etc. In fact here you can break the rules by using large image files such as a screen shot of a webpage rather than actually building ect. – as they’ll probably be served locally, or can be cached on the testing machine prior to the test, and the test participant will be none the wiser

Databases

If you can get sample data, adding a database to a prototype is a great way to make it behave like the real site, and give test participants a much richer experience, giving a far more realistic test than forcing them thru a fixed path.
Use a 2 tiered approach by combining business and data logic. This will give you many reusable methods for calling specific pre-formatted data at any point in your prototype without having to re-type SQL queries – there isn’t really a need to separate out the Data access from Business Logic.
Make sure your testing lab has reliable access to the prototype server and can access it thru firewalls etc. Also make sure everyone is aware it will be dependent on an internet connection, and can’t be zipped up and run locally from any machine.

Accurately Replicate Site Functionality

Before you start, get a good idea of how the site will be built and what technologies it will employ. Do your best to replicate these as accurately in the prototype as possible. A minor change in functionality may have a radical outcome on the testing results.
For example if the site has some AJAX functionally below the page fold, and you use a page reload to replicate it, the jump to the top of the page may disorientate the user on functionally that may have worked perfectly well using AJAX. Conversely – if you implement it using AJAX, and the developers don’t, then the live site will fail, having tested successfully.

Define the a:visited Colour

Don’t make the moderator clear the history between each test – they have enough to think about! Your prototype shouldn't show any signs of a user having already visited the site. If there is login or stored data, make sure this is reset between each test. –Be careful about saving data to sessions – if the browser crashes, it will be difficult for the moderator to resume the test.

Prototypes Don’t Have to be Throw Away

Don’t get disheartened when all your hard work is discarded at the end of the test. If you’re doing the build as well as the prototype,then you should make you prototype the start of the final build. All your JavaScript, HTML and CSS should be separate – you shouldn’t really have any inline CSS or JavaScript in your HTML. This means that the HTML is your structure, the CSS is your design and the JavaScript is your functionality. Build the wireframes in HTML. Add on the functionality in JavaScript – and here you have a working prototype. Then you need to do is add the design in the CSS – and you have your website.
http://video.yahoo.com/watch/1373808/4732784

Prototype Methods

Existing Site HTML

If you’re working from a live site, you may ‘save as’ each page with all the assets. Try to avoid this method if possible. It can be very messy using rendered code and global changes which will have to be made individually to each page. If however you do use this method, make sure to set all unused links to ‘javascript:;’ so the user doesn’t end up back on the live site, and only link the ones the path your actually going to use. Dreamweaver has a good advanced tag ‘find and replace’ for replacing all href attributes values. Make sure for a dead link you use set the href value to ‘javascript:;’ and not ‘#’ so the page doesn’t jump to the top or the user will think they’re on a new page.

Interactive Screenshots

If pages already exist, such as you’re replicating a path-in on an existing site, or you have full page design from the designer, all you want to do is make one or two links work.
A quick and simple way is to take a screen shot of the website and use an image map.
If you have a section that needs some functionality you may want to overlay an absolutely positioned div tag with content within it. Remember to make the containing tag position relative so it will stay aligned in different browser widths.

Greyscale Interactive Wireframes

It’s worth setting up a reusable style sheet beforehand that you can use for greyscale prototypes. Use the YUI CSS Base style sheet to get good spacing.
For dead links you could set up a links class that looks like this and use it on a span tag:
.links { color: #00f; text-decoration: underline; cursor: pointer; }
Dreamweaver’s library feature is good for setting reusable html such as header and footer bars etc. if your prototype has to be portable, but can quickly get tricky to maintain – However, if you can use server-side technology to render pages each time it’ll give you far more flexibility as your prototype evolves.

High Fidelity

Most of what I have covered above, you should bear in mind when developing high-fidelity prototypes, but remember - It is only a prototype! Don’t let scope creep in and irrelevant details or functionality that won’t be tested take up too much of your time.