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 syncs); some user interface sketches and a user journey explaining how some key features will be used.

Tasks

Problem statement. In your first assignment, you brainstormed a set of problems that your project might address. You should now pick one of those problems and refine it for this assignment. Your problem statement should be less than one page in length, and should include the following deliverables:

  • A problem domain, with a title and a few sentences explaining it. Remember that a domain is not a particular problem but an area of activity that you are involved or interested in. Your explanation should include what your connection is and why you care about it. (See examples in the first assignment.)
  • A problem: one key problem faced by users within this domain, with a title and a few sentences explaining it. Remember that a problem must be a difficulty experienced in the problem domain by users; it should not be a flaw or limitation of existing solutions.
  • A stakeholder list, with a name for each kind of stakeholder, and a sentence explaining their role (if any) in the problem.
  • Evidence and comparables: a list of pieces of evidence that the problem is real, which will likely be citations of publicly available resources (but could also be observations that you have made about the extent or nature of the problem), and some comparables, being applications that address this or a related problem. Your list of evidence and comparables should have at least 5 entries, each with a title, an optional link, and a sentence or two explaining it.

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 synchronizations. You do not need an exhaustive collection of synchronizations, but should capture (a) any essential design ideas that involve multiple concepts; (b) representative syncs for kinds of sync that are common throughout your application (such as syncs 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 that reference your sketches when appropriate.

Submission process

Submitting your work is a 3-step process:

  1. Create one or more files in your GitHub porfolio that contain your responses, written in Markdown. Include a link to your assignment in the main README. Make sure your work is committed and pushed by the assignment deadline and save the commit hash.
  2. Fill in the submission form with your GitHub repo link and commit hash by the assignment deadline.
  3. Fill in the survey form within 24 hours after the assignment deadline.

Rubric

Skill Description (what good work looks like) Common Failures (examples of falling short)
Problem framing Description of problem domain shows insights into an area of human activity; problems are credible and serious; evidence adds information regarding extent or nature of problem; comparables are relevant, offer useful starting points, or show clear limitations Problem domain is unclear or contrived; problems seem minor, or are limitations of existing technology; comparables are not strongly related, or appear to solve the problem adequately
Pitching an application idea Name is catchy and memorable; motivation is a cogent and compelling summary of recognizable problem; features are understandable, appealing and clearly offer a solution to the problem Name is obscure or fails to convey any of the ideas in the application or its domain; motivation is unclear or not compelling, does not summarize problem effectively; features are not readily understandable, are unconnected to problem or do not seem to address it in an effective way
Designing concepts Concepts meet the criteria for good concepts: they are purposeful, easy to understand, provide an effective mechanism to deliver their purpose, and are independent from other concepts Concepts are muddled or unclear; concepts have purposes that would be fulfilled by more familiar concepts; concepts refer to one another and are not properly independent; concepts treat external types in a non-generic way, making assumptions about them that rely on knowledge of other concepts; concepts do not have clear purposes or operational principles; states and actions are not specified correctly or are insufficient for providing functionality that will satisfy the purpose
Designing syncs Enough syncs are included to show how the concepts work together, and how data flows between them; the syncs follow the declarative when/where/then pattern; syncs are granular, separating out linkages that can be defined independently Not enough syncs are included to understand how concepts are composed and how generic types are instantiated; syncs violate the pattern and look like imperative code and use if-statements and loops; syncs are not granular rules but more like scripts that execute sequences of actions
Sketches Sketches clearly depict the primary interactions, avoiding peripheral or trivial functions; sketches are neat enough to be understood at a glance, and layout communicates intended relationships between elements (navigation, content, controls); annotations (if included) clarify purpose or interaction, without overloading the sketch; sketches show structure and function, not polished design or styling Essential interactions are missing; sketches are vague or ambiguous, or are too rough or poorly labeled for others to tell what the elements mean; drawings resemble high-fidelity mockups; core elements shift unpredictably between sketches; not clear how user moves from one screen to another
User Journey Narrative Presents a clear, engaging story of a stakeholder encountering the problem and benefiting from features, illustrating value Journey is flat and lacking insights; journey does not connect user motivations and needs to features; journey is unclear, or fails to show how features address the problem

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) assignments 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 order to make that reflection easy and productive, we strongly recommend that you keep a design notebook throughout your project of your ideas, questions and decisions as you go along. A simple markdown file (or a pencil and paper notebook) in which you can jot observations down as they arise will work well.

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 from your earlier assignment 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 wish list concept for recording the user’s wishes; a streaming availability concept that determines when movies are available from particular platforms; a subscription concept that tracks which platforms a user has subscribed to; and a notification 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!

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 do 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 lectures on modularity and their associated slides.

Identifying concepts. See this tutorial on criteria that you can apply to ensure that your concepts really are coherent concepts and not just arbitrary pieces of functionality. You can also read more about identifying concepts in Chapter 2 of Daniel’s book: The Essence of Software.

Writing concept specs. The concept notation is pretty minimal, so try and keep your concept specifications short and to the point. Include only the essential actions. Any additional commentary that you might want to include should be in a notes section at the end of the concept specification. You can use the concept design rubric as a checklist for your concepts: here in PDF and here in Markdown. There is an overview of the concept state declaration notation here.

Using LLMs. You are welcome to use an LLM to help you with this problem set, but you should not expect an LLM to have sufficient knowledge of concept design to generate concept specs reliably. You can use the rubric and guide documents in your prompts (for example when asking an LLM to review your concept models).