Prototypes as a form of documentation ... What about?

5 Nov 2004 - 4:25pm
9 years ago
8 replies
642 reads
Dave Malouf
2005

Hiya,

I'm a pretty big believer in that prototypes make excelent communication
tools for designers. I'm all but sold.

I do have a question though and I would love to get some assistance.

I have an application where the GUI changes depending on many factors: role,
browser/technology, permissions on objects, type of object, entry point into
the app, etc.

When doing a prototype how do you communicate all these subtle pieces and
still maintain some sort of constraint on the size of the prototype? I mean
the prototype should not be "every" possible view, should it? How do you
"annotate" a working prototype?

-- dave

Comments

5 Nov 2004 - 4:35pm
Listera
2004

David Heller:

> When doing a prototype how do you communicate all these subtle pieces and
> still maintain some sort of constraint on the size of the prototype? I mean
> the prototype should not be "every" possible view, should it? How do you
> "annotate" a working prototype?

I just delivered one two hours ago:

_________________________
1

App

_________________________
2 |< < > >|
_________________________
3 Annotations
_________________________

1 -> the real app prototype/screens
2 -> nav buttons for going through prototype screens
3 -> screen/widget specific annotations/nav notes/etc

Another method is a uniformly colored button that popups comments, that can
be placed near objects in question.

Ziya
Nullius in Verba

5 Nov 2004 - 4:42pm
Chris Ryan
2004

On Nov 5, 2004, at 1:25 PM, David Heller wrote:

> When doing a prototype how do you communicate all these subtle pieces
> and
> still maintain some sort of constraint on the size of the prototype? I
> mean
> the prototype should not be "every" possible view, should it? How do
> you
> "annotate" a working prototype?

For the parts which you have decided to prototype, use "decision point"
screens as placeholders for application logic, and clearly identify
that they are not part of the user interface.

Chris

5 Nov 2004 - 5:11pm
John Vaughan - ...
2004

David Heller said:
> When doing a prototype how do you communicate all these subtle pieces and
> still maintain some sort of constraint on the size of the prototype? I
> mean
> the prototype should not be "every" possible view, should it? How do you
> "annotate" a working prototype?

My clients really like the "self-referential" prototype. I often attach
such annotations to

* mouseOver events <title> for text tags <alt> for images
* (for buttons) a popup can display reference to a business rule; might
describe IF/THEN conditions

I generally try to do as little redundant work as possible. But when there
are a bunch of radically different "views", sometimes you just gotta map out
the alternative paths in detail. Usually these are just variations on a
theme, so it's not TOO laborious. I find the Templating & Librarying tools
in Dreamweaver very useful for maintaining incremental changes across a
large number of iterations of the same basic design. Far more effective to
spell out each iteration than to assume that your audience can fill in the
blanks, based on a single model and a set of instructions.

Another technique - especially useful in a presentation environment - is to
"frame" the prototype screen with a sidebar that contains scrolling field
for ongoing commentary. This allows you to develop context-sensitive
"online help" collateral in parallel.

7 Nov 2004 - 8:13am
Pradyot Rai
2004

On Fri, 5 Nov 2004 16:25:05 -0500, David Heller <dave at ixdg.org> wrote:
> I have an application where the GUI changes depending on many factors: role,
> browser/technology, permissions on objects, type of object, entry point into
> the app, etc.
>
> When doing a prototype how do you communicate all these subtle pieces and
> still maintain some sort of constraint on the size of the prototype? I mean
> the prototype should not be "every" possible view, should it? How do you
> "annotate" a working prototype?

You should consider few things cautiously –
1.You will need to maintain UI deliverables for long time, in exact
accordance with product versions, SRD/BRD needs and other
processes/standards to make your UI group successful
2. Who is your customer – how are they going to reference/use/interpret it?
3. How will you manage the Agile a.k.a cowboy requirements?
4. There may be intermittent releases of the product where
conventional wisdom of prototypes will not work effective, yet you
will have to grab them because they matter to UI/Usability (or people
will expect you to do so)
5. How will you deploy the same process for iterative vs. one-shot design cycle?
6. Finally, documentation is also to serve auditing!

All you have listed is part of design deliverable, sure, but IMHO I
doubt if prototype can handle it as a long run process. I have seen it
closely at multiple places failing. Some of the other artifacts that
complement prototypes are "UI Specification Documents", "UI
Guidelines", "Wire frame Documents", "Usability Requirements" and so
on. May be it will help you take a look at those, especially, the
whole nine-yards of GUI guidelines.

Splitting your documentation needs from prototype is "very important"
if you are doing "interactive prototypes". Some good reasons are – a)
Interactive prototyping and their version control/releases is
difficult (or I would say, I have never seen it working), b) passing
out specifications with prototypes does not get translated effectively
to it's customers. Developers are used to read documents (linear
documents) when they implement the specifications.

In fact this discussion was started few weeks back by me under the
thread "Design Documentation Tools/Methodology". Peter Boersma had
real good answers to some of my questions. He sends a link that may
show you how he manages UI requirements --
http://www.xs4all.nl/~nieuwnet/iasummit/. This is just to show you
some patterns of UI process. I know this may not directly translate to
every context in the industry. But there are many I personally know
who are currently engaged with kind-of-same methodology for real long
time.

All it's about splitting UI documentations/specifications from
prototyping. They both fall under UI Design. UI
specifications/documentation are handled by wire frames, which are set
of representative/all screens. They contain specifications, abstract
prototypes (B/W with boxes & arrows), sitemaps and workflows, actual
text/instructions/labels/data set specifications, etc. They are easy
to be handled by any version control tools. They are tied to same
release numbers as the BRD/SRD. Each wire frames are living objects --
individual pages (static) and have reference numbers, which is useful
from other documents to reference for other business/technical
specifications.

On the other hand, Prototypes are stuffs that you maintain primarily
for visual design, demonstrating interactions to developers or as
simulator to fake actual products (for Demos, training purposes). At
times, you also use it against developers, who says,
that-is-not-possible! :-)

My 2 cents.

Prady

8 Nov 2004 - 5:13am
Peter Boersma
2003

David asked:
> When doing a prototype how do you communicate all these subtle pieces and
> still maintain some sort of constraint on the size of the
> prototype?

What I would do is create a start screen that shows several scenarios for
each of the rols/situations. The scenarios could re-use the same screens,
but in different order depending on the scenario.

Peter
--
Peter Boersma - Senior Information Architect - EzGov
Rijnsburgstraat 11 - 1059AT Amsterdam - The Netherlands
t: +31(0)20 7133881 - f: +31(0)20 7133799 - m: +31(0)6 15072747
mailto:peter.boersma at ezgov.com - http://www.ezgov.com

8 Nov 2004 - 10:19am
Coryndon Luxmoore
2004

Dave said:
When doing a prototype how do you communicate all these subtle pieces and
still maintain some sort of constraint on the size of the prototype? I mean
the prototype should not be "every" possible view, should it? How do you
"annotate" a working prototype?
--

The problem that we have found with interactive prototypes for complex
desktop applications is that prototypes cannot describe the interaction and
behavior with the subtlety that is required for development. All of the
roles, business rules, security and permissions, and data variation prevent
us from really accurately describing the behavior in a prototype.
Theoretically it is possible to reproduce it in high enough fidelity but we
have found it to take far too long for our design teams. This inability to
truly construct all of the variations has a tendency to lead the development
team astray since each person looking at the prototype tends to fill in the
gaps a bit differently.

We use the prototype for two basic purposes: demos to stakeholders and
reviewers, the basis for our user testing scenarios. So to determine what
pieces to more accurately prototype we determine what are the most common
scenarios that we will need to share with key stakeholders and what
scenarios we will be using for user testing. We will then build a generic
prototype that is used as a basis for client walkthrough and serves as a
base set of screens for constructing specific scenario prototypes for the
user tests. We do find the user testing prototypes to be useful for demos as
well since they more accurately describe the behavior in a specific
situation.

This means that the prototype is strictly a supporting document to our main
screen specifications that we build into an HTML or word deliverable. These
specs become the document of record.

We prefer HTML because we can link from the specs directly into the
prototype or other supporting material. However, the medium used for a
project is determined by the clients ability to maintain the documentation
after we are gone. So we are frequently forced to used Word since it is a
defacto standard tool in most IT organizations.

--Coryndon

8 Nov 2004 - 10:27pm
bill pawlak
2004

> My clients really like the "self-referential" prototype. I often
> attach such annotations to
>
> * mouseOver events <title> for text tags <alt> for images
> * (for buttons) a popup can display reference to a business rule;
> might describe IF/THEN conditions
>
> Another technique - especially useful in a presentation environment -
> is to "frame" the prototype screen with a sidebar
> that contains scrolling field for ongoing commentary.
> This allows you to develop context-sensitive "online help"
> collateral in parallel.

A recent Portal implementation project (with the usual mix of staff
users, mangaers, CE_ level-users all with differing roles and
permissions on what can/can't be seen at any one time presented the
same challenges.

In the beginning, I started out using both of these techniques to much
sucess. I also, on occasion, included hidden mouse-over div tags to
provide more explanation, as needed. But as things got going, they had
more requests to see what extra elements would be available when
someone had admin roles associated with their login.

Initial suggestions were that we should just basically create 2
different versions of the prototype. But that seemed like such a
waste, since many of the elements (portets) remained the same between
the two. So, I just converted most of it to .asp and based on the test
user's login, would include/not include various portlets as
appropriate.

You could do the same with hiding/showing individual <div> tags. The
benefits of .asp (or .jsp or whatever) are that you could potentially
show/hide something like an "edit" button on a portlet, based on the
login. It might seem like overkill from a prototyping perspective, but
the client firmly "got it," was quite pleased, and allowed us to
continue the project (3 goals that I think prototypes are helpful in
achieving)

bill

__________________________________
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com

8 Nov 2004 - 10:30pm
bill pawlak
2004

Oops. I meant "Managers," not "mangaers" - although I see no reason
why certain users couldn't be proficient in the art of drawing
Japanese-style comics!

bill

--- bill pawlak <billpawlak at yahoo.com> wrote:

>
> A recent Portal implementation project (with the usual mix of staff
> users, mangaers, CE_ level-users all with differing roles and
> permissions on what can/can't be seen at any one time presented the
> same challenges.
>

__________________________________
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com

Syndicate content Get the feed