Interaction Design - PowerPoint PPT Presentation

1 / 39
About This Presentation
Title:

Interaction Design

Description:

Search for lyrics. View lyrics. Verify source of lyrics. Then, ... Question: When do users need to see lyrics in the process of creating a song interpretation? ... – PowerPoint PPT presentation

Number of Views:58
Avg rating:3.0/5.0
Slides: 40
Provided by: HartDa
Learn more at: https://www.msu.edu
Category:

less

Transcript and Presenter's Notes

Title: Interaction Design


1
Interaction Design
  • Spring 2004
  • Bill Hart-Davidson

Session 9 teams present artifact or physical
model a class diagram guidelines for phase 2
memos prototyping
2
Today in Class
  • Teams present
  • Physical or artifact model
  • Class diagram
  • Guidelines for ph. 2 memos
  • Prototyping

3
What 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

4
Why 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
5
Why 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
6
Why 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.
7
Conceptual 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.
8
Concept 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!
9
Concept 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.

10
Concept 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.

11
Concept Report Format, in our class
  • A technical memo
  • Usually 5-8 pages in the body
  • Includes appendices for Drawings, Charts,
    Research Data, References, etc.

12
One 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!
13
One 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
14
One 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
15
I 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
16
A 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
17
Things 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.

18
Things 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

19
What 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.

20
A 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.

21
A 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.

22
Sowhy 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
23
Involve users in design
  • An alternative approach

use
use
use
use
Design..design..design..design
24
Prototyping 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

25
Prototyping 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

26
Prototyping 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
27
Prototyping 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.
28
Prototyping 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
29
Start 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
30
Then, 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
31
Make 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
32
Make a claim Composing screen
33
Then 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

34
I need more cowbell!
35
Try 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

36
Some 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

37
Outcomes 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
38
Using 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
39
For 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!
Write a Comment
User Comments (0)
About PowerShow.com