P1: Design

Milestone	Due date
Overview
P1: Design	Monday, October 5, 2026, 11:59 PM
P2: Alpha (MVP)	Tuesday, October 13, 2026, 11:59 PM
P3: Beta (complete functionality)	Monday, October 19, 2026, 11:59 PM
P4: Code complete	Monday, October 26, 2026, 11:59 PM
P5: User testing	Monday, November 2, 2026, 11:59 PM

Due Monday, October 5, 2026, at 11:59 PM.

Overview

Advice. Read the advice section before you start! It’ll help you succeed in this assignment, enjoy it more and complete it in less time. Note especially the part about keeping a design notebook.

Design elements. In this assignment, you’ll design the essential parts of the application you’re building for your personal project. These include: an articulation of the problem being addressed; an outline of the key features; a conceptual design comprising the main concepts (and a few representative reactions); some user interface sketches and a user journey explaining how some key features will be used.

Tasks

Design notebook. Keep a chronological Markdown notebook in your personal repository throughout the project. Record your design decisions and interesting moments: what happened, what you learned, and any relevant links to your work. Keep these notes to support your final reflection, which will be graded in P5.

Problem framing. Include a separate problem-framing section. You may copy or revise your framing from E1, taking account of feedback. Follow the problem-framing rubric.

Include a stakeholder list, with a name for each kind of stakeholder, and a sentence explaining their role (if any) in the problem.

Application pitch. Construct a succinct but compelling pitch that explains, in terms understandable to a lay user, how your application will solve the problem. Your pitch should be around half a page in length, and should include the following deliverables:

• A name: pick a fun and memorable name for your application.

• A motivation: summarize the problem that your application will solve in a sentence.

• Key features: explain up to three features in a brief narrative, ensuring that each has a name and a simple explanation of what the feature is; why it helps mitigate the problem; and how it impacts stakeholders. (See the note in the advice section on concepts vs. features.)

Concept design. Design a set of concepts that will embody the functionality of your app and deliver its features. We expect you to have 3-5 concepts. Fewer than 3 concepts would probably mean limited functionality or a lack of separation of concerns; more than 5 likely suggests overambition or lack of focus. (Talk to us if you think you need more!) The deliverables are:

• The concept specifications, written in the standard form.

• Some essential reactions. You do not need an exhaustive collection of reactions, but should capture (a) any essential design ideas that involve multiple concepts; (b) representative reactions for kinds of reactions that are common throughout your application (such as for access control or notification).

• A brief note, at most half a page long, explaining the role that your concepts play in the context of the app as a whole. For example, if you have an authentication or authorization concept, you should say how it’s used to control access to other particular concepts. You should also explain how generic type parameters will be instantiated whenever it’s non-obvious.

(For example, that a generic user type will be bound to the users of an authentication concept is obvious; that the targeted items of an upvoting concept are users would not be.)

UI Sketches. Construct some low-fidelity sketches of your user interface that show the primary user interface elements and their rough layout, annotated with pointers or comments to explain anything that might not be obvious. You should omit any error handling and standard interactions (such as user registration), but should aim to convey how the essential features appear and are used. You can use any tool you like to draw the sketches, or you can draw them by hand and scan them.

You should include them in your design document as images referenced in markdown.

User journey. Write a narrative that follows a single stakeholder as they encounter the problem and use your designed app to address it. Tell their story in chronological order: what triggers their need, the steps they take with the app (referring to the wireframes), and the outcome. A good journey should both persuade a reader that the problem is worth solving, and illustrate how your app might help solve it.

The deliverable here is a few short paragraphs that form a coherent story but identify individual steps clearly, and reference your sketches when appropriate.

Deliverables

Creating a new repo. Create a new public GitHub repository for your personal project. You will do your project design and implementation work in this repository. Keep your design notebook and personal reflections in your existing private individual repository.

Create a main README that serves as the single entry point to your complete design submission.

Your submission is a design document in Markdown in your public project repository, with clearly labeled sections for:

• Problem framing and stakeholders.

• Application pitch.

• Concept specifications, essential reactions, and the note explaining their roles.

• UI sketches.

• User journey.

The sections may link to separate Markdown files. These sections must be linked in the main README.

Submitting your work:

1. Create one or more files in your project repository that contain your design submission, written in Markdown. Include a link to your submission in the main README.

2. Keep your design notebook in your private individual repository, linked from its main README.

3. Make sure your work is committed and pushed in both repositories by the assignment deadline and save the commit hash for each.

4. Submit both GitHub repository links and their corresponding commit hashes through the P1 assignment in Commons by the assignment deadline.

Rubrics

Your work will be evaluated using these rubrics:

• Problem framing: your problem-framing section.

• Concept design: your concept specifications, essential reactions, and the note explaining their roles in the application.

• Communicating a proposed solution: your application pitch, UI sketches, and user journey.

• Technical writing: all written parts of your submission.

Advice

Start early. If you make an early start on thinking about your design, you’ll have it in mind over the next few days, and you’ll mull it over in the back of your mind and find both interesting flaws and interesting fixes without trying too hard. But if you leave the whole assignment until the last day, it will be hard to think creatively, and you’ll have much less fun.

Refining your problem framing. In refining your problem framing, you are free of course to reuse material from your earlier assignment, but you should make whatever corrections and improvements were suggested by your TA (and you should not feel shy to ask your TA for feedback on possible changes).

Scoping and focusing your app. As explained in the very first lecture, one of the greatest risks in a project like this is overambition: that you lay out a design that is just too much to implement in the time you have available. Another equally serious risk is lack of focus: that you hand in a design that is full of plausible sounding elements, but haven’t really distilled your ideas into a compelling set of features, backed up by well-defined concepts.

To avoid these risks, we suggest that you not rush into writing the assignment, but that you spend time thinking very carefully about what your app will do and how it will work, and that you ruthlessly reduce the features, concepts and sketches to the absolute minimum that is necessary.

A real app, not a proof of concept. Another criterion explained in the first lecture: your app should be real, so that it can actually be put into use immediately, and not a proof-of-concept that merely illustrates some interesting functionality but that is actually not ready for real use.

As explained in class, to achieve this you will need to ensure that your app is as simple as possible (so it has only the absolutely essential concepts); that it minimizes user friction (so no requirements of tedious data entry, for example); that it does not rely on a critical mass of users; and that it does not make unrealistic assumptions about the use of external services which might turn out not to be available.

How novel should your project be? Your project should not be a clone of an existing app, but should be novel. Ideally, it embodies some novel ideas, for example in a new concept or in the way in which some existing concepts are used together. But don’t sweat this too much. If you have a compelling problem, in a domain you understand well, and you work hard on designing an elegant and minimal solution to it, you will inevitably end up with something novel.

Daniel Jackson learned this lesson from a photographer called Arno Minkkinen whom he studied with at a summer workshop in 2006, where Arno explained his Helsinki Bus Station Theory of innovation, which has since become very popular with management consultants and creative advisors of all sorts.

Can you change your design later? Recognizing that design is always iterative, and that you will discover design flaws and opportunities during implementation, we anticipate that you will want to make changes to the design during the upcoming implementation milestones to the design you develop here. But we expect the design as implemented to be very close to the design described in this assignment, so you should think hard and carefully about your design and try to anticipate issues that will arise.

Otherwise, you will not have a strong basis for implementation and risk being mired in frustrating changes and backtracking.

Keeping a design notebook. A critical aspect of learning how to design is self reflection, in which you constantly analyze your own process, your successes and failures, and learn from them. In order to keep this assignment to a manageable length, we are not requiring that you include a self reflection with it. You will, however, be reflecting on all aspects of your project at the end.

In your notebook, record the issues that arise, the options you consider, and why you choose one over another. Keep entries brief and write them as you work.

Dialog with an LLM? One provocative idea you might want to consider: some software developers have found it helpful to record all their thinking as a dialog with an LLM (such as ChatGPT), in which they explain each step in their reasoning and ask the LLM for a response. This can be a good forcing factor to keeping the design notebook, and has the added benefit of sometimes stimulating responses from the LLM.

Concepts vs. features. Your features will generally not correspond directly to concepts. Concepts are the building bricks of user-facing functionality from which your app is constructed; features are what users experience when concepts together bring value in addressing a particular need. Consider the feature example for an app to help people find movies to watch:

Wish List: You can add a movie that you’ve heard about and want to see (but maybe missed when it was in theaters) to a wish list, and when it opens on a streaming platform that you’ve subscribed to, you’ll get a notification that it’s now available.

Realizing this feature might require four concepts: a Wishing concept for recording the user’s wishes; a MovieReleasing concept that determines when movies are released on particular platforms; a Subscribing concept that tracks which platforms a user has subscribed to; and a Notifying concept that sends updates when certain events occur.

UI sketches and visual design. The purpose of the UI sketching is to explore fundamental user interaction decisions, and not to finesse the visual design. So make them as clear and simple as possible, but do not spend time on colors, typography or layout. Consider making them monochrome to avoid the temptation of getting caught up in visual design. If you enjoy visual design, you’ll have the opportunity later during implementation to make your user interface as pretty as you like! For a short demonstration, see Nielsen Norman Group’s How to Sketch a UI for Non-Designers.

Concept independence. Remember that when you define your concepts, they should be independent of each other. Whenever one concept uses a set of objects that comes from another concept, it should do so completely generically, without relying on any properties of those objects. This requirement is hard because it forces you to introduce modularity early on.

Often, developers are sloppy about this and then they have to introduce modularity in the code, when everything is more complicated and that can require a lot of reworking. Put another way, it’s a difficult task whenever you do it, but it’s easier to do at the design phase, and will make coding much easier. You might find it helpful to review the lecture on modularity and the associated slides.

Use the background docs. The lectures, recitations, and exercises have given you a general overview of concept design. Now that you are developing a complete project, you will certainly need to refer to the background docs linked on the resources page. These contain everything from basic introduction to concept design, detailed reference material on how to write formal concept specifications, and advice on good design. You might find it useful to provide these documents as input to LLM agents, either to enable them to confidently answer questions you have about concept design, or as coding assistants.