

The Process of Wireframing a Web App - stkhlm
http://nathanbarry.com/wireframing-web-application/

======
pan69
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.

~~~
nathanbarry
That's interesting. To me it seems like a long process, but if you can't
afford mistakes and need the client's approval it may make sense.

Thanks for sharing!

------
nathanbarry
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.

~~~
adrianhoward
I start as you do - paper first ;)

Sometimes I start even simpler than your initial sketches and just think about
the things I want on each page and how much emphasis I want to spend on them -
using little bar charts ([http://adrianh.posterous.com/little-bar-charts-to-
show-page-...](http://adrianh.posterous.com/little-bar-charts-to-show-page-
content-ratios))

From the looks of it I stay on paper a bit longer than you do. I find I can
iterate on paper, and do paper prototyping, faster than I can mess with
Photoshop or Balsamiq.

From there I usually jump straight to code (I come from a dev background and I
find I'm more productive there than I am with tools like Axure).

------
jarjoura
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. :-)

~~~
nathanbarry
I like using printer paper without lines.

The dotgrid book is nice because it is spiral bound so there isn't a mess of
papers. Most spiral bound books have lines which suck.

~~~
culturestate
If there's a Muji near you, check out their spiral-bound sketchbooks - I use
the A4 version[1] and really enjoy it.

1\. <http://www.muji.us/store/art-and-craft/sketch-book-a4.html>

------
kaliblack
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.

------
dorseymike
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.

~~~
saraid216
I've known about this method for a long while (back as early as 2004), but
I've always found it easier to actually mock it up in HTML/CSS and then make
changes on the fly. It might be my personal skill level that makes the
difference, but it worked out better for me.

(My favorite design sessions remain the ones where I sat in a room, projecting
my laptop onto a screen, and speed-editing CSS and PHP while my boss made
suggestions at the front of the room. And then I'd go, "So, like this?" and
refresh.)

Not really recommending it so much as saying it's a thing that can be done.

~~~
dorseymike
Yeah that's a good point. Your approach is getting easier and easier now with
stuff like Bootstrap washing away CSS complexity...

------
dictum
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_.

------
jplur
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.

------
CodiCode
interesting, thx for sharing.

