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 delivery…what 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? • What’s 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. 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:

13. A Process View of Spec, 1 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 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 Supported by: Initial Feedback Formative Test Data Summative Test Data Market Profiles About users: Profiles Use Scenarios (transformed) Roles (admin; buyer, etc.) Use Cases

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

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? Who’s 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… …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!

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. Thanks for all of your hard work and a great semester!! For next time… • Final Presentations!