Exercises
Introduction to exercises
Active Learning
The best way to learn the processes described in this book is by doing them! We have organized your participation in the process at three levels: examples for you to follow in the text, a more or less parallel set of exercises to do on your own, and a set of extensively specified team project assignments (on the book Website).
Pointers to the exercises are indicated within many of the chapters, often right after a similar example in the text. Those pointers refer to the exercise descriptions here. The location of each forward reference is where you should consider doing the exercise before moving on, but we have put the exercise descriptions here so as not to interrupt the flow of the rest of the text in the chapters. Finally, a comprehensive set of team project assignments is available in the Instructor’s Guide, available to instructors from the publisher. The exercises require medium-level engagement, somewhere in between the in-text examples and full project assignments.
Within the broader audience of this book, individual readers are encouraged to follow the examples and undertake the exercises on their own. Groups of readers, whether within classes taking the material as a course or within organizations that wish to acquire competency in these processes, will benefit even more from carrying out the exercises as a team. You should be able to figure out, from each exercise description, how to pursue the exercise either as an individual or as a team.
The exercises are for learning, not for producing a product, so you do not have to complete every detail if you think you have gotten what you need to out of each one. You should be able to learn most of what you can get from most exercises in an hour or so. In the case of a team within a classroom setting, this means that you can do the exercises as in-class activities, breaking out into teams and working in parallel, and possibly finishing the exercise as homework before the next class. This has the advantages of working next to other teams with similar goals and problems and of having an instructor present who can move among teams as a consultant and mentor. We recommend that student team deliverables be prepared in summary form for presentation to the rest of the class so that each team can learn from the others.
Choosing a Target Application System
Your choice of a target application system should be gauged toward the goal of learning, not producing a product. That means choosing something the right size. Avoid applications that are too large or complex; choose something for which the semantics and functionality are relatively easy to understand. However, avoid systems that are too small or too simple because they may not support the process activities very well. The bottom line: Choose something broad enough so that you can use the same system in all the exercises, each time building on your previous experience.
The criterion for selection here is that you will need to identify at least a half-dozen somewhat different kinds of user tasks. That usually means, for example, that a Website used only for information seeking is not a good candidate because information seeking is only a single type of task and often does not involve enough differences in the kinds of interaction. You should also choose a system that has more than one class of user. For example, an e-commerce Website for ordering merchandise will have users from the public doing the ordering and employee users processing the orders.
For practitioner teams in a real development organization, we recommend against using a real development project for these exercises. There is no sense in introducing the pressure to produce a real design and the risk of failure into this learning process.
Because many parts of these processes are best learned by interacting with a “user,” “customer,” or “client,” it helps to choose an application for which you can find (among friends, family, or fellow students or practitioners) or simulate these roles, for example, for contextual inquiry interviews.
Chapter 3 exercises
Exercise 3-1: System Concept Statement for a System of Your Choice
Goal: Get practice in writing a concise system concept statement.
Write a system concept statement for a system of your choice.
Iterate and polish it. The 150 or fewer words you write here will be among the most important words in the whole project; they should be highly polished, which means that you should spend a disproportionate amount of time and energy thinking about, writing, reading, editing, discussing, and rewriting this system concept statement.
Deliverables: Your “final” system concept statement.
Schedule: Given the simplicity of the domain, we expect you can get what you need from this exercise in about 30 minutes.
Exercise 3-2: Contextual Inquiry Data Gathering for the System of Your Choice
Goal: Get practice in performing contextual inquiry.
The best conditions for this exercise are to work as a team and have a real client, as you would in a team project, for example, in a course.
If you are working with a team but do not have a real client, divide your team members into users and interviewers and do a role-playing exercise. If you are working alone, invite some friends over for one of your famous pizza-and-beer-and-contextual-inquiry parties and have them play a user role while you interview them. We have found that you get the best results if you follow this order: eat the pizza, do the exercise, drink the beer.
Do your best to suspend disbelief and pretend that you and your users are in a real situation within the context of your domain of investigation.
Interviewers each take their own transcripts of raw data notes as you ask questions and listen to users talk about their work activities in this domain.
Preface each note with the user ID, for example, U3, of the user from whom the note is derived.
Deliverables: At least a few pages of raw contextual inquiry data transcript, hand written or typed, for the investigations you conducted for your example system. Include a few interesting examples (something unexpected or unique) from your notes to share.
Schedule: Given the simplicity of the domain, we expect this exercise to take about 1 to 2 hours.
Chapter 4 exercises
Exercise 4-1: Flow Model Sketch for Your System
Goal: Get practice in making an initial flow model sketch for the work practice of an organization.
For your target system sketch out a flow model diagram, in the same style as our flow model sketch for MUTTS, shown in Figure 4-3, showing work roles, information flow, information repositories, transactions, etc.
Draw on your raw work activity data and construct a representation of the flow of data, information, and work artifacts.
Even if there is no existing automated system, you should capture the flow of the manual work process.
Start with representing your work roles as nodes, add in any other nodes for databases and so on.
Label communication and flow lines.
If you do not have enough contextual data from your limited data-gathering exercise, make some up to make this work.
Deliverables: A one-page diagram illustrating a high-level flow model for the existing work process of your target system.
Schedule: Given the simplicity of the domain, we expect this exercise to take about an hour.
Exercise 4-2: Work Activity Notes for Your System
Goal: Get practice in synthesizing work activity notes from your contextual data.
If you are working alone, it is time for another pizza-and-beer-and-contextual-analysis party with your friends.
However you form your team, appoint a team leader and a person to act as note recorder.
The team leader leads the group through raw data, synthesizing work activity notes on the fly.
Be sure to filter out all unnecessary verbiage, fluff, and noise.
As the work activity notes are called out, the recorder types them into a laptop (preferably with a screen projector so that the group can see the work in progress).
Everyone in the team should work together to make sure that the individual work activity notes are disambiguated from context dependencies (usually by adding explanatory text in italics).
Deliverables: At least a few dozen work activity notes synthesized from your raw contextual inquiry data transcript for your system, hand written or typed into a laptop. Highlight a few of your most interesting synthesized work activity notes for sharing.
Schedule: Based on our experience with these activities, we expect this to take you an hour or two.
Exercise 4-3: WAAD Building for Your System
Goal: Get practice in building a work activity affinity diagram to sort and organize contextual data.
If you are working alone, it is time for yet another pizza-and-beer-and-contextual-analysis party with your friends (the last time you have to buy pizza, at least in this chapter).
However you assemble your team, using all the work activity notes created from the contextual inquiry investigations you did in the previous exercise, do your best to follow the procedure we have described in this chapter for WAAD building.
Take digital photographs of your work process and products, including the full WAAD, some medium-level details, and some close-ups of interesting parts.
Hang them on your fridge with magnets.
Deliverables: As much of the full WAAD for your system as you were able to produce. It is probably best to keep it rolled up into a bundle for safe keeping unless you have the luxury of being able to keep it taped to the wall. You should also have the digital photos you took of your WAAD. If you are working in a classroom environment, be prepared to share the photos in a narrated slide show and to discuss your WAAD and the process of building it with other teams in the class.
Schedule: This is one of the more time-consuming exercises; expect it to take 4 to 6 hours.
Chapter 5 exercises
Exercise 5-1: Extracting Requirement Statements for Your System
Goal: Get some practice with requirements extraction.
Assemble a team per the preparation guidelines in this chapter.
Get together with your team where you have hung your WAAD for the Ticket Kiosk System or hang it back up again if you had to take it down before.
Number all the WAAD nodes and notes with a structured set of ID markers.
Do a careful walkthrough, traversing the WAAD.
For each work activity note in the WAAD, work as a team to:
Deduce user need(s) and interaction design requirements to support the need(s).
As you go, have the recorder capture requirements in the format of Figures 5-4 and 5-5, including extrapolation requirements and rationale statements, where appropriate.
In the process, also make notes and lists about:
Ways to enhance the overall user experience
Information about design-informing models
To speed things up, have each person be responsible for writing the requirement statements extracted from a different sub-tree in the WAAD structure. Set aside any work activity notes that require additional thought or discussion to be dealt with at the end by the team as a whole.
If time permits, have the whole team read all requirement statements to assure agreement.
A requirements document covering at least one subtree of the WAAD for your system.
Notes and lists of the other kinds of information (above bullets) that come out of this process.
Schedule: We expect that this exercise could take at least a couple of hours. If you simply do not have that kind of time to devote to it, do as much as you can to at least get a flavor of how this exercise works.
Chapter 6 exercises
Exercise 6-1: Identifying Work Roles for Your System
Goal: Get a little practice at identifying work roles from your contextual data.
Activities: By now you should be pretty certain about the work roles for your system.
Using your user-related contextual data notes, identify the major work roles for your system.
Write the major ones in a list.
For each role, add explanatory notes describing the role.
For each role, add a description of the major task set that people in that role would be expected to perform.
Deliverables: A written list of work roles you identified for your system, each with an explanation of the role and a description of the associated task set.
Exercise 6-2: User Class Definitions for Your System
Goal: Get practice in defining user classes for work roles.
Using your user-related contextual data notes, create a few user class definitions to go with the work roles definitions you created in the previous exercise.
For each of the work roles that you identified in the previous exercise, draw on your user-related contextual data notes to define one or two corresponding user classes, describing the characteristics of each.
Deliverables: A few user class definitions to go with the work roles identified for the system of your choice.
Schedule: A half hour to 45 minutes should be enough to get the most out of this assignment.
Exercise 6-3: A Social Model for Your System
Goal: Get a little practice in making a social model diagram.
Identify active entities, such as work roles, and represent as nodes in the diagram.
Include groups and subgroups of roles and external roles that interact with work roles.
Include system-related roles, such as a central database.
Include workplace ambiance and its pressures and influences.
Identify concerns and perspectives and represent as attributes of nodes.
Identify social relationships, such as influences between entities, and represent these as arcs between nodes in the diagram.
Identify barriers, or potential barriers, in relationships between entities and represent them as red bolts of lightning (
).
Deliverables: One social model diagram for your system, with as much detail as feasible.
Exercise 6-4: A Social Model for a “Smartphone”
Sketch out an annotated social model for the use of an iPhone or similar smartphone by you and your friends.
Exercise 6-5: Creating a Flow Model for Your System
Goal: Get a little practice in creating a flow model for an enterprise.
Follow up on your flow model initial sketch that you did in Exercise 4-1.
Again represent each work role or system entity as a node in the diagram.
Use arcs between nodes to show all communication and coordination necessary to do the work of the enterprise.
Use arcs to represent all information flow and flow of physical artifacts.
Include all forms of communication, including direct conversations, email, phones, letters, memos, meetings, and so on.
Include both flow internally within the enterprise and flow externally with the rest of the world.
Deliverables: One flow model diagram for your system, with as much detail as feasible.
Exercise 6-6: Hierarchical Task Inventory for Your System
Goal: Get some practice creating a hierarchical task inventory diagram.
Activities: Using your task-related contextual data notes, make a simple hierarchical task inventory diagram for your system.
Deliverables: Simple HTI diagram(s) for the system of your choice.
Schedule: An hour should be enough to get what you need from this exercise.
Exercise 6-7: Usage Scenarios for Your System
Goal: Get some practice in writing usage scenarios.
Select one or two good representative task threads for the most interesting user class, for example, the customer.
Write a couple of detailed usage scenarios, referring to user roles, tasks, actions, objects, and work context.
Work quickly; you can clean it up as you go.
Hints and cautions: Do not worry too much about the design yet; we will get to that.
Exercise 6-8: Design Scenarios for Your System
Goal: Get some practice in writing usage scenarios.
For the same usage scenarios you wrote in the previous exercise, write a couple of detailed design scenarios, again referring to user roles, tasks, actions, objects, and work context.
Make up anything you need about the design on the fly.
Do this quickly; you can clean it up as you go.
Exercise 6-9: Identifying Information Objects for Your System
Goal: Get a little practice in identifying information objects for a system.
Review the ontology of your system.
Identify the entities within your application that are operated on by users—searched and browsed for, accessed and displayed, modified and manipulated, and stored back again.
Sketch an outline or list of these information objects, their attributes, and the relationships among them.
Chapter 7 exercises
Exercise 7-1: Creating a User Persona for Your System
Goal: Get some experience at writing a persona.
Select an important work role within your system. At least one user class for this work role must be very broad, with the user population coming from a large and diverse group, such as the general public.
Using your user-related contextual data, create a persona, give it a name, and get a photo to go with it.
Write the text for the persona description.
Deliverables: One- or two-page persona write-up
Schedule: You should be able to do what you need to learn from this in about an hour.
Exercise 7-2: Practice in Ideation and Sketching
Goal: To get practice in ideation and sketching for design.
Doing this in a small group is strongly preferable, but you can do it with one other person.
Get out blank paper, appropriate size marking pens, and any other supplies you might need for sketching.
Pick a topic, a system, or device. Our recommendation is something familiar, like a dishwasher.
Start with some free-flow ideation about ways to design a new and improved concept of a dishwasher. Do not limit yourself to conventional designs.
Go with the flow and see what happens.
Remember that this is an exercise about the process, so what you come up with for the product is not that crucial.
Everyone should make sketches of the ideas that arise about a dishwasher design, as you go in the ideation.
Start with design sketches in the ecological perspective. For a dishwasher, this might include your dining room, kitchen, and the flow of dishes in their daily cycle. You could include something unorthodox: sketch a conveyor belt from the dinner table through your appliance and out into the dish cabinets. Sketch how avoiding the use of paper plates can save resources and not fill the trash dumps.
Make some sketches from an interaction perspective showing different ways you can operate the dishwasher: how you load and unload it and how you set wash cycle parameters and turn it on.
Make sketches that project the emotional perspective of a user experience with your product. This might be more difficult, but it is worth taking some time to try.
Ideate. Sketch, sketch, and sketch. Brainstorm and discuss.
Deliverables: A brief written description of the ideation process and its results, along with all your supporting sketches.
Schedule: Give yourself enough time to really get engaged in this activity.
Chapter 8 exercises
Exercise 8-1: Conceptual Design for Your System
Goal: Get a little practice in initial conceptual design.
Think about your system and contextual data and envision a conceptual design, including any metaphors, in the ecological perspective. Try to communicate the designer’s mental model, or a design vision, of how the system works as a black box within its environment.
Think about your system and contextual data and envision a conceptual design in the interaction perspective. Try to communicate the designer’s mental model of how the user operates the system.
Finally, think about your system and contextual data and envision a conceptual design in the emotional perspective. Try to communicate a vision of how the design elements will evoke emotional impact in users.
Deliverables: Brief written descriptions of your conceptual design in the three perspectives and/or a few presentation slides of the same to share with others.
Schedule: You decide how much time you can afford to give this. If you cannot do this exercise in all three perspectives, just pick one, perhaps the ecological perspective.
Exercise 8-2: Storyboard for Your System
Goal: Get a little practice in sketching storyboards.
Sketch storyboard frames illustrating narrative sequences of action in each of the three perspectives.
Include things like these in your storyboards:
Hand-sketched pictures annotated with a few words
All the work practice that is part of the task, not just interaction with the system, for example, include telephone conversations with agents or roles outside the system
Sketches of devices and screens
Any connections with system internals, for example, flow to and from a database
Cognitive user actions in “thought balloons”
Extra-system activities, such as talking with a friend about what ticket to buy
For the ecological perspective, illustrate high-level interplay among human users, the system as a whole, and the surrounding context.
In the interaction perspective, show screens, user actions, transitions, and user reactions.
Use storyboards in the emotional perspective to illustrate deeper user experience phenomena such as fun, joy, and aesthetics.
Schedule: You decide how much time you can afford to give this. If you cannot do this exercise in all three perspectives, just pick one, perhaps the ecological perspective.
Chapter 9 exercises
Exercise 9-1: Intermediate and Detailed Design for Your System
Goal: Get some practice in developing a few parts of the intermediate and detailed design.
If you are working with a team, get together with your team.
Choose just one principal work role for your system (e.g., the customer).
Choose just one key task that work role is expected to perform.
For that work role and task, make a few illustrated scenarios to show some of the associated interaction.
Sketch some screen layouts to support your scenarios, along with some representation of the navigational structure.
Go for a little depth, but not much breadth.
Make a few annotated wireframes for the same scenarios.
Hints, cautions, and assumptions:
Do not get too involved in design guidelines issues yet (e.g., icon appearance or menu placement).
Control time spent arguing; learn the process!
Base your screen designs on the contextual analysis and design you have done so far.
Deliverables: Just the work products that naturally result from these activities.
Schedule: Whatever you can afford. At least give it an honest try.
Chapter 10 exercises
Exercise 10-1: Identifying User Experience Goals for Your System
Goal: A little experience in stating user experience goals.
Activities: Review the WAAD and user concerns in the social model for the system of your choice, noting user or customer concerns relating to user experience goals.
Deliverables: A short list of user experience goals for one user class of the system of your choice.
Exercise 10-2: Creating Benchmark Tasks and UX Targets for Your System
Goal: To gain experience in writing effective benchmark tasks and measurable UX targets.
We have shown you a rather complete set of examples of benchmark tasks and UX targets for the Ticket Kiosk System. Your job is to do something similar for the system of your choice.
Begin by identifying which work roles and user classes you are targeting in evaluation (brief description is enough).
Write three or more UX table entries (rows), including your choices for each column. Have at least two UX targets based on a benchmark task and at least one based on a questionnaire.
Create and write up a set of about three benchmark tasks to go with the UX targets in the table.
Do NOT make the tasks too easy.
Make tasks increasingly complex.
Create tasks that you can later “implement” in your low-fidelity rapid prototype.
The expected average performance time for each task should be no more than about 3 minutes, just to keep it short and simple for you during evaluation.
Include the questionnaire question numbers in the measuring instrument column of the appropriate UX target.
Do not spend any time on design in this exercise; there will be time for detailed design in the next exercise.
Do not plan to give users any training.
Two user benchmark tasks, each on a separate sheet of paper.
Three or more UX targets entered into a blank UX target table on your laptop or on paper.
If you are doing this exercise in a classroom environment, finish up by reading your benchmark tasks to the class for critique and discussion.
Schedule: Work efficiently and complete in about an hour and a half.
Chapter 11 exercises
Exercise 11-1: Building a Low-Fidelity Paper Prototype for Your System
Goal: To obtain experience with rapid construction of a low-fidelity prototype for early stages of user interaction design and to have a real paper prototype to generate lots of critical incidents later in your evaluation exercise.
Activities: This should be one of your most fun exercises, but it can also be a lot of work.
Following the guidelines for paper prototype construction given in Section 11.6.5, build a paper prototype for your system or product design.
Make sure that the prototype will support at least the benchmark tasks, descriptions for which you wrote in the previous exercise.
Add in some other “decoy” interaction design “features,” widgets, and objects so that the prototype does not look tailored to just your benchmark tasks.
It is normal for you to have to do more design work during this exercise, to complete details that were not fully designed in previous exercises.
Remember: You are learning the process, not creating a perfect design or prototype.
Assuming you are doing this as a team: Get everyone on your team involved in drawing, cutting, taping, and so on, not just one or two people.
You will be done much faster if everyone pitches in.
This is not art class so do not worry too much about straight lines, exact details, etc.
Pilot test to be sure it will support your benchmark tasks for evaluation.
Deliverables: A right smart “executable” paper prototype that will support your benchmark tasks in user experience testing, and your pilot tests passed with flying colors (no monochromatic flying).
Schedule: Just git ‘er done. It could take several hours, but it is essential for all the exercises that follow.
Chapter 13 exercises
Exercise 13-1: Formative UX Inspection of Your System
Goal: Get a little practice in doing a UX inspection.
Unless you have another prototype, use the paper prototype you built in the previous exercise. If your paper prototype is not suitable for an effective exercise in UX inspection, select an application or appropriate Website as the target of your inspection.
Perform a UX inspection as described in Chapter 13.
If you are working with a team, use the team approach described in Chapter 13.
Deliverables: A list of UX problems identified by your UX inspection.
Chapter 14 exercises
Exercise 14-1: Formative UX Evaluation Preparation for Your System
Goal: To get some practice in preparation for a simple empirical evaluation.
If you are working with a team, get together with your team.
Decide roles for team members. Include at least a facilitator and a prototype executor, plus a quantitative data recorder and one or more critical incident recorders.
In addition, if you are doing this exercise in a classroom with other teams, assign two team members as participants to trade to another team when you start data collection in the next exercise.
The prototype executor should get out the paper prototype you made in Exercise 11-1 and make sure the prototype works without breaking.
If you developed a programmed prototype, everything will be the same except that you will not need an interface executor. You will, instead, need someone to make sure the prototype hardware and software are set up, installed, and running properly for evaluation.
This activity works well for a team of about four. If you have more or fewer members in your team, it is easy to make adjustments. If there are only two of you, for example, one person can be the executor and the other person can record critical incidents and time the benchmark tasks. If there are four or five of you, the extra people will be valuable in helping record critical incidents. If you have been working alone on all the previous exercises, you may want find a couple of other people to help you run the evaluation. In addition and in any case, you need to recruit two people to serve as participants to evaluate your prototype.
Get out the UX target table you made in Exercise 10-2.
Have at least two benchmark tasks that you created in Exercise 10-2, each written on a separate piece of paper.
Assuming you used a questionnaire for subjective data in your evaluation session, get out copies of the questionnaire, one for each participant you will be using, and circle the questions you want participants to answer.
Review your evaluation protocols.
Deliverables: Just have everything just mentioned ready for the next exercise, data collection.
Schedule: It should not take too long to get ready for evaluation.
Chapter 15 exercises
Exercise 15-1: UX Evaluation Data Collection for Your System
Goal: To get a little practice in the data collection part for a very simple formative UX evaluation using a paper prototype.
Activities: This is perhaps the most fun and most rewarding of all the exercises when you finally get to see some users in action with your interaction design.
This is described in terms of multiple teams in a classroom setting. For other setups, make appropriate adjustments.
After all the teams are gathered and sitting around a table, make the switch of participants with another team.
You send the two people in the participant role from your team to another team. Curb the potential confusion here by doing the swap in an orderly circular fashion among the teams.
You will now have new participants from a different team who are unfamiliar with your design. These new participants are now permanently on your team, for the rest of these exercises, including data collection, analysis, and reporting.
As an alternative, if you do not have multiple teams, try recruiting a couple of co-workers or friends as participants.
Sitting together in your newly formed teams, get out your UX target table form, your benchmark task descriptions, and your questionnaires.
Dismiss your two participants (the new team members you just got) to the hallway or other waiting area.
Assemble and boot up your prototype, per the instructions in Section 15.3.6.
Call in your first participant into the “lab,” greet the participant, and explain the evaluation session.
Have this first participant perform your first benchmark task for your objective UX targets.
Have the participant read the first benchmark task aloud.
Ask the participant to perform that task while thinking aloud.
The executor moves prototype parts in response to participant actions.
The facilitator directs the session and keeps it moving.
Timer(s) writes down or enters timing and error count data as indicated in UX targets as the user performs the task (do not count participant’s reading aloud of task in task timing).
Everyone else available should be used to take notes on critical incidents and UX problems.
Remember the rules about not coaching or anticipating user actions. And the computer may not speak!
Have this first participant perform your second benchmark task for your objective UX targets.
Have the participant read the second task aloud and perform it while thinking aloud.
You need to collect a dozen or more critical incidents in this overall exercise (i.e., from both participants doing both benchmark tasks).
If you do not get at least a half dozen from each participant, continue with that participant doing exploratory use of your prototype until you get enough critical incidents.
For example, have them browse through each screen, looking at each object (button, menu, etc.), commenting on and giving their opinion about the quality of the user experience relating to various features.
Have this participant complete your questionnaire and then give them their “reward.”
Keep your first participant as a new member of the rest of the team to help with observations.
Bring in the second participant and perform the same session again.
Schedule: Complete by end of class (about an hour and a half, if you are efficient).
Chapter 16 exercises
Exercise 16-1: UX Data Analysis for Your System
Goal: To get some practice with the analysis part of a very simple formative UX evaluation.
If you are working with a team, get together with your team, including any new participants you picked up along the way.
Fill in the UX target table “Observed results” column.
Together, your team compiles and compares the quantitative results to determine whether UX targets were met.
Review your raw critical incident notes and write a UX problem list.
Organize the UX problem list and perform cost-importance analysis.
Using a paper cost-importance table or laptop spreadsheet, list a dozen or more UX problems from critical incidents.
Assign an importance (to fix) rating to each observed problem.
Propose solutions (without doing all the work of redesign).
Group together any related problems and list as single problem.
Assign cost values (in person-hours) to each solution.
Move your “Must fix” problems to the top of your cost-importance table.
Sort the remaining problems by decreasing priority ratios to determine the priority rank of UX problems.
Fill in the cumulative cost column.
Assume a hypothetical value for available time resources (something to make this exercise work).
Draw the cutoff, line of affordability.
Finalize your “management” decisions (resolution) about which changes to make now and in the next version.
Summary of quantitative results, written in “Observed results” column in your UX target table form (for comparison with UX targets).
List of raw critical incidents.
Cost-importance table form containing three UX problems selected as interesting to present to class or your work group (complete across all three rows).
Choose someone to give brief a report on your evaluation results.
Schedule: Given the simplicity of the domain, we expect this exercise to take about 30 to 60 minutes.
Chapter 17 exercises
Exercise 17-1: Formative Evaluation Reporting for Your System
Goal: Write a report of the formative UX evaluation you did on the system of your choice.
Report on your informal summative evaluation results using a table showing UX targets, benchmark tasks, questionnaires, and so on used to gather data, along with target values and observed values.
Add brief statements about whether or not each UX target was met.
Write a full report on a selected subset (about half a dozen) of UX problems found in the qualitative part of your formative UX evaluation. Follow the guidelines in this chapter regarding content, tone, and format, being sure to include redesign proposals for each problem.
Report on the results of your cost-importance analysis, including problem resolutions, for all the problems you reported previously and, if appropriate, some others for context.