Design Deliverables for Web Apps or Websites

25 Sep 2009 - 6:37am
7 years ago
1 reply
1682 reads
Paul Bryan

The design activities and deliverables that we produce for web apps
depend on the value to the company of an optimized design vs. an
average design. That doesn%u2019t mean we turn out crap unless
required to do otherwise. It means the background work we do to build
understanding prior to creating the deliverables, and the depth of
detail in the deliverables, have to be worth the cost in time and

While I agree that some of the production values in the deliverables
serve more of a marketing or political function, I think the contents
of design deliverables are also very important in the same way that a
blueprint is important. For a dog house, maybe a pencil sketch will
do. For a high-rise, a room full of architectural specifications are

In a web app we designed for GE that was used at all levels between
practitioner and VP, we documented the following:

- User interviews at all levels
- Audience segmentation and user archetype profiles
- User interface requirements for each segment
- Task flow diagrams
- Interaction modes with mini-screen flow diagrams
- Organizational structure
- Navigation system
- Concept wireframes
- Functional specifications with screen states and error handling
- Design templates

To be effective, the web app design documentation you produce has to
fit in with the development process, and you need to time design
deliverables to be inputs to the development cycles.

The details in the documentation should be greater when design and
development are separated functionally or organizationally. That was
the case in the web app above. The dev team said the documentation
helped them to develop the app very efficiently. A six sigma study of
the app after release showed significant ROI of the design process we

Paul Bryan
Usography (
Linked In:

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new


25 Sep 2009 - 9:38am
Chris Heckler

For web apps we've used similar documentation to what Paul has
described. Sometimes we have a customer requirement to write use
cases that trace to the requirements document. In some cases we get
a rough requirements document from the customer and then add to it as
needs are uncovered through user interviews and testing, and in other
cases we write it. We roughly sort everything into 3 groups of

User interviews, survey results and test results

Requirements document, use cases, concept wireframes

Design document which includes design style info, functional
specifications, navigation and site structure, general info about the
purpose and audience of the app

For our purposes we presented the usability interviews and test
feedback in a summary to the customer. The requirements related
documentation is packaged for the customer and archived for
developers who may work on it in the future. The design document is
what the interaction designer turns over to the app developer.

The web app and desktop app documentation for us is about the same
just adjusted slightly to fit the medium. Like web navigation might
lead to a site diagram, but if we're on a desktop app this might be
a series of task flow charts.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new

Syndicate content Get the feed