Studio Design in HCI

1
Studio Design in HCI

• Fall 2005
• Bill Hart-Davidson

Session 12 final presentation guidelines more
than you ever wanted to know about Functional
Specifications making a long-term commitment to
user involvement
2
Today in Class

• Final Presentation Schedule Guidelines
• Functional Specifications
• Keeping users involved after deliverywhat can
  designers do?

3
Final Presentations, nutshell

• Current scenario (research/problems)
• Transformed scenario
• Walkthrough of 3-4 typical activities in the
  transformed scenario
• Future decisions implementations, markets,
  license options, version 2, 3, 4 etc.

4
Send me the link to your slides

• 24 hours before your talk, send me a link to your
  slides
• Due to the change in venue, we want to try to
  have all of the materials loaded on the machine
  ahead of time

5
Functional Specifications

• What are they?
• Whats in them?
• What do they do?

6
Functional Specifications, 1
A formal description of a technical product or
process that is used as a blueprint for building
or implementing. At minimum, a functional
specification should precisely state the purpose
(e.g., the function) of each component of the
product or process.
7
Functional Specifications, 2
Depending on the product and design method, a
functional specification might also provide
implementation details, such as how the project
is divided into modules and how the different
modules interact.
8
Functional Specifications, 3
In addition, a functional specification often
describes the software from the user's
perspective how the user interface appears and
how a user would use the program to perform
specific functions.
This definition adapted from a similar one
at webpedia.com
9
More about specifications
Audiences
Purposes

• Document specific design concepts
  implementation decisions made
• Create a shared object to smooth the transition
  into production phase
• Record justify design choices

• Design team
• Future developers, others making implementation
  decisions
• Bill H-D, the teacher

10
Spec Sample Outline

• 1.0 Purpose of Spec Document
• 2.0 Design Overview
• 3.0 User Roles and Tasks
• 4.0 Screens
• Interactions/Tasks
• Views Objects
• Open Questions
• 5.0 Testing Overview
• 6.0 Methods
• 7.0 Results
• 8.0 Future Steps

Note This is just a sample the headings are
general here so that you can see how segments
relate to one another
11
Spec Prototypes Some humorous resolutions

• Never shall a UI specification and the prototype
  which matches its version number be exactly the
  same
• Innovations shall occur in both the spec and the
  prototypes without regard for one another
• Those who must read and interpret both spec and
  prototype, including usability specialists and
  developers, may simply ignore one or the other

It is hereby resolved that
12
Spec Prototypes But seriously
It is helpful to understand a spec document as it
plays a role in the design lifecycle. Well call
this a process view of UI Spec The basic point
here is simple we expect the UI spec to do
different things for us depending on where we are
in the design process Consider these examples
13
A Process View of Spec, 1
Audience
Purposes

• Create a shared understanding of designs
  purpose, users, supported activities
• Document implementation decisions that are firm
  and those that are open
• Make a coherent case for the design to take to
  developers, management

Design team
early
mid
late
14
A Process View of Spec, 2
Audience
Purposes
Developers

• Serve as a blueprint for building the design and
  resourcing the build effort
• Document implementations supported and those that
  remain unsupported for current release
• Serve as a starting point for future design
  efforts and upgrades

1st prototype
beta
released
15
A Process View of Spec, 3
Audience
Purposes
Bean Counters

• Document a coherent, reasonable, and valid
  technical plan
• Forecast supported features of initial and
  subsequent releases
• Document development activities and justify
  costs plan next release

Proposal
First review by investors
Pre-release review
16
What the Process View Teaches Us about Developing
Spec, 1

• A Spec is an evolving document
• A Spec explains, argues, records

Therefore, we should design a format, layout, and
content that will allow us to constantly add to
it.
Therefore, we should create sections and
subsections that will enable the document to do
all 3 of these things.
17
What the Process View Teaches Us about Developing
Spec, 2
Therefore, we should take care to represent the
project modules in relation to user profiles,
activities, and real user data, whenever possible.
3. Spec may be the main place to store info about
users 4. Spec bridges the interests of
stakeholders in the design
Therefore, we should ensure that the document is
readable and appropriate for all of these groups.
18
Spec Sample Content, 1
About the document Overview Version
info Authors Design Team Last Revision Prototype
refs
About users Profiles Use Scenarios
(transformed) Roles (admin buyer, etc.) Use Cases
Supported by Initial Feedback Formative Test
Data Summative Test Data Market Profiles
19
Spec Sample Content, 2
About the design Modules States
Stages Screens Objects Interactions
(User Actions Object Methods)
Common Formats

• Screen shots
• Conceptual diagrams
• Formatted tables
• Bulleted Lists
• Specialized Notation (e.g. UML)

Each of these could be subordinate or
superordinate
20
UI Spec Format

• Enumerated sections make the document extensible
  protect documents ability to establish current
  decisions and record past actions
• Headings visuals make the document skimmable,
  easy to use as a reference for the design team
  and quickly indexed by a group of decision makers
• The modules you choose as the top-level section
  headings make the document more suited to one
  audience or another

21
Spec Arrangement

• 1.0 Purpose of Spec Document
• 2.0 Design Overview
• 3.0 User Roles and Tasks
• 4.0 Screens
• Interactions/Tasks
• Views Objects
• Open Questions
• 5.0 Testing Overview
• 6.0 Methods
• 7.0 Results
• 8.0 Future Steps

What do the modules in this outline seem to
reflect? Whos the audience? What are the
purposes?
22
UI Spec Arrangement by User Interactions
3.0 Marking up a report 3.1 The text markup
screen screenshot, etc. 3.1.2 Steps box left
margin 3.2.1 Student view 3.2.2 Teacher
view 3.3.1 Drag to Highlight 3.4 Rationales, test
data
The superordinate category here is an important
action that cuts across several key user roles
23
Spec Arrangement by Supported Features
3.0 User Profile Teacher 3.1 Teacher markup
view 3.2.1 Create new markup 3.2.2 Publish markup
guide 3.3.1 Drag to highlight 3.4 Rationales,
test data
Superordinate category here is a user role,
followed by key actions for each role
24
UI Spec Style

• Design your spec documents for
• Modularity
• Extensibility
• Scanability
• Indexicality

In other words, be consistent, use emphasis to
indicate similiarity of repeated elements, use
text boxes, tables, etc. to enhance layout, and
make sure your images, references to a prototype,
and text are all in agreement
25
Design Principles for Keeping Users Involved
Consider two overarching goals for transforming
interactive systems
The first is to support the improvised
sequential organization of action by giving users
more direct control over how activity is
managed...the second is to make the immediate
circumstances of work more visible
Dourish, p. 160
26
Remember that users
dont need to be saved. They will learn to do
fine without (or in spite of) your system if they
must. are the ones who, ultimately, must take
over your design and extend it into their working
environment. will use your system in the course
of doing other things, including using other
systems!
27
Design principles to take away

• Computation is a medium
• Meaning arises on multiple levels
• Users, not designers, create and communicate
  meaning
• Users, not designers, manage coupling of meaning
  to artifacts
• Embodied technologies participate in the world
  they represent
• Embodied interaction turns action into meaning

28
For next time
Thanks for all of your hard work and a great
semester!!

• Final Presentations!