Need Ideas for WireFrames and/or Functional Specs?
Our team has been looking high and low for example of wireframes, Functional Specs, Design Specs, etc. that fit into our process here. Unfortunately I have not found many examples posted out on the World Wide Inter-Web. The best example of a "toolkit" that I can find is at the IA Institute. But still, nothing we found there tickled our fancy.
I'm sure there are other people searching for documentation ideas as well so...I am going to post our process here (Fortune 500 company with one of the "top 10" commercial websites on the web). The main focus of this post is to show you an example of Functional Specs and Wireframes/Comps that fit nice and snug together with those specs.
Here's our process in a nutshell:
1)Business people "The Suits" and the project manager get together and decide they want to redesign or make a whole new web application. They then meet and come up with Requirements. Out of this meeting comes a Scope document detail at a high level what needs to change.
2)The IAs review the scope and we have a brainstorming session about what we want to do...along with the design team.
3) The IAs work on Wires and maybe a little prototyping using Axure...and once that's going we start the FIS (Functional Information Specs) which I will show you an example of. The Specs detail absolutely everything: what happens when you click on this, when you click on that, if you have to be logged in, what errors you get for any type of action, default values for fields, etc.
4) The FIS, wires and prototype are then sent to the designers who make "comps" with the materials we gave them. We make sure the designers have an idea of what should be most prominent on the page and we basically just check in once in a while to make sure there are no usability concerns and make sure that standards are being followed.
5) Once the designers have something, they show it to us and we work back and forth on feedback.
6) Once satisfied with eveything, the designers take those comps and build the html, find the pretty little images on stock sites, build the style sheets, etc.
7) Then we have Developer Handoff. This is when we give the developers the FIS, Wireframes and HTML. We also give them comps, which are the screen shots of the HTML.
The FIS:
Made with Adobe InDesign.
These are the business rules. I tell the developers exactly what to do for everything. Figures are labeled by letter and everything from Browser title to the Footer is called out. At the end of the project this also serves as official documentation.
Text is using black text. Anything dynamic like maybe images, fields, drop-downs, etc. have [brackets] surrounding them with a corresponding definition for the developers to code to.
The QA team will also build their testing plan based on this while the developers are working their magic. The QA team pretty much makes a testing scenario for every "green" rule.
The Wire:
This is normally what I send to the designers so they have an idea of what we need. However, when the design work is done we will use the nice screen shot comps of the finished HTML to show the developers/business during handoff to them.
Right now I have no place to post this for download. If you would like the .indd file for this, please mail me. I will be more than happy to send it to you.
For the Visio wire, I used some storyboarding shapes that I got from Bryan and Jeffrey Eisenberg, authors of "Waiting for Your Cat to Bark?". The shapes are very helpful and make wires much easier. I'll be happy to send those to anyone interested.
I'm sure there are other people searching for documentation ideas as well so...I am going to post our process here (Fortune 500 company with one of the "top 10" commercial websites on the web). The main focus of this post is to show you an example of Functional Specs and Wireframes/Comps that fit nice and snug together with those specs.
Here's our process in a nutshell:
1)Business people "The Suits" and the project manager get together and decide they want to redesign or make a whole new web application. They then meet and come up with Requirements. Out of this meeting comes a Scope document detail at a high level what needs to change.
2)The IAs review the scope and we have a brainstorming session about what we want to do...along with the design team.
3) The IAs work on Wires and maybe a little prototyping using Axure...and once that's going we start the FIS (Functional Information Specs) which I will show you an example of. The Specs detail absolutely everything: what happens when you click on this, when you click on that, if you have to be logged in, what errors you get for any type of action, default values for fields, etc.
4) The FIS, wires and prototype are then sent to the designers who make "comps" with the materials we gave them. We make sure the designers have an idea of what should be most prominent on the page and we basically just check in once in a while to make sure there are no usability concerns and make sure that standards are being followed.
5) Once the designers have something, they show it to us and we work back and forth on feedback.
6) Once satisfied with eveything, the designers take those comps and build the html, find the pretty little images on stock sites, build the style sheets, etc.
7) Then we have Developer Handoff. This is when we give the developers the FIS, Wireframes and HTML. We also give them comps, which are the screen shots of the HTML.
The FIS:
Made with Adobe InDesign.
These are the business rules. I tell the developers exactly what to do for everything. Figures are labeled by letter and everything from Browser title to the Footer is called out. At the end of the project this also serves as official documentation.
Text is using black text. Anything dynamic like maybe images, fields, drop-downs, etc. have [brackets] surrounding them with a corresponding definition for the developers to code to.
The QA team will also build their testing plan based on this while the developers are working their magic. The QA team pretty much makes a testing scenario for every "green" rule.
The Wire:
This is normally what I send to the designers so they have an idea of what we need. However, when the design work is done we will use the nice screen shot comps of the finished HTML to show the developers/business during handoff to them.
Right now I have no place to post this for download. If you would like the .indd file for this, please mail me. I will be more than happy to send it to you.
For the Visio wire, I used some storyboarding shapes that I got from Bryan and Jeffrey Eisenberg, authors of "Waiting for Your Cat to Bark?". The shapes are very helpful and make wires much easier. I'll be happy to send those to anyone interested.
posted by basin at 2:04 PM
0 Comments:
Post a Comment
<< Home