Title: Interaction Design
1Interaction Design
- Spring 2004
- Bill Hart-Davidson
Session 9 teams present artifact or physical
model a class diagram guidelines for phase 2
memos prototyping
2Today in Class
- Teams present
- Physical or artifact model
- Class diagram
- Guidelines for ph. 2 memos
- Prototyping
3What is a Conceptual Design?
- In the conceptual design the goal is to clarify
the following about your design - a list of the functionality it must provide to
users, based on the structure of work/activity - how the new design will do what the old system
used to doand - how the new design will transform the target
activity
4Why do a Conceptual Design report?, 1
For quality assurance, to lay out the model for
the solution independent of its implementation so
that we can have a baseline to evaluate
implementation options
e.g. Saying our system must provide for
asynchronous sharing of CAD drawings among design
team members, management, and clients at
distributed locations allows you to have a
standard by which to judge various means of
satisfying this requirement
5Why do a Conceptual Design report?, 2
As a formalized statement of goals for the design
team understanding what the system must do at a
conceptual level allows the team members to
understand how their expertise can contribute to
the designand lets individuals work on their
strength areas without having to guess about
design targets
6Why do a Conceptual Design report?, 3
For the sake of users! to allow the client, the
team, and end users to look at and comment on the
designs basic functions and features while it is
still easy and cheap to make changes
This is probably the most important function of
the report. If you construct your document with a
review meeting in mind where the stakeholders
can read, react, and either agree to the design
or suggest changes, youll do well.
7Conceptual Design Reports are Technical Documents
By technical, we mean that your readers are
insiders often experts in both the technical
area as well as the organizational context in
which the design will be implemented. They will
expect to hear details about the design features
you have devised as well as the methods/sources
you have consulted to arrive at these.
8Concept Report Lines of Argument, 1
Like many technical documents, there are few
explicit appeals which make this document seem
to be persuasive. In other words, there will be
no overt arguments like you may have made in
the proposal. This doesnt mean that you dont
have a persuasive aim however!
9Concept Report Lines of Argument, 2
- The concept report should argue that
- Your designs basic features match the needs of
the client and the end-users. - That your team is technically competent,
thorough, and careful to keep the clients
interests (practical, financial, ethical, etc.)
at the forefront. - That your design is innovative, truly capable of
transforming the social practice you target.
10Concept Report Format, in the real world
- Usually a formal technical report
- Letter of Transmittal, Summary Team Contact
Info Page, Body of Report, Appendices for
Drawings, Charts, Research Data, References, etc. - Letter introduces report and invites response,
perhaps by anticipating the design review meeting - Concept reports are occasionally followed up with
a Design Walkthrough.
11Concept Report Format, in our class
- A technical memo
- Usually 5-8 pages in the body
- Includes appendices for Drawings, Charts,
Research Data, References, etc.
12One option for the report body
I. Introduction Overview of Current/Transformed
Scenario II. Functional Requirements A.
statement of the requirement B. problems in the
current scenario C. goals, actions resources
important to users D. functionality in the new
design that will transform the scenario
Back theseup with Data!
13One option for the report body, 2
III. Key issues in the design A. Themes from the
Affinity B. Design challenges posed by the
situation, and how the team has
resolved them C. Open issues the team needs to
resolve and how they plan to do so
use your models
This section could be section II, if it will help
give readers more of the big picture up front
14One option for the report body, 3
IV. Looking Ahead Prototyping and
Implementation Options A. Descriptions,
sketches, mockups , etc. along with discussion
of implementation choices the team must make
15I am not giving you an outline!
This memo can and probably should be organized
differently for each team. Please, consider the
previous example as just one option. Consider
your teams own situation and how the structure
should change to fit it
For example
16A macro-structure modification
I. User role menu planners
A. Functional Requirements 1. statement of the
requirement 2. problems in the current
scenario 3. goals, actions resources important
to users in this role 4. functionality in the
new design that will transform the scenario
17Things To Do Now, logistics
- Set up the document shell as a group, agree
on an outline, section headings, etc. Establish a
process for drafting that includes version
control. - Come to an agreement on how much information you
currently have that you need to write the report,
how much you still need, and when/where that info
is coming from.
18Things To Do Now, design
- Take stock of what you knowand what you still
need to find out. Do the exercise Holtzblatt
calls Walking the Affinity - Make a list of basic functionality features for
the current system in place where are the
obvious gaps between your user/client needs and
this list? - Go over the list carefully to add detail from
your CD work, then go over it again to separate
out implementation specific details
19What is a prototype?
- A prototype is a physical representation of a
design idea that the team wants user feedback on. - Users should be able to do work with the
prototype so that the design idea it represents
can be tested.
20A prototype is not
- A work model, class diagram, or other conceptual
artifact. - These are not very useful for getting real user
feedback because they are written in the
language of designers.
21A prototype is also not
- A demo.
- With a demo, the designer does all the work,
either by automating a sequence that gets played
backor by guiding users through a work sequence.
22Sowhy prototype?
- Because, as BH say, the customer is the final
arbiter of the design - Consider this one for a second
use
Design..design..design..design
23Involve users in design
use
use
use
use
Design..design..design..design
24Prototyping allows you to
- test your design ideasas claims about what
will work for your users - see how work practice will be supported (or not!)
in the design - discover emergent work practices
- glimpse the overall experience the new work
environment will offer - find out if work processes (e.g. a known
sequence) are coherent in the new system
25Prototyping also allows you to
- Involve users in the design process
- In such a way as to limit user involvement to
preserve focus on both the users and designers
most pressing concerns
26Prototyping guidelines, 1
- Use a language to develop prototypes that users
have easy access to (like pencil paper)
The main reason for doing paper (or other
low-fidelity) prototypes is to allow users write
access to the designco-designer status depends
on ability and willingness to change the design
27Prototyping guidelines, 2
- Keep it real use real user data, let users do
real work with the low-fi system
To keep the focus on the structure of work, you
want to have the users doing real tasks. This may
mean having the design team fill in for the
interactive components of the systemchanging
paper screens, etc.
28Prototyping guidelines, 3
- Build prototypes in response to specific
questions the team needs user feedback to answer
If every prototype is a kind of claim about
whats best for users, then you are usually
asking questions that test the validity of those
claims.
Example
29Start with your requirements/functions
- Requirement Users need access to trustworthy
editions of song lyrics in order to create an
interpretation
Function(s)
Search for lyrics View lyrics Verify source of
lyrics
30Then, identify a question
- Question When do users need to see lyrics in the
process of creating a song interpretation?
Review existing data
Users read lyrics carefully before writing scan
re-read during writing Access to lyrics seem
important throughout the process
31Make a claim
- Claim When users are writing about an entire
album, they may need to check the lyrics of
various tracks frequently.
Then build it
32Make a claim Composing screen
33Then test the claim with a scenario
- Use the following screen as if you were
composing a review of Blue Oyster Cults 1973
album Tyranny Mutation
- Why BOC? Because it matters to the user (if not,
use something else!) - Note that you may need several mock-ups to
simulate interaction
34I need more cowbell!
35Try it for next week!
- Pick a requirement set of functions (use your
class diagram) - Identify a question
- Recall your data about the issue
- Write a claim (or two!)
- Sketch it and test it on somebody nearby
36Some things to watch for during a prototyping
session
- Where users struggle and why
- Where users work practices seem fluent
- new work that didnt exist before the system
- Attempts by users to work around the system
37Outcomes of prototyping sessions evidence for
your claims!
when composing a review, users preferred the
quick-access of a rollover for viewing lyrics to
a separate window
38Using the evidence
- There are three main ways youll use the
information from prototyping - To continually improve the design
- To justify design decisions
- To clarify issues for the implementation team
in the final spec doc
39For next time
- Bring a (very) low-fi prototype
- Be prepared to explain its features and functions
in terms of your CD analysis - Discuss the design question it will help you
address - Discuss how you will evaluate the prototype or,
if applicable, test it in class!