studio design in hci fall 2005 bill hart-davidson session 12: final presentation guidelines; more...
Post on 19-Dec-2015
213 views
TRANSCRIPT
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.
Functional Specifications, 2Functional 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.
Functional Specifications, 3Functional 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
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
A Process View of Spec, 2A Process View of Spec, 2
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
A Process View of Spec, 3A Process View of Spec, 3
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!!