INF320U App Prototyping Studio
HW Instructions

Published

August 27, 2026

Ninety percent of your grade comes from the work described here. Note that the syllabus describes the attendance policy. That accounts for the final ten percent. Note that this document augments the syllabus. The syllabus is the final authority in case of conflicts. Conflicts should be brought to the instructor’s attention as soon as you see them.

Component	Weight	Due
Sketches (six batches, 5% each)	30%	weeks 6, 7, 9, 12, 13, 14
Project deliverables (three, 5% each)	15%	weeks 2, 4, 4
User testing (three rounds, 5% each)	15%	weeks 5, 8, 10
Bad UX	5%	week 11
Final presentation	15%	weeks 13–14
Final reflection	10%	final exam time

The syllabus schedule gives the week each item is assigned and due. Canvas carries the authoritative due date and time for each assignment. In case of conflict, Canvas wins.

Rules that apply to everything

Submission

All work is submitted via Canvas. Don’t send me any attachments in emails or I will deduct points from the relevant score!

Reports are delivered as PDF, not Word or Pages or Google Docs links or anything else. Disregarding this instruction slows down my grading and results in a deduction. Please do not double space your reports. I will deduct points for double spacing.

Every assignment below names the file you are to submit. Any deviation from those names slows down my grading scripts and results in points deducted, including the first time you do it.

Working as a team

You design an iOS application that the Computer Science students on your team build. Some deliverables are individual and some belong to the whole team; each assignment below says which. For a team deliverable, every member submits the same file in Canvas so that everyone has a submission of record.

Your teammates depend on you and you depend on them. See the syllabus for what happens when a team member contributes little or nothing to a phase.

AI appendix

Every report should include an AI appendix. This is a short section or sections that include three things: The exact tool used, the exact version of the tool, and the exact prompt or prompts used to generate the content.

The AI appendix helps me evaluate how you are using AI tools. It is not to be used to generate the entire solution, but to help you think through a problem or to generate ideas or generate content such as lorem ipsum text that would be tedious to enter manually. If you don’t include this, I will deduct points from your grade. If you use AI tools, you must include this appendix. If you don’t, you don’t need to include the appendix but, in today’s climate, I will be skeptical of claims that you didn’t use AI tools. It is not a requirement to use AI tools, but if you do, you must include this appendix.

By exact tool, I mean the name of the tool, such as “Qwen 3 Coder” or “Claude Opus 4.5” or “Gemini Pro” or something similar. By exact version, I mean the version number and any extra name, such as “ChatGPT 5 Thinking”. It is not enough to say “ChatGPT” with no qualifier. You should know the actual tool you’re using at all times.

You do not need to include trial prompts whose output was not used. You do not need to include the prompt’s output (except in the body of the assignment, of course). Most AI tools will offer a transcript of your conversation. If you can not get that, you should see me or an expert in the AI tool use to help you get it. If you can’t figure this out even with help, you will find yourself in trouble in the contemporary workplace.

If you use AI tools in a way that doesn’t involve prompting, document it as clearly as you can. For example, I use the autocomplete feature of Qwen 3 Coder in my text editor and will sometimes press tab to accept a phrase or sentence. It would be awkward to try to document each phrase I accept, so I just provide a paragraph covering my blanket use of the tool in any prose that I write.

What I am looking for

The syllabus explains how I grade in detail: a mechanical completeness check first, then judgment, with no rubric. Three things are worth repeating here because they apply to every deliverable.

Solving the right problem. Is the problem real, and did you show me that it is rather than assert it?
Thoughtfulness of the solution. Are your alternatives genuinely different approaches, or one idea in several guises? Did you choose among them for reasons a colleague could argue with?
Craft of presentation. This one breaks down cleanly into color, typography, layout, navigation, and animation, plus the ordinary care of proofread prose, labeled figures, and cited sources.

Beyond that: say both good and bad about your own work, be as detailed as you can be, refer back to the original problem when you present a solution, and give special attention to obvious gaps in your thinking about the problem. Could a reader who was not in the room follow your reasoning from the problem to the decision? The mark of strong work is that I learn something from reading it.

Project deliverables (15 percent of your grade)

Overview

These three deliverables start your team’s semester project. They are the handoff from you to your developers, so the standard is not “does it look nice” but could a developer build this from what you handed them without guessing?

Onboarding lofi, 5 percent

This one is individual, not team, and it comes before teams are settled. Following the onboarding workflow exercise we do in class, produce a lofi prototype of the first-run experience of an app: what a brand new user sees, in order, from launch to the moment they can do the thing the app is for.

Pencil and paper is fine and often better at this stage. Photograph or scan it.
Show every screen in the sequence, in order, with the transitions labeled.
Show at least two places where onboarding can go wrong (permission denied, no network, sign-in fails, user wants to skip) and what happens then.
Add a paragraph or two of text explaining the choices you made and what you left out on purpose.
Deliver as a PDF named onboardingLofi.pdf.

The objective is to learn how much of a design has to be specified before someone else can build it. Most people undershoot the first time. The empty states and the error paths are where the real design work is.

Project proposal, 5 percent

This is a team deliverable, written with your Computer Science teammates. The goal is an app that they can actually build in one semester and that you would be glad to have in your portfolio.

Your app will be an iOS app supporting a job seeker. This document will be updated to give more detail. Your Computer Science teammates will also receive more specifics. r app will be an iOS app supporting a job seeker. This document will be updated to give more detail. Your Computer Science teammates will also receive more specifics.

Deliverables for the proposal

A PDF named proposal.pdf containing the following sections.

An introduction to your app idea
A description of the problem you are solving
A description of the users
A description of the solution you are proposing
A list of features you will implement
A list of features you will not implement
A note on scope: what makes this buildable in iOS by your teammates in the weeks available

Note that you may modify these features later in the project process. Say who wrote what, or at least who did what.

Onboarding workflow, 5 percent

This is a team deliverable and it is about your project, not a generic app. Take what you learned from your individual onboarding lofi and specify the onboarding of the app your team is actually building, at the level of detail your developers need.

Every screen, in order, with the navigation between them.
Every state of every screen: empty, loading, error, success.
The decisions a user can make and the consequence of each, including declining and skipping.
What persists between launches and what does not.
Anything your developers have to obtain from Apple or a third party (permissions, sign-in, notifications) and when it is asked for.

Deliver as a PDF named onboardingWorkflow.pdf, with a link to the Figma file if the work lives there. Include a short section recording where you and your developers disagreed and how you settled it. That section is not a confession, it is the interesting part.

User testing (15 percent of your grade)

Overview

You test three times and report each time: once on paper, and twice on running software.

user testing of lofi sketches (5 percent), due week 5
user testing of the alpha release (5 percent), due week 8
user testing of the beta release (5 percent), due week 10

Rules for all three rounds

Each student conducts two sessions per round with two different users. Testing is not a team task you can divide up. Everyone interviews.
Across the semester, at least one of your sessions must be unmoderated via Usertesting.com. Do that in the alpha or beta round, when there is running software to put in front of someone. The paper round is moderated, in person, by you.
Every other session may be done in any way you prefer, moderated or unmoderated, via Usertesting.com or any other method.
You can do one test setup on Usertesting.com and use it on up to three users. That gives you some padding in case a test doesn’t work out.
You should include survey questions in your test. You may find it useful to consult the website for the book Rocket Surgery Made Easy by Steve Krug. It has examples of most, if not all, of what you need.
You should not keep records of the identity of the test participants. You should not record their names or email addresses.
You must use a consent form although Usertesting.com may have that built in for anyone you get there.
Keep in mind that you may, if you wish, invite your own users to Usertesting.com or use their participants. Keep in mind that their participants are not necessarily great for your specific project. Their users want to be paid and probably have a requirement (that they don’t like) to do a number of free tests for eligibility.

Deliverables for each round

A PDF report, named testLofi.pdf, testAlpha.pdf, and testBeta.pdf respectively, containing

Your methodology, including how you recruited and why those participants made sense for this app.
Your findings and insights, with quotes from participants supporting each insight.
Images of the prototype, annotated, showing what you are talking about.
What you would change in the prototype and what you will not change.
Appendices with your testing materials: consent form, protocol, script, survey questions, notes, and screenshots of your analysis if you use Usertesting.com. Two copies of each thing, because you did two sessions.

Acting on the results in the alpha and beta rounds

For the alpha and beta rounds, the report also has to show what you did about what you found. Start by assigning a severity rating to each issue mentioned by your participants.

Major issue
Moderate issue
Minor issue
Not an issue

Second, decide which changes to actually make, and document your decision-making process. Not everything a participant says is a defect, and saying so with a reason is a design judgment I want to see you make.

Third, actually make the changes in Figma or a similar tool, and show the before and after.

Pay special attention to

Level of review and analysis of previous work to identify opportunities
How you rate your severity levels
Thoughtfulness of implemented changes
Clarity in communication to someone reviewing your work

Why do this?

It encourages you to find participants matching your target audience.
It improves your interviewing skills by conducting more than one test total per student.
It identifies valuable insights that can be translated into action items for the next prototype.
It helps you develop a method for user testing.

What are lessons learned from previous submissions that we should incorporate?

You should discuss the target audience and address your success level in finding relevant participants.
Images of the prototype with annotations to help explain recommendations should be included in the report.
There should be “show your work” type discussions of your analysis and insights.
There should be quotes from your participants to support your insights.
Discuss errors or issues you encountered during testing.

More evaluation criteria

Quality of insights

Are the insights practical?
Do the insights add value or solve problems?
Are the insights detailed and have specific rationale?

Easy to understand

How well were the insights explained?
How well were findings summarized in digestible points?
How well were images of the prototype used to explain the process and findings?
Was the report understandable to a person without exposure to the prototype?

Method

How well did you understand the chosen method(s)?
How well did you explain your process?
How good was your execution?
Did the chosen method(s) make sense?
Did the chosen participants make sense?
Did your testing have the capacity to tell you that you were wrong?

That last question is the one that separates real testing from a demo with an audience.

Sketches (Lofi Prototypes) (30 percent of your grade)

Overview

You will keep a 5×8 inch (approximately) sketchbook throughout the semester. This may be a Moleskine Cahier or similarly sized sketchbook. The size is important. A significantly larger or smaller sketchbook invites you to sketch differently because of the dimensions of the adult human hand and pencils. You will submit three sketches for each Sketches exercise: one that will be specified in class, and two examples of good design that you find in the wild. You will submit photographs of these three sketches to Canvas. The sketches for the first assignment will be named sketch1a.png, sketch1b.png, and sketch1c.png. For the remaining assignments you will increment the numeral. Any deviation from of these names slows down my grading scripts and results in points deducted, including the first time you do it.

Why do these sketches by hand? In the workplace, former students have told me that at least thirty percent of their time is spent at a whiteboard. Hand-eye coordination is of paramount importance in their work. They have repeatedly told me that the sketchbook was the most important part of their UX education.

Details

Good design sketches

For each and every Sketch assignment, you will include two sketches of good design in addition to the assignment described below. These are designs you find that have been designed by humans. Trees or other living things or mountains or rock formations are not acceptable. Your designs will typically be physical or digital products designed by human designers, facing all the challenges that designers face.

Sketch 1: Graphical self intro

Make a sketch that introduces you as a UX design student. If you are not a UX design student, introduce that aspect of yourself that was motivated to take a UX prototyping course. This sketch could be a self-portrait, a narrative of your journey to your present location, a collage of things that are important to you as a UX design student, or an abstract image that may convey that you are hard to describe or wish to remain a mystery to your classmates. It can be anything as long as it is a sketch that you spend enough time on to improve your sketching skill.

The objective of this assignment is to communicate yourself to your classmates.

I want you to express yourselves as fully as possible. If I give you a list of parameters, I’m afraid that the graphical self intros will all look alike. It would be as if I told you how to dress and how to cut your hair so that you would all look uniform. That might please me if I were running an army, but that is not a good way to start a design class. Learning to follow instructions teaches you to follow instructions. Is that really what you want from a design class?

Of course, there are always constraints in design. In fact, it has been said that design is all about constraints. But don’t ask for more constraints than are already imposed upon you. For this assignment, I want to make a nice pdf of all the submissions. That gives you an important constraint to make it easy to view. You’ll want to use really good lighting to get the best picture of the page you draw. That should be constraint enough. (Some people really struggle to meet that constraint despite the widespread presence of sunlight!) Another constraint is that the picture should be in focus. (If you can’t figure out a way to focus a picture, or don’t care enough to do so when you’re given a week to do it, I question your commitment.) That is constraint enough. Whether it’s landscape or portrait is really up to your creativity and how you want to lay out the elements you draw. Whether you illustrate yourself, or objects meaningful to you, or words that describe you, or something completely abstract that puts your feelings in the foreground, or something that I haven’t imagined yet—all that is completely up to you. You should be glad of this freedom and use it to make something you really like!

Sketch 2: Record interaction

Spend a total of 25 minutes interacting with an app and documenting your experience, using mainly a series of about three dozen to four dozen pictures, each about 2 cm to 3 cm square. The interaction itself may last only a minute of the 25 minutes or perhaps it is used intermittently during the 25 minutes. Employ very few words. Pictures should tell the story. Make it clear how the app display changes and what your interactions with the app are. Be specific. I should not have to wonder what the consequence was of pushing a particular button. I’m not looking for impressionism as much as something that the developer of the app could learn from. Only include enough about the surroundings to clarify the interaction. In other words, if it is a jogging monitor app, I don’t need to see a bunch of pictures of a person running around. One at the start and end are probably enough unless you have issues caused by the surroundings.

One strategy might be to start with a screen recording and then to determine which frames are critical to understanding, then to draw only those frames and use drawing skill to make them come alive so that we see action rather than stasis.

The objective is to learn to describe interaction. Notice how difficult it is to isolate the interaction from its surroundings. Try to disambiguate what you are communicating in each picture. Plan the narrative.

Sketch 3: Map interface for smartwatch

For this exercise, your task is to design a screen for a wearable smartwatch device, such as Fitbit, Apple Watch, Samsung Galaxy, or similar. Given the limitations of these small devices, including restricted screen size and limited navigation controls, as well as the variation in device shapes (rectangle, circle, or long-rounded rectangle), your challenge is to create a user-friendly navigation interface for a map app.

Considering the inherent constraints of smartwatches and the fact that they may not offer the full feature set of a corresponding smartphone app, focus on providing users with clear turn-by-turn directions, highlighting key points of interest, and offering alternative routes. The primary goal is to optimize the user experience within the confines of a small smartwatch screen while avoiding interface clutter.

To achieve this, prioritize essential information and design the interface to be glanceable, ensuring users can quickly absorb details. Optimize information density and layout for the limited screen space, emphasizing the most vital information for navigation.

Consider the diverse features that wearable devices offer, such as voice guidance and haptic interactions. Use these features to enhance the user experience, providing alternative ways for users to interact with the map interface beyond traditional touch gestures and button controls.

In summary, your design should tackle the challenges posed by small screen sizes, limited controls, and diverse device shapes, ensuring a user-friendly navigation interface that utilizes the unique features of wearable devices while accommodating the option for users to access clearer guidance on their phones.

Sketch 4: User-centered music player

Visit the Play Store or the App Store and look at reviews of music players. Design a niche music player that fulfills some (not all) of the needs you find in these reviews. Try to refrain from making it look like the myriad nearly identical players available in these two stores.

Sketch 5: Auto collision center assistant

Automobile collision centers have to buy body parts for the cars they repair. In my personal experience, they sometimes let the customer see the desktop application they use to shop for parts. Design such an application with this in mind. It should allow the user to compare parts. For example, the OEM (original equipment manufacturer) prices parts above the average for aftermarket parts but offers a stronger warranty. Keep in mind that a customer may be looking over the user’s shoulder while using the application.

Sketch 6: UX for a thousand story elevator

Design the user experience for an elevator that can stop on any of a thousand floors. Bear in mind that this is a single elevator that can stop on any floor from ground to top. Bear in mind that there has never been a building more than a tenth the size of this one, so you would do well to completely rethink the concept of an elevator. You will receive little credit for a design that mimics existing elevators. Also bear in mind that a journey from the bottom to the top uninterrupted by stops would take at least half an hour.

You may take inspiration from the only building in history that was designed at such a size. This was the X-Seed 4000, a concept conceived by Tokyo city planners and elaborated by the Taisei Corporation in the 1990s. They envisioned this building being the size and shape of Mount Fujiyama and housing an auxiliary city to Tokyo of over a million people.

Following is an illustration of a comparison between the proposed design and the Burj Khalifa (at that time called the Burj Dubai), the world’s tallest building.

Size comparison between XSeed4000 and Burj Khalifa

Bad UX (5 percent of your grade)

Find an instance of bad UX in the wild, document it, diagnose it, and propose a fix. Read Norman’s The Design of Everyday Things, chapter one, before you do this. It gives you the vocabulary—affordances, signifiers, mapping, feedback, conceptual models—to say something more useful than that a thing is bad.

Two parts, in this order.

Before the Bad UX class day, upload a picture of your example to Canvas, named baduxa.png. We use these in class, so a late upload is worth nothing to anybody. The picture has to make the problem visible without you standing next to it explaining.
A short report, named badux.pdf, containing your diagnosis and your fix. Include a sketch or mockup of the fixed design, named baduxb.png, in the report as well as uploaded separately.

The diagnosis should say what the design led the user to expect, what actually happened, and which property of the design produced the gap. The fix should be a design, not a complaint: show me the thing redesigned, and say what your fix costs. Real fixes have costs—manufacturing, screen space, an extra tap, a retrained user—and naming yours is part of the work.

Be warned that this assignment is easier to do badly than any other in the course. Noticing that a door is confusing is a very small step. Everybody can do it, and a semester of pointing at bad doors teaches nothing. Getting design right is hard, and the grade here is mostly in the fix and the reasoning, not in the find.

Final presentation (15 percent of your grade)

Your team presents the finished prototype and the app built from it, including a live demo, during the last two weeks of class. This is a joint presentation with your Computer Science teammates, and both halves of the team present.

What to cover.

The problem, and the evidence that it is real. Do not skip this to get to the screens faster.
The design, shown rather than described.
A live demo of the running app.
What your user testing changed about the design. Name at least one thing you got wrong and fixed.
What you would do next with another semester.

Advice.

Rehearse it, out loud, with the timer running. Almost every unrehearsed presentation runs long and finishes on the least interesting material.
Decide in advance who says what and who drives the demo. Handoffs are where presentations fall apart.
Have a fallback for the demo. Record a video of the working app and have it queued. Live demos fail, and the failure is only a disaster if you have nothing else.
Craft of presentation counts here as much as anywhere: color, typography, layout, and the discipline not to read your slides aloud.
Leave time for questions and answer them directly. “We considered that and chose otherwise, because…” is a strong answer. So is “we did not think of that.”

Final reflection (10 percent of your grade)

The final exam is a take-home reflection document, delivered in pdf format, not Word or any other format. Disregarding this instruction will slow down my grading and result in a deduction of one of the five points.

The reflection tests the learning objective be able to articulately describe and evaluate tools and techniques for prototyping with five questions, each worth one percent of your grade, such as “Describe how you used story mapping in your project and tell what else you could have done with story mapping that you didn’t do.” The exact five questions will be disseminated on the last class day and the document is due at our final exam time, which will be announced.

Answer from your own project. Generic answers about what a technique is in general get very little credit; the question is always what you did with it, what it got you, and what you left on the table.