Assignment 5

Assignment by Mara Bravo-Santos.

Due Tuesday, October 13 at 1:30 pm Pacific

---

This assignment is the second in our two-part series on design. In Assignment 4, you researched student life, talked to people, and identified a concrete problem worth designing for. In this assignment, you'll vibecode part of a website designed to address that problem. You will then take that task through one design loop: create a wireflow, explore different visual directions, build the prototype, check your work, watch someone use it, and refine the prototype.

Step One: Get the Starter Files

Your first step is to clone the repository for this project. The repository lives at the URL https://github.com/cs193v-students/a5-<your-sunet>, where <your-sunet> is replaced by your SUNetID (e.g. htiek, szum, cbl, poohbear, etc.). For example, your TA Mara would use the URL https://github.com/cs193v-students/a5-mbravo13.

Step Two: Narrow In on One Task

You ended Assignment 4 with a problem worth designing for. If you had unbounded time, we're confident you could vibecode an amazing piece of software to address it. But you only have five days for this full assignment, and so your first task is to decide which part of that problem your prototype will address.

For example, suppose your research showed that students have trouble using the Marguerite shuttle because it is hard to tell where the bus is and whether they can make it to the stop in time.

You could design around this specific task:

Your prototype might show the student's location, the bus location, the stop, and how long they have to get there. It does not need route planning, saved trips, notifications, transit history, or every other feature a transportation app could have.

Here are a few more examples of options appropriately-scoped for this assignment:

• If your problem is that students have trouble deciding where to eat because dining information is spread across different places, you could design around choosing a dining hall for dinner based on tonight's food and hours. Your prototype might let someone compare a few dining halls and view details for one of them.

• If your problem is that students have trouble figuring out where to get help when they are stuck on coursework, you could design around finding an office hours session the user can attend today. Your prototype might show available sessions and enough information to choose one.

• If your problem is that students want to get off campus on the weekend but have trouble deciding what to do, you could design around finding one activity the user can get to this Saturday afternoon. Your prototype might show a small set of options and help someone choose among them.

Come up with a specific task you think is appropriately scoped. Chat about it with your coding agent; we've instructed it to ask you questions to help you refine your task description. Once you're happy with it, keep the final wording somewhere you can refer back to later. If you want, you can ask your coding agent to create a notes.md file in your repository and save the task there for you.

Step Three: Create a Wireflow

In class, you sketched a wireflow, a set of rough screen sketches connected by arrows showing how your website responds as the user interacts with it.

Look at your wireflow again with the task from Step Two in mind. If you didn't complete your wireflow in class, finish it. If your wireflow was for a different task than the one you chose in Step Two, create a new one. If you got feedback from classmates or learned something from your first attempt, revise it.

Ask yourself:

• Can I trace the task from a clear beginning to a clear end?
• Does each screen help the person complete that task?
• Is the main action on each screen clear?
• Is there anything in the flow that I do not need?

Keep it small. Two to five screens is a good target. If an action changes what appears without taking the person to a new screen, include sketches for each version of the screen. For example, if tapping a button opens a popup on top of the current screen, draw the screen with the popup open as another box in your wireflow.

Once you have your wireflow ready, get your wireflow onto your computer as an image. If you drew the wireflow on paper, take a picture with a camera and upload the photo to your computer. If you drew the wireflow on your computer, export it as an image. Rename the file wireflow while keeping the existing extension (e.g. wireflow.png, wireflow.jpg, wireflow.heic, etc.). Then put it inside the design folder within the git repo you cloned. If you're not sure where on your machine that lives, ask your coding agent to tell you.

Commit and push your work to GitHub before you proceed.

Step Four: Try Out Your Style Tile

In class, you also made a style tile, a visual reference for choices such as typography, color, controls, spacing, and overall visual direction. Before using your style tile to build the real prototype, see what your coding agent thinks it means.

First, get the style tile from class onto your computer as an image. Move it into the design folder and rename the file style-tile, preserving the file extension. Then, start a new session in your coding agent (open a fresh instance if one isn't running, or use /clear to start a new session in an open one) and give it the following prompt:

Open the preview in your browser. The point is to see how the coding agent turns the style tile into a UI before you do the big lift of making a prototype.

If the result is not what you had in mind, change the style tile and try again. You might change a few descriptive words, swap an image in the moodboard, adjust a color, or change another part of the visual direction. Repeat as many times as you find useful.

Make sure that the final version of your style tile is in the design directory and named style-tile (with some image format suffix, like .jpg or .png). Then commit and push your work to GitHub.

Step Five: Create the Prototype

You now have everything you need to start vibecoding. It's time to ask your coding agent to make something.

You will need to instruct your coding agent on what it needs to build and how to make use of the files in your design folder. Although coding agents usually are smart enough to write tests and meet accessibility guidelines without instructions, they aren't (yet) consistent about this. Thus you'll need to guide the coding agent with your prompt to ensure it tests what it builds for correctness and accessibility.

There are lots of different ways you could prompt your agent to do this. Here's one possibility. You're welcome to use this if you'd like, or you could come up with your own.

Once your coding agent has finished conjuring something into being, commit and push so that your original version is backed up. Then, ask your coding agent to tell you how to open the website. This may be as simple as double-clicking on a file, but more likely you're going to need to run a command inside the development environment and open a specific link in your browser.

You now need to do manual testing to make sure your prototype works as intended. Chances are that it will have some aspects you'll want to correct: the visuals might not be exactly right, there may be software bugs, etc. If you were building something you wanted to use on a daily basis, or something you wanted to release to a larger group, you would want to fix most of the issues you find. For the purposes of this assignment, though, only fix issues with your website that make it difficult or impossible to use. (These are sometimes called release blockers.) You've seen how to report bugs and get your coding agent to fix things in Assignment 3, and you can use the same workflow here.

At this point your work should already be committed and pushed (either from the original version, or after each bug is fixed). But if not, do that now so that you have a backup.

Step Six: Conduct a User Test

You now have a working prototype. Is it easy to use? Can someone quickly figure out what they're supposed to do? The best way to find out is to conduct a user test: give your prototype to another person and see how they use it.

You'll first need to find someone to try out your prototype. In the previous assignment, you identified a specific group of people you were designing for. You can choose anyone in that group to test out what you made. Feel free to ping the people you interviewed in the previous assignment, or to post on EdStem to see if any other CS193Vers are available.

For the purposes of this assignment, we would like you to conduct a user test by following this specific sequence of steps.

1. Set up your prototype. Launch your website the way you did in the previous step, and ensure it's ready for someone to use.

2. Explain the task, and nothing else. Your goal is to observe how a person interacts with your prototype. They need to know what task your prototype is designed to help them perform. Give them the task you came up with in Step Two of this assignment, but do not provide any other context. Don't explain how to use your website. Don't explain the design rationale, why you selected your particular solution, etc. This may seem strange or even unfriendly, but it really is important. You don't want to give the tester any preconceived notions of how the program is supposed to work. They should be looking at it with a fresh pair of eyes, the way you would if you visited a new website for the first time or downloaded a new app on your phone.

3. Tell your volunteer to begin, and start a 15-minute timer. You shouldn't need more than 15 minutes for this test. If things go long, cut them off at 15 minutes.

4. Quietly observe and take notes. Resist the temptation to tell the user where to click, or point at controls, or explain what something means. If they ask what they should do, tell them to do what they would normally try if you were not there.

   Take as many notes as you can. Write down whether they complete the task, what path through the software they took, which places they paused, where they clicked on the wrong thing, where they had to back up, etc. If they hesitate or take a path you did not expect, make a note of it.

   Every urge to explain is a bug worth noticing. If you feel like you need to step in and help out, it likely means there's something about the design you need to change in the future. Be sure to write those moments down!

5. Once finished, ask questions. When the user has finished the task (or if the timer goes off), conduct a brief exit interview. If you were conducting a proper user test, you would ask structured questions to try to better understand the user's thought process. But for the purposes of this assignment, feel free to ask any questions you'd like. And feel free to have fun showing off any features of the prototype that they missed, to talk more about the process of making it, etc.

Once you've finished, save a copy of your notes into the repo directory. If you took notes by hand, include a photo. If you typed up your notes, save a plain-text file or PDF. Then commit and push.

(Optional) Step Seven: Iterate

If you were designing a piece of software you wanted to deploy IRL, at this point you would look over your notes, identify areas for improvement, and then ask your coding agent to refine the software. But you've already done a lot in this assignment, so we aren't going to require that you do so. If you have the time, though, we recommend having a chat with your coding agent about what you saw and using that to update your website to make it easier to use.

Step Eight: Rejoice!

And that's it! You're done. Go wander around the huge marble spheres in the Engineering Quad and enjoy the sunshine.

More to Explore

If you want to look more closely at the usability and accessibility guidance used in this assignment, check out these links:

1. Nielsen Norman Group: 10 Usability Heuristics for User Interface Design
2. W3C: WCAG 2.2, Contrast (Minimum)
3. WebAIM: Contrast Checker