What is needed in a web site's wireframe?

Question

I'm going to be going to be meeting with a number of programmers and custom software companies to get bids on creating a website for a company that I'm involved with. My question is this: What should I prepare for the programmers so that they can give me an accurate bid, timetable, etc. for the development of the website? I have a clear picture of how I would like the site to work and the features that I would like to have included.

Answer 1

The best you can do is to put the end-user's hat on and describe what you'd like the system to look like / work.

Imagine all pages and create a new frame for each one. Make as many annotations as you can so all bidders know exactly what you are expecting.

I'd also add at the end if it's likely the site's requirements to change during development, so everybody's warned in advance.

Answer 2

Details Details Details. You might think you have a clear picture, you don't. You need to write every single step down no matter how trivial. You will see there are things you haven't thought of.

Try to write down as much information as you can think of. Go through all the scenarios a user would when using your site. Use steps such as

1) User clicks on Buy Button

2) Screen shows up with 4 items, Link to details, price, quantity and a 32x32 thumbnail.

2a) If User clicks on thumbnail full resolution image i s displayed etc etc.

Don't try to gloss over the "simple" stuff and you will get the most accurate bid possible!

Answer 3

Basically draw out what you want (ie textboxes, drop down lists, controls, etc) in very simple manner. Then add little numbers around each area that has some functionality. In the margins or on another sheet, describe each point you numbered on the controls with simple instructions on how that functionality should work.

Think of it as a skeleton to describe the application you want.

Answer 4

I'd suggest using something like balsamiq to put some simple sketches together as suggested elsewhere.

Quite often the act of putting your requirements down on paper in a way that represents the actual site will flush out all manner of issues you hadn't considered before, and will give you a much clearer understanding of what you're after.

Also consider the sources of the data you're displaying. From a functional spec aspect, simply saying something like 'show this figure here' is easy. From a programming point of view, coming up with the figure in the first place is often the hard bit.

Answer 5

Not a complete list, but here a couple of thoughts:

Do not forget the back button. Back button behaviour is an issue on every site I've ever worked on. Specify exactly what you want to happen on every page if the user gets to that page by hitting the back button. Often it's easy, but sometimes it is not at all trivial.

Security: Do people need to log on, how, how do you create accounts, reset passwords etc. What pages need you to be logged on, what happens if you hit those pages without being logged on.

Answer 6

You could read Joel Spolsky's Painless Functional Specifications for ideas, but I've just tried to summarise what that means for web software too.

I usually do this in 3 stages:

1. a list of contents, under the headings they'll appear on the site. Get this firmly agreed by all parties before doing any wireframes;

2. a greyscale functional wireframe in plain HTML/CSS, using examples of real-world content and dummy static pages for dymanic content, with everything where it should be. This is the first thing programmers want to see;

3. a purely visual graphic mockup of each type of page - this is the next thing programmers like to see, as in 'show me how you want it to look and I'll make it happen'.