Students Will Learn:

  • How to model their user population with a persona, an artificial person, which makes it easier to grasp who their users actually are.
  • How to interview users to understand their needs and wants, and to express these in the form of user stories.
  • How to make low-fidelity mockups layouts of apps and websites using sketching tools
  • How to test low-fidelity mockups on users, and incorporate their feedback into better designs
  • How to choose and configure telemetry to collect information on actual user behavior, and to analyze that behavior to improve your app
  • How to analyze the impact of security requirements on user behavior, and the user behavior’s impact on the required security environment


This class is aimed primarily at developers, designers, architects, and their managers. It also works extremely well with inter-disciplinary teams, including marketing and operations, each function providing its own perspective on the UX process.


Three days

Outline for User Experience Training

Day 1

0. Introduction: Why Software Sucks, and Why It Doesn’t Have To, and Shouldn’t

1. Who

Lecture:  The fundamental principle of all user experience design is understanding WHO the users really are – not  who you wish they were or hope they’ll somehow morph into.  We'll discuss methods of user research. Understanding your user population works best with an artificial person called a persona. We will study the elements of personas and how they work together. We'll examine how to update personas and user data with each agile sprint.
Lab: Develop personas representing your user population. Present them to the class for critique.

2. What

Lecture: We now work on on interviewing users to determine their needs, and expressing these needs in the form of stories. We’ll study the concept of stories, the hallmarks of good ones. Even if you already use stories for development, the user stories that we will generate and refine today are more detailed and user-oriented than those typically used in an agile backlog.  We'll examine how stories change and are refined with each agile sprint.

Lab: Quickly interview actual users or role-playing students. Select the two most important needs. Generate a story for each. Present them to the class for critique.

Day 2

3. How

Lecture: We will discuss the principles of UX sketches and prototypes, and the need for fast, cheap iteration in the early stages of the project. We’ll learn how to use the Balsamiq mock-up editor to quickly produce screens and storyboards.  This is a key portion of the agile sprint, so we'll learn how to prepare iterate them quickly and generate feed-forward for the next sprint.

Lab: Produce mock-ups sketches for the stories we did in the previous lesson.  Present them to the class for critique.

4. Try It Out:

Lecture: We’d discuss the principles of usability testing, and the items that contribute to its success or failure. We’ll cover the selection of test users and the writing of test scripts, the actual test runs, and the debriefing afterwards. This is also a key portion of the agile sprint, so we'll learn how to prepare iterate them quickly and generate feed-forward for the next sprint.

Lab:  We’ll set up an in-house lab and actually run a usability test on a quick prototype. Class will then critique the operation.

Day 3

5. Telemetry

Lecture:  We’ll discuss the needs of monitoring users' actual behavior, rather than what they can remember or are willing to admit to. We’ll cover the selection of a telemetry framework, the types of actions to monitor, and the design decisions we can make based on them.  We'll discuss the conclusions that can and can't be drawn from the data that we collect, and the feed-forward of data into the agile stream.

Lab: Produce telemetry plan for our own applications. Present them to the class for critique. Implement in simple example if there is time.  

6. Security

Lecture: We’ll discuss the impact of security effort on users, and users’ behaviors in response to required security effort. We’ll introduce the concept of the “hassle budget”, the amount of overhead that users will tolerate, and the sorts of workarounds that they’ll do when they feel it is exceeded. We’ll examine ways of spending this hassle budget wisely.  As always, we'll discuss feeding the data that we collect into future agile streams.

Lab:  Examine actual security requirements of our application. Consider ways in which users’ hassle budget is being spent, see if we can improve it. Present them to the class for critique.

7. Students’ Choice

Lecture and Lab: Topics requested by the students based on their experiences in the class