A recent Ajaxian post asks how developers prototype their apps., in addition at the recent Future of Web Design conference this also came up a lot, with designers and developers weighing up the benefits of designing with design tools or jumping straight into the code. Preferences really vary, so I thought I would throw my thoughts out there.
If I was asked the question "How do you prototype your Web apps?" then my answer would be simple - it depends!
Designing Visual
In my professional and personal design work it really varies, mainly down to what I am developing - if it is a site where design is most important then I tend to jump into Photoshop and begin thinking about design elements; taking inspiration from various sources such as Smashing Magazine, interesting photo's on Flickr and artistic styles. This helps me put together a creative direction in my head which I can then refine and experiment with.
Often in these cases I would spend a lot of my time in Photoshop (and/or Flash if we have interactive elements) refining the concept before following the traditional approach of cutting graphics and building my XHTML and CSS. I find this tends to work well for sites where you are trying to do and communicate visually, and when you are working with a page/system which already has well defined layouts for content - so for example when you are re-skinning a blog or designing a product landing page.
Designing Process
If I am working on an application which is either transactional or data orientated, I'll often take a very different approach to my design and prototyping.
Many applications have a finite number of states, so for example on a very basic level Amazon has category landing pages, product list pages, product pages and the checkout flow. I would first try and list out the set of states for an application, and then create a rough 'napkin-sketch' of each, either on the back of an actual napkin or using a quick and easy wireframing tool such as the excellent
Balsamiq. This helps to get thinking about the components of an application up front, ensuring that you have covered all of the use-cases and hopefully prevents the situation where at the end of the design you realize a feature has been missed and you need to go back and try to retrofit it into the application.
From their I tend to move straight to XHTML/CSS, getting the layout setup and beginning to focus on the 'feel' and interaction a user has with the page page. This I find, especially when designing a transactional process, helps to stay focused on the underlying goal of the page which is often to support a user in completing a task or driving an actual conversion.
Working direct with XHTML/CSS really emphasizes the interaction portion of design - at an early stage you can see how a user will move through the process and identify any bottlenecks or any opportunities.
This is also the stage where you can also start thinking about behavior - how can you use JavaScript (or Flash) to enhance a transaction? This may be as simple as prototyping how an Ajax auto-completer could be applied to a form field, to visually experimenting with how a page is displayed.
By adopting this high-fidelity prototyping approach, you also generate reusable code which can be worked into the final design in addition to artifacts which are often more value when it comes to presenting to clients and usability testing.
