Prototypes as documentation?

28 Oct 2003 - 1:12pm
10 years ago
6 replies
680 reads
Dave Malouf
2005

Are others finding themselves in the quandry that was expressed in a recent
article on B&A about how wireframes have become the final source of
documentation for design, engineering, and quality assurance?

Here's the link:
http://www.boxesandarrows.com/archives/the_devils_in_the_wireframes.php

I know I am facing this problem.

How are people dealing w/ this? What do people think of Liz's solution?

-- dave

Comments

28 Oct 2003 - 8:30pm
ralph lord
2004

I haven't read the Bank of America article (ha, ha
just kidding, I know it's Bears of Asia. Sheesh) but
we are currently approaching the wireframe/prototype
as an "opportunity" to use a visual medium to carry
requirements. Two primary reasons are that we can get
much better feedback from our user community when we
show them something that looks like a screen (big
documents make their eyes roll back) and secondly
because we are calling our very earliest
mockups/sketches "visual use cases". We're in a
use-case environment and simply by using this term we
get buy-in from the management and developers.
However, the wireframey stuff is meant to complement
the other requirements docs which are generated and
are meant to contain mostly design and behavior
requirements.

RL
--- David Heller <dave at interactiondesigners.com>
wrote:
> Are others finding themselves in the quandry that
> was expressed in a recent
> article on B&A about how wireframes have become the
> final source of
> documentation for design, engineering, and quality
> assurance?
>
> Here's the link:
>
http://www.boxesandarrows.com/archives/the_devils_in_the_wireframes.php
>
> I know I am facing this problem.
>
> How are people dealing w/ this? What do people think
> of Liz's solution?
>
> -- dave
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to unsubscribe:
> discuss-unsubscribe at interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members
> get announcements already)
> http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/

=====
Ralph Lord
User Experience Consulting and Interaction Design
Phone: 770-804-8935
Fax: 775-245-7569

__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/

28 Oct 2003 - 9:10pm
whitneyq
2010

At 01:12 PM 10/28/2003 -0500, David Heller wrote:
>Are others finding themselves in the quandry that was expressed in a recent
>article on B&A about how wireframes have become the final source of
>documentation for design, engineering, and quality assurance?
>How are people dealing w/ this? What do people think of Liz's solution?

Hmm. Why is this a quandry. Sounds like success to me.

More seriously, the problem is finding a way to express both the "pattern"
and the "detailed design" - and ensuring that everyone knows which is which.

I tend to deliver both simplified wireframes that show details of the
structure of the page/screen - especially those that persist from page to
page. This might, for example, show a left menu in greeking text to
identify placement, levels, fonts, colors, etc. I might make some small
cartoons that show a sequence of pages when that will clarify the design.
Then I show re-usable elements. For example, how a left menu is constructed
and changes from section to section. Finally, I create individual views for
either every page/screen or every template.

By the way, in a discussion at the last NYC UPA meeting (James Van Duyne on
patterns), it occurred to me that if a pattern is one design solution to a
generic problem, then the style guide/template is the specific
implementation of that solution. (Left menu is a pattern. White text in 12
point verdana on a dark blue background (etc) is part of a style guide.)

Perhaps the problem is that we are trying to show style specifics, patterns
and detailed screens in a single drawing?

Whitney Quesenbery
Whitney Interactive Design, LLC
w. www.WQusability.com
e. whitneyq at wqusability.com
p. 908-638-5467

UPA - www.usabilityprofessionals.org
STC Usability SIG: www.stcsig.org/usability

28 Oct 2003 - 9:20pm
John O'Donovan
2004

I've had this problem for years - everyone working in the graphic design
tool of choice to mock up wireframes from which a great deal of information
must then be extracted and maintained. Also, as the design changes this
information has to be reverse engineered into the wireframes. Quite often
this is not always done as well and as often as it should be...

What would be nice would be some cross between:

- something easy to use like Denim
- something with high production values like Freehand or Photoshop
- something like a CASE (Computer Aided Software Engineering) tool which
captures information in a structured way

I'm still waiting for this though...

...in the mean time, I started using a CASE tool some time ago for the very
reason you mention and a number of other reasons. Some benefits are:

- It allows me to create screens / wireframes / interfaces / mock-ups using
a library of standard widgets
- If I don't like this look and feel you can import your own or create your
own libraries
- You capture information by attaching properties and descriptions to each
screen component

You can then export:

- Labelled graphical wireframes
- Documentation which contains the wireframes and all the descriptive info
you put in linked to the wireframe
- Clickable prototypes by exporting the wireframes as HTML
- The whole screen map and UI object structure as XML (using XMI standard)
- Loads of other collaborative and design stuff...helps if you know UML
though...

The wireframe can become an early prototype illustrating user journeys by
using the export options.

This is a great way for a team to store and share information through a
central repository. On larger projects it beats the Visio approach.

Being a CASE tool it also intrinsically links the analysts, designers and
developers as they can all extract info from the same repository. Developers
can use the wireframes to make Stereotyped UML classes and related code to
start structuring and implementing what they will build directly from the
wireframes - if you wish.

I have found no quicker way to build a design and capture all the
information and notes about that design at the same time - whilst also not
having that information locked up in a layered Photoshop file.

The downside is CASE tools can be complex and not all are as good as the one
I use at allowing you to create decent interface designs.

Cheers,

jod

----- Original Message -----
From: "David Heller" <dave at interactiondesigners.com>
To: <discuss at interactiondesigners.com>
Sent: Tuesday, October 28, 2003 6:12 PM
Subject: [ID Discuss] Prototypes as documentation?

> Are others finding themselves in the quandry that was expressed in a
recent
> article on B&A about how wireframes have become the final source of
> documentation for design, engineering, and quality assurance?
>
> Here's the link:
> http://www.boxesandarrows.com/archives/the_devils_in_the_wireframes.php
>
> I know I am facing this problem.
>
> How are people dealing w/ this? What do people think of Liz's solution?
>
> -- dave
>

28 Oct 2003 - 9:52pm
John O'Donovan
2004

todd said:
> Chris, you've hit it right on the
> head with this one. I think the most
> effective process is to bring the
> stakeholders, designers, and
> developers together as soon as possible.

Another simple issue related to this is that when designs are translated
into requirements that development teams work off, the requirements are
usually driven by functionality.

That is, requirements wil state "it must do this", "it must do that". They
often don't say enough about how these requiremets should be met - the UX.

If requirements also captured and represented more of the UX issues, this
would ensure that these are retained as elements of the design which are
important to the client / end user.

All related to developing a common language between design and delivery, a
good medium for communnication between the two and inclusive teams which
ensure there is buy in on decisions from all the stakeholders.

Cheers,

jod

28 Oct 2003 - 10:23pm
John O'Donovan
2004

Just thinking on patterns for a minute - better interfaces and reusable
patterns perhaps?

http://www.ftponline.com/reports/pdc/2003/kiely2/

----- Original Message -----
From: "Whitney Quesenbery" <wq at sufficiently.com>
To: <discuss at interactiondesigners.com>
Sent: Wednesday, October 29, 2003 2:10 AM
Subject: Re: [ID Discuss] Prototypes as documentation?
>
> More seriously, the problem is finding a way to express both the "pattern"
> and the "detailed design" - and ensuring that everyone knows which is
which.
>

30 Oct 2003 - 12:59am
Tristan Naramore
2003

Absolutely, yes. Especially when teams are constantly changing. It's
one thing if you're developing products in-house, with a relatively
fixed staff. It's quite another when there are various consultants and
developers involved at different points of the project. Effective
knowledge transfer becomes a matter of great importance.

Another way in which wire frames can become a form of final
documentation is when the original requirements docs are incomplete,
creating a "moving target" situation replete with scope creep and all
its attendant problems. Instead of going back to the requirements,
stakeholders and developers tend to lock onto the easy-to-read wire
frames.

The problem with this approach (which I've encountered on the majority
of projects I've ever worked on) is obviously that wire frames simply
are not designed to hold that much information. What's called for is a
flexible tool that can dynamically track requirements changes and then
present them in a form appropriate to the
stakeholder/developer/designer/user.

CASE tools (which I haven't used yet) sounds like they try to
accomplish just that. But from the descriptions I've heard, the
approach still sounds too limiting. I have to say the best tool of this
sort I've encountered was developed in-house for Ikonic (a web design
agency I worked for way back in '96.) It was a based on Filemaker (!)
and quite successfully tied together requirements, wire frames, graphic
production, html production and QA.

Since then, I've been dreaming of a tool that could standardize the
basic elements of IA/ID. Something akin to AutoCAD for real-space
architects. But so far, no go.

Anybody know of anything like this that's done the trick?

Thanx,
Tristan Naramore

w: InterfaceConsultant.com
e: tritisan at pacbell.net
m: 415-867-4190
h: 415-388-5351

> Are others finding themselves in the quandry that was expressed in a
> recent
> article on B&A about how wireframes have become the final source of
> documentation for design, engineering, and quality assurance?
>
> Here's the link:
> http://www.boxesandarrows.com/archives/the_devils_in_the_wireframes.php
>
> I know I am facing this problem.
>
> How are people dealing w/ this? What do people think of Liz's solution?
>
> -- dave
>

Syndicate content Get the feed