User Activities

User activities help incorporate user feedback and needs into your project, enhancing the user experience and overall product design. They are also key to finding users and growing your product.

“You are not your user.” – Many People

Note

These activities are direct preparation for graded work. Your Definition of Shipped requires a user access plan: who your real users or evaluators are and how you will reach them by the winter real-user gate. Recruiting users takes weeks, not days; the Shipping guide explains the lead times. Start these activities in fall.

Whenever an activity below involves talking to users, run the conversation with the Mom Test cheat sheet in hand: ask about their life and past behavior, not about whether they like your idea.

Ideate About User Activities

Team Activity

Generate a list of 5-10 ideas for user activities that you might do at some future point. For each kind of activity, generate at least one (but preferably two or three) different ways in which you might apply that activity in your project. For example, there are multiple ways one might use A/B testing.

To get started, you can read NN/g’s When to Use Which User-Experience Research Methods and UX Research Cheat Sheet.

Here are some more in-depth guides:

• Quantitative User-Research Methodologies
• 27 Tips and Tricks for Conducting Successful User Research in the Field
• Why You Only Need to Test with 5 Users

Consider splitting the readings between team members.

A good output is 5 to 10 candidate user activities, each with at least one concrete way you would apply it to your project.

Do a User Activity

Individual Activity Team Activity

There are dozens of activities that you can do with real users (see previous section). Select one that is relevant for your project at this point in time and do it. This is exactly the kind of evidence the winter real-user gate and your Definition of Shipped ask for.

A good write-up includes:

• the type of activity,
• the goal of the activity or hypothesis being tested,
• details on how the activity was conducted (e.g., questions asked, test groups),
• key findings, data, or patterns observed,
• an analysis of what the results mean for the project, and
• actionable changes or decisions based on the findings.

A good output is the write-up described above: activity type, goal or hypothesis, how you ran it, what you found, and what changes because of it.

Define your Personas

Team Activity

Read/browse Personas: Study Guide then create 2-3 personas relevant for your project and explain how they are being used to ideate or prioritize features. Consider splitting the content of the article between team members.

Some ideas to define personas:

• What is your ideal user’s current behavior?
• What do they want to achieve?
• Define the demographic profiles, goals, and a scenario use case.

A good output is 2 to 3 personas with demographics, goals, and behaviors, plus a note on which features they caused you to prioritize or drop.

Find Users

Individual Activity Recommended

Once you have created your user profile, you can now find places they are present. The internet has communities for every niche; try searching for communities relevant to your product on Reddit, Twitter/X, Hacker News, and other forums. Post on these platforms and engage with potential users. There are also many modern platforms that product and technology enthusiasts browse to discover new solutions to their problems, such as Product Hunt, Beta List, and Indie Hackers. Finally, you can reach out to your local community (fellow students, friends, clubs, etc.) as well.

Consider reading You Are Not the User: The False-Consensus Effect.

Keep a running summary of the outreach you’ve done, the mediums you’ve used, and the returns, e.g., people who have agreed to do user activities with you. This list of reachable people is the user access plan your Definition of Shipped requires. Consider the following marketing activities:

• Post a demo on Reddit, Twitter/X, Hacker News (or similar)
• Launch on Product Hunt or Beta List
• Distribute cookies for trying your software (or similar)
• Present at a conference or workshop

A good output is a written list of the communities and platforms where your users actually are, with the outreach you have already made.

Feeds: the winter repo checkpoint real-user gate, and the Definition of Shipped user access plan.

Engage Users

Individual Activity Recommended

Once you’ve found a good pool of users, engage them to gather feedback on your product. This can be done through social media posts, emails, surveys, demos, a public Discord/Slack channel, etc. Interview-style conversations should follow the Mom Test cheat sheet.

Write up the outreach you’ve done, the mediums you’ve used, and the feedback you’ve received from users.

A good output is a write-up of the outreach, the mediums used, and the feedback received.

Feeds: the winter repo checkpoint real-user gate.

Test with an Assistive Technology User

Team Activity Recommended

Run one task-based session with someone who uses assistive technology (a screen reader, voice control, switch access, or magnification) as part of their normal day. Use the same structure as any other usability session: pick two or three real tasks, watch, and do not help.

Expect to be surprised. Daily users navigate far faster and in different patterns than you will when simulating, and they routinely find in two minutes what a checklist misses entirely. Campus disability services, local accessibility meetups, and your project partner’s own users are the usual ways to recruit.

If that is not feasible in your timeline, the honest substitute is a session under simulated constraint: a teammate who did not build the feature completes the flow keyboard-only or with a screen reader on. Say plainly in your writeup that it was simulated. Simulation finds broken things; it does not tell you what daily use feels like.

See testing with assistive technology users for how this fits your wider testing strategy, and Designing for Accessibility for what to fix before you get here.

A good output is a list of observed failures with the task each one blocked, prioritized by whether it stops a user or merely slows them.

Feeds: the winter week 10 repo checkpoint real-user evidence.

UX Design Maturity

Individual Activity

Read The 6 Levels of UX Maturity (Absent, Limited, Emergent, Structured, Integrated, User-Driven) and complete the UX Maturity Quiz.

Write what needs to happen for you to move to the next stage. If your project involves user experience and no other significant technical elements, aim to reach at least Level 5, Integrated, by the end of the year.

A good output is your quiz result plus a written list of what has to happen to reach the next level.

Complete an IRB Application

Team Activity Recommended

Get human-subjects approval filed while there is still a year left to use it. A few hours to draft, then weeks of review you do not control, so start in fall week 1.

If your project involves faculty research and any kind of user testing, you need IRB approval. “User testing” is broader than students expect: interviews, surveys, and usability sessions can all count.

• Ask your faculty partner who files it. Usually they do, or their graduate student does, and they have done it before. This is not a form you should be discovering alone.
• Determine the review level: exempt, expedited, or full board. Exempt still takes weeks, and it is a determination someone else makes, not one you can assume.
• Draft the protocol: what you will ask, of whom, how you recruit, what data you keep, how you store it, and how you anonymize it.
• File it, then keep working. Design and build against synthetic or public data while review runs.
• Record the filing date and expected turnaround in docs/risks.md alongside your other approval clocks.

A good output is a filed application with a dated confirmation, and a line in your risk register naming who owns it and what is blocked until it lands.

Feeds: the Definition of Shipped prerequisites-and-lead-times criterion.