studio design in hci

Studio Design in HCIStudio 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

Today in ClassToday in Class

Final Presentation Schedule & Guidelines

Functional Specifications Keeping users involved after

delivery…what can designers do?

Final Presentations, nutshellFinal 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.

Send me the link to your Send me the link to your slidesslides

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

Functional SpecificationsFunctional Specifications

What are they? What’s in them? What do they

do?

Functional Specifications, 1Functional 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.


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.


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

More about specificationsMore about specifications

•Design team

•Future developers, others making implementation decisions

•Bill H-D, the teacher

Audiences Purposes

•Document specific design concepts & implementation decisions made

•Create a shared object to smooth the transition into production phase

•Record & justify design choices

Spec: Sample OutlineSpec: Sample Outline1.0 Purpose of Spec Document2.0 Design Overview3.0 User Roles and Tasks4.0 Screens

Interactions/TasksViews & Objects

Open Questions

5.0 Testing Overview6.0 Methods7.0 Results8.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

Spec & Prototypes: Some Spec & Prototypes: Some humorous resolutions…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:

Spec & Prototypes: Spec & Prototypes: But seriously…But seriously…

It is helpful to understand a spec document as it plays a role in the design lifecycle. We’ll 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:

A Process View of Spec, 1A Process View of Spec, 1

Design team

Audience Purposes•Create a shared understanding of design’s 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

early

mid

late


Developers

Audience Purposes

•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


Bean Counters

Audience Purposes

•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

What the Process View Teaches What the Process View Teaches Us about Developing Spec, 1Us about Developing Spec, 1

1. A Spec is an evolving document

2. 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.

What the Process View Teaches What the Process View Teaches Us about Developing Spec, 2Us about Developing Spec, 2

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 take care to represent the project “modules” in relation to user profiles, activities, and real user data, whenever possible.

Therefore, we should ensure that the document is readable and appropriate for all of these groups.

Spec: Sample Content, 1Spec: Sample Content, 1About 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

Spec: Sample Content, 2Spec: Sample Content, 2About 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

UI Spec: FormatUI Spec: Format•Enumerated sections make the document extensible & protect document’s 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

Spec: Arrangement Spec: Arrangement 1.0 Purpose of Spec Document2.0 Design Overview3.0 User Roles and Tasks4.0 Screens

Interactions/TasksViews & Objects

Open Questions5.0 Testing Overview6.0 Methods7.0 Results8.0 Future Steps

What do the “modules” in this outline seem to reflect? Who’s the audience? What are the purposes?

UI Spec: Arrangement by User UI Spec: Arrangement by User InteractionsInteractions

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

Spec: Arrangement by Spec: Arrangement by Supported FeaturesSupported 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

UI Spec: StyleUI 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

Design Principles for Keeping Design Principles for Keeping Users InvolvedUsers 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

Remember that users…Remember that users…

…don’t 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!

Design principles to take awayDesign principles to take away

1. Computation is a medium

2. Meaning arises on multiple levels

3. Users, not designers, create and communicate meaning

4. Users, not designers, manage coupling [of meaning to artifacts]

5. Embodied technologies participate in the world they represent

6. Embodied interaction turns action into meaning

For next time…For next time… Final

Presentations!

Thanks for all of your hard work and a great semester!!

studio design in hci

Documents