Last week I introduced the three main document types that I use when designing a User Interface; Information Architecture diagrams, Static HTML mock ups and State diagrams. I started off by writing about Information Architecture diagrams in: Documenting the design os a web application - Part one: Using Garrett’s Visual Vocabulary for documenting the Information Architecture design. This week I’ll explain why I like to follow those diagrams with static HTML screens.

From sketch to screen

While Information Architecture diagrams are great for giving everyone involved an overview of a system, and even a detailed map of functional areas, nothing beats opening an application in your browser and clicking around it to get a feel for how it will work and how it will look; enter Static HTML mock ups.

Before I continue, I should explain (for the sake of clarity) what I mean by static HTML mock ups: By static I mean not dynamic, not PHP / ASP / JSP / rhtml pages that interact with databases of any sort. I mean “boring”, old school, plain HTML with standard anchor elements for hyper linking between documents to show how dynamic versions of the screens would work.

I’ve seen mock ups of applications done in numerous ways; paper prototypes, PDF prototypes, Photoshop mock ups, HTML mock ups and even real, working, quickly-knocked-together-coded prototypes. For me HTML mock ups are the best choice for four reasons:

1. HTML and CSS are where my skills lie, it’s really quick for me to put together some screens and make something useful for clients and developers using plain old semanticHTML and CSS
2. having screens in front of them in a browser requires no imagination on a client’s behalf. What they see is what they will get
3. by working in HTML and CSS, once the design is finalised I can hand the files over to our developers who can worry about how they make the business logic and the like work, and not have to worry about working out how to translate what I gave them into working HTML
4. it’s not too much effort to build or modify static pages, yes it can be tedious should something like a navigation link label need to be changed on a few hundred static pages, but it doesn’t take days.

Now, I’m not saying that this method will work for everyone. You have to use the tool that suites the job. This works for me, our clients and our development team.

From paper to prototype, in one simple step (kind of)

To say that I jump straight from the Information Architecture diagrams to working HTML mock ups would be a slight exaggeration, but only a slight one. The reality is that I take the structure and overview of the application provided by the IA diagrams, along with the branding of the client and combine them to work out: the interface, navigation and information design followed by the page layout, colour palette (if this is not already fixed thanks to the clients branding guidelines) and typography (ditto).

All that is done in a very short period of time (normally hours) by sketching very rough (37 signals style) outlines of designs, that I then directly translate into HTML.

At this point you may question why I don’t use these sketches as paper prototypes with our clients? The answer lies in bullet point 2 above; sketches are great for showing designers what something will look like and for working through an idea quickly, but not so great for clients. Clients are not so good (in my experience) at seeing a sketch and imagining it as a working interface (possibly due to my bad sketching?…). I much prefer having them looking over the designs in a browser as they would be where it the final product.

So the point of the above ramble is that moving from IA diagrams to static HTML pages is very quick, simple and results in pages that have been tested cross browser, cross platform and against the WAI accessibility guidelines (as much as they can be) and built with semantic HTML and CSS.

Each functional area of the application is represented by a collection of HTML pages, each named to reflect which box they represent on the IA diagrams for easy reference, for example “10Login.html” for box number 10 in the diagram. Each one has links that allow people to move through the mock up and see how the application should react to their actions.

For pages that may have more than one state (more on that next week), for example pages that contain input forms will have a “normal state” and an “error state”, I mock up both versions (naming them along the lines of “Login.html” and “Login_Error_State.html”) so our developers can see how the mark up would vary between states.

There is a down side

I’m happy to admit that this approach would probably not be the best one for applications that have 1000’s of screens, as the creation and maintenance overheads would be too much. I’m yet to work on such a system (so far at ProcServe I’ve built about 200 or so screens for our mock up which is manageable), so I’ve not faced this problem. Having said that I still believe that even in a “1000s of screens” situation there would be value in mocking up at least a portion of the application in this way.

Happy clients, happy developers, happy days

The advantages of prototyping, and getting something in front of a client early on in the development cycle have been written about over and over again, I’ll not repeat them here. For me the most important advantage of documenting a design in this way is that it helps me communicate a design to both my clients and our development team using the same documents, while leaving little room for misunderstanding.