The Process of Wireframing a Web App

I have been using an extra step what I'd to call "Interactive wire frames". The entire process goes something like this:

1) Write down in a few paragraphs the objective of your project. what it is you want to do and what this project needs to achieve. If you work for a client, discuss this text with your client until you're both happy about it. It's this text that's going to define the scope of your project.

2) Set up a requirements and scope document. This document will describes in greater detail what you discussed in the document at step 1 and it's this document that will become your official Scope of Work document. If you have a client, discuss this document with your client and get sign off.

3) Based on the requirements and scope I create wire frames using Balsamiq. If you have a client then discuss the wire frames with your client and get sign of before moving on.

4) Based on the wire frames I now create "Interactive wire frames" using Bootstrap. I basically recreate the Balsamiq wire frames in Bootstrap. This allows you and your client to click through it. The difference between a paper wire frame and an interactive one is that the interactive wire frame will bring out issues early on. Again, if you have a client get sign off.

5) Build. Uh? That's right. At this point I build as much of the core functionality as possible and I use the interactive wire frames for the front end of it. This allows me to fine tune the functionality and to test if all the objectives are met. Discuss with your client whenever you have something significant to demonstrate.

6) Design. Often design can be started during step 5. Very important here, discuss the designs with your client (if you have one) and get sign off.

7) Implement designs and cross browser test. Again, with a client, get sign off.

There is always a debate about how best to move from idea to finished product. This is just my method. Would love to hear yours.

Ryan Singer (37signals) actually jumps straight from sketch to code, but then takes screenshots and brings them into Photoshop when he needs to work on more details.

Find a process that works for you.

I wouldn't bother buying (overpriced) design sketch books. Just find a couple free design templates online that work with your project and print them at Kinko's. I also get them 3-hole punched so they can be easily moved around.

Stickies are also a great way of making notes you can move around on each page and do take advantage of setting meaning to color.

Filling in with matching highlighters can also help you mark actions and flow. Plus who doesn't love a good coloring book moment. :-)

My process helps me clearly understand what the user is trying to do and plays to my strengths, which aren't designing. For each user flow I do the following.

1) State the use case (who is doing what and why)

2) Write each stage of the flow in terms of user request, decision and information they need

3) Very rough sketches

This will throw up a lot of questions, mainly about edge cases, so I write those down separately. When all the main flows are done I start coding.

This is a really helpful outline.

I like your idea of keeping a "features" list and "questions" list separate. Otherwise, it gets confusing when the two get jumbled together.

One tool that most hardcore engineers chuckle at - but that I love for the higher fidelity mockups - is using Keynote/Powerpoint. It is extremely fast to make things like buttons, move text around, etc.

Most importantly, these tools make super easy to make a duplicate of any view and completely overhaul the layout...giving the ability to show users A/B options for the same slide.

Finally, it's easy to export the entire "app" mockup as one PDF file (made of many slides) and share all the mockups with users. I like it as a last step before diving into actual CSS/HTML. I like this more than Balsmiq because it lets me get closer to pixel perfect before I start coding - emphasis on actual look & feel, vs functionality (which balsamiq is probably faster at depicting).

Anyway, great writeup, thx for sharing.

After sketching, I usually design a wireframe with gray boxes, visually flat (like Nathan's wireframes). I've been thinking of replacing this method with HTML wireframes using a simple CSS framework. That would allow me to link between wireframes, and would make it easier to deal with changes.

I've been postponing this for fear that it might add too much complexity and make things harder, but on second thought, it's worse that I have to basically remake my own framework every time I make a wireframe in Photoshop. Creating rectangles in Photoshop is so easy it's mind numbing, but as you work on a wireframe with multiple versions, it gets annoying.

I'm particularly interested in how Bootstrap 3 will look like when it's released, because the preview looks more or less like what I need: flat and responsive. It's not that I want to create visually flat websites, I just want a framework to create visually flat wireframes.

Great to see your working process!

My mousepad is a pad of paper, when a page gets too many notes (or too many coffee stains) it gets torn off.

interesting, thx for sharing.