CHI-WEB Archives

ACM SIGCHI WWW Human Factors (Open Discussion)

CHI-WEB@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Dave Lafon <[log in to unmask]>
Reply To:
Date:
Tue, 4 Feb 2003 13:04:52 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (252 lines)
Here is the summary of responses to my recent inquiry about resources for
storyboarding.  Many thanks to all who replied.

Dave

------------------------
Mary Keitelman wrote:
You might want to take a look at Designing from Both Sides of the Screen by
Ellen Isaacs and Alan Walendowski. The book is an overall roadmap of how to
build an application with user centered design, and starting with Chapter
6, talks about how to go about defining a UI in real, practical terms.

-----------------------
Kay Brown wrote:
Our designers and engineers use a flow chart. Simple and understandable to
client, designers and engineers because a description of the activity both
electronic and graphic can be shown - everyone is on the same page. Is this
what you call a storyboard?

-----------------------
Cindy Lu wrote:
1)Find out what the system will do. Are there any functional requirements
and product requirements written for the web application?  Find the
requirements and read them.  Try to understand what the system will do for
the customers who buy the system.
2. Find out the players in the web application development: project
manager, product manager, functional architect, systems engineering,
development
manager, development leader, UI development team, etc. Talk to them to
understand their roles, product and marketing strategy, development
platforms and architecture.
3. Find out who are the potential customers of the systems. What systems
are they using right now? What problems with the current systems?
4. Find out the types of end users and what general tasks they do with this
system.
5. Will the system be integrated with other systems or it is a stand alone
system?
6. Are there any competitors in this field?  What are the competitors'
products look like?
7. Are there any UI style guideline and product identity style you should
follow?

When you have gathered all the above information, find a functional
architect or system engineer and a development person who are supportive
and can work with you during the entire development process.  Define UI use
cases/scenarios and review with them.  Do some initial prototype, either on
paper or Dreamweaver.

Call a meeting to review the use cases and the prototype with all the
interested parties, marking people, product manager, architect, development
manager, etc.

Revise the use cases and incorporate their comments.  Do more prototyping.

Work with a graphics person to define the style.

Design the pages.  Review with the development team.  Do testing.  etc.

This is the way how I have been worked.  I hope this helps.

--------------------------
Beate Huber wrote:

maybe you know it but anyhow
the tutorial "information architecture"
on webmonkey.com helped me in this case a lot.

---------------------------
Virpi Kurkela wrote:
I think that Contextual Design -book (Beyer and Holtzblatt) might be
helpful.

---------------------------
Pradyot Rai wrote:

There's going be couple of things you must be aware of - during this
exercise and as outcome of storyboarding. Following are the most important
stuff I have realized -

1. Expectations you would feel as wild as flying horses - People would want
to know what color of background you will have, how the button will look,
will there be pop-ups or dropdowns, etc. etc. etc. And if you don't manage
these premature expectations about the outcome is paper prototype/rough
sketches, I am sure you will have a tough time. How you plan to give them
list of things 'differed' for next stage of design, will work for
everybody. For example, telling people that 'visual design', detailing of
each
'widget' /'interactions', aspect ratio (and dimension), placement of
elements is not
early part of the storyboarding, is right thing to do in the beginning. If
you don't differ things and try answering/designing everything at that very
moment, you run a risk of been slapped by both the Product Managers and the
Developers, ultimately. Not been able to track all that was 'expressed'
could put you in the soup too.

2. People firing form all sides without having accountability (and everyone
would want to opine) and you will have no mechanism to track the issues and
move ahead - It is often a good practice to involve set of representatives
from all necessary departments for brainstorming and feedbacks. The list
must not be exhaustive and should be small enough for you to manage. Do the
most important job of telling people what each of them are responsible for,
besides just coming in the meeting. For example, there has to be some
'arbitrator' (other than you) incase there's a clash of interest. Also
there must be people, from places like engineering and QA responsible for
seeing
that outcome is implementable and should get tested, respectively. Also, it
is nice to have, a person always present with you (other than you) to take
note of all that was resolved (or even those which were raised but
unresolved). Usually those with tech writing background are good friends of
you during this phase, 'plus' their presence help you have better
documentation for the end users. The set of people you choose could form
the 'stakeholders' list. You have to have a process to close the issues,
open
new issues, differ of reject proposals and most importantly 'track' all the
issue which has ever been 'ushered' during these sessions.

3. Finally interpreting the requirements to produce meaningful 'workflow'
and 'screen sketches' - This is actually the main task which you wanted to
do. But due to the lack of insight into other stakeholders 'vested
interest' in the product, storyboarding could just not be complete, ever. To
have
story boarding done, you have to have 'Requirements' well documented and
clear, besides few stuffs as I mentioned earlier. At times, it is also good
idea not to jump over paper and pencil before knowing for sure what you are
designing. There are multiple ways, such as, use case driven approaches,
seeking the top level work flow from the Product Managers, etc. It is upto
your judgment to say when the requirements are understood and interpreted,
enough for the brainstorming and storyboarding sessions. Now I will
illustrate what I have done so far to get to the final stage to accomplish
'Storyboarding' -

The form and function of 'storyboarding' which I have presented to my
people and made them agree to (excuse me, not verbatim), is - set of screens
arrange in a sequence or interactively, which tells the story of how a user
could achieve one or multiple tasks (representative once) for which the
system is designed. This obviously presents, impression of 'navigation',
'all or set of representative screens' and plan for next stage of design
(which in my case gives me set of screens to be mocked-up, estimates of
expectations of visual design, and issues to do due-diligence).

In the very first sessions of brainstorming with set of people I go
prepared with the requirements. I try to design what is in 'requirement'
rather than
making suggestion. I keep myself prepared to discourage for taking anything
for discussion which is outside the scope or the plan, just to keep the
creative juices properly utilized. Most importantly, I make the pitch to
the people showing them my prematurely visualized interface design. I always
have seen, this working to start the brainstorming. But I have learned to
keep away from being sentimentally attached to my proposals, because that
is always been changed with better results with my being flexible.

The stuff I prepare to show for the first time are generally very rough
sketches (pasted against the wall, or drawn on the whiteboard), or black &
white drawings in the computer. It is a good practice to close all the
sessions by revisiting on all the important issues discussed and stuff to
be followed in the next sessions. Most of the issues don't get over in one
or
two sessions and I make sure the time spend between these sessions must be
utilized from my side towards the progress made in the right direction.
During all the time, where making friends with others is important, it is
always good to educate the group about the practical constraints of each
design suggestions, so to keep them prepared for any changes in design
after a certain stage.

On the issue of tool to use for Storyboarding - I have my own means to do
it. I have spend enough time collecting feedback on other ideas as well, so
far without fruitful results. People around me, my Mentor, Product
Managers, have always told me to use just paper-pen to illustrate things for
discussion, but I have always prepared my final sketches using 'Macromedia
Freehand' or 'Adode Illustrator'. Reason - these tools are easy to work
through rough templates, and are flexible for all small changes which
affects all the rest of the screens, far superior than those 'tissue paper'
concepts your bosses may ask you to adopt. After making all the screens
ready, I either play them through the projector, or paste the printouts on
the wall in a meaning full manner for discussion.

Multiple sessions are called to make progress through 'Storyboarding' to
attain the following -

1. To make sure the idea is tested and well thought by the cross functional
team, and that no aspects of design has been isolated or slipped through
the crack.
2. To get a good estimate of what is design and that it is enforced by the
set of paper prototypes, list of all the screens (or screen instances),
list of all the 'widgets', UI specs. or guidelines (may be, initial pass),
etc.
3. To manage the expectations of cross functional team and provide them
good visibility into development matters (it helps)

That is all about the way I do storyboarding.

I have read about various other means and processes to handle the
storyboarding. I also know that no process guarantee the eventualities, and
that it only helps skilled people to enforce the right stuff and do the
right thing. I also understands that no two companies are akin to each
other and no same processes which is successful at one place could guarantee
at
all other places. I have also felt that these process must be designed and
executed depending upon the size of the project/team. Finally for anything
you try to follow than bottom line must be - 1) that you complete the
design cycle before blocking the engineering team (eventually this ties down
to
the successful product roll out in time) and 2) that you establish set of
improvements over the previous design or fulfill the requirements.

--------------------------
Manoj wrote:

I'd asked this sometime back out here, and received a deluge of
helpful references. Of those, here's my pick of pointers -
http://www-106.ibm.com/developerworks/library/us-paper/?dwzone-usability

The site packs a punch as it desribes in detail the process which they
call 'paper prototyping' - a high sound, but just apt for the
intensive drill the interface is put through. With examples of e-com
pages and application GUIs deconstructed, Carolyn Snyder clarifies on
this important 'beore coding' aspect of development.

Other sites you could refer are -
http://www.oclc.org/usability/prototyping/oclc.htm
http://www.ucc.ie/hfrg/projects/respect/urmethods/paperproto.htm
http://www.stcsig.org/usability/topics/prototyping.html
http://www.infodesign.com.au/usability/paperprototypinggraphics.html

-------------------------
Joshua Kaufman wrote

DENIM is great software tool for creating storyboards and information
architecture diagrams:
http://guir.berkeley.edu/projects/denim/

I also highly recommend Jesse James Garretts widely used IA Visual
Vocabulary:
http://jjg.net/ia/visvocab/


Dave Lafon, Information Architect
WorldRes.com
1510 Fashion Island Blvd., Ste. 100
San Mateo, CA 94404
650-372-1712
 
"Online hotel reservations worldwide"

    --------------------------------------------------------------
        Tip of the Day: Forward out-of-office replies to
                    mailto:[log in to unmask]
     CHI-WEB: www.sigchi.org/web POSTINGS: mailto:[log in to unmask]
              MODERATORS: mailto:[log in to unmask]
       SUBSCRIPTION CHANGES & FAQ:  www.sigchi.org/web/faq.html
    --------------------------------------------------------------

ATOM RSS1 RSS2