Overview. This project milestone continues the process we followed with the individual assignment: starting with your ideas from the previous milestone, and then iterating, evaluating, and refining them to converge on the ultimate design of your application ready for implementation.

Your Tasks

  1. Functional Design. Flesh out the conceptual outline you had constructed in the previous milestone, in response to issues you might have noticed while storyboarding or ideas you have had since. You are, of course, not beholden to your outline from P2: you can adjust, replace, or remove concepts as needed.

    Explain your conceptual design more thoroughly this time round. Each concept should have the standard parts (name, purpose, principle, state, and actions). You can write the principle informally, so long as it’s clear which actions are being referred to. The state should be defined using sets and relations. The actions can be written informally, or using the set/relation syntax illustrated in class. Define the app-level actions as synchronizations of concept actions, and instantiate generic concepts with appropriate types. Draw a dependency diagram showing the possible subsets.

  2. Wireframes. Construct a set of wireframes that shows the user interface elements and their layout, and includes the main flows. You can omit error handling and completely standard interactions (such as user registration), but your wireframes should otherwise be enough to cover all your concepts.

  3. Heuristic Evaluation. Conduct a heuristic self-evaluation to assess the usability, linguistic, and physical aspects of your wireframes. Pick two heuristics from each of the three categories found at the bottom of the A5 page, and use them to generate a bulleted list of observations about how they apply to the interaction design implied by your wireframes. For example, what design decisions do your wireframes make that support the heuristics? Or, do your wireframes violate them in particular ways? In either case, do the heuristics suggest improvements you might make? Finally, what tradeoffs exist between optimizing for some of these heuristics (e.g., have you had to make some sacrifices to learnability to boost efficiency)? Make sure to clearly identify the heuristics you are responding to, and keep your observations grounded by ensuring that you cite a specific aspect of your wireframes with every observation.

    In total, you should aim to generate about half a page of observations.

  4. Design Iteration. As you work on the above tasks, you should simulate the execution in your mind, considering each step the user might take and how the app would react. You should also have in mind the social/ethical concerns that you considered in the last assignment, and how they might be impacted by the decisions you’re making. As you do this, you will encounter problems that you have to resolve and choices to make. Note down the issues as they arise, and make any necessary changes to your conceptual design or wireframes.

  5. Visual Design Study. Establish the “look and feel” of your app—what fonts and colors will you use, and what do they communicate about your app’s purpose? Look through a diverse range of visual media (including photographs, screenshots, magazines, newsprint, graphic novels, etc.) and assemble two slides of inspiration focusing on typography and color respectively. On each slide, collage together examples that you find particularly inspiring, and then use the margins to extract or annotate particular design choices you might be interested in exploring (e.g., specific color palettes and font families, or characteristics that you find interesting such as serifs, tall/short x-heights, etc.). Recall, we provided an example of a color study with A5.

  6. Plan your Implementation. Once this assignment is due, you will have roughly 3 calendar-weeks (12 person-weeks) to implement your app. An implementation milestone submission will be required each week (see the project overview timeline) similar to the milestones you experienced with the individual assignments:

    1. One week in, you will deploy an alpha release that includes an end-to-end (i.e., backend and frontend) implementation for two concepts in your app. For the alpha release, you do not need to worry about styling (i.e., your components may remain entirely unstyled or using default styles).

    2. Two weeks in, you will deploy a beta release where the central concepts and functionality of your app have been implemented, and a preliminary round of styling has been applied (rough edges are a-ok). At this stage, your app should sufficiently and usably address the problem statement you identified in P1, ready for user testing.

    3. In the final week, you will conduct some user tests to determine how well your app addresses user needs and identify flaws and opportunities for improvement. The rest of the week will be spent addressing any improvements that are feasible to do so in the remaining time, as well as polishing any rough edges.

    Given this timeline, develop a project plan that: (a) lists the specific order in which concepts will be implemented (your dependency diagram should help here); (b) breaks this ordering down into a set of manageable tasks; (c) assigns each task to a team member with a corresponding deadline. Every member of the team is expected to contribute equally to all parts of the final project (including design, implementation, and user testing).

    Your plan should also include a brief paragraph explaining what you will do if something goes wrong. Your description should include some substantive ideas for how you might adapt, pivot, or modify your scope. For instance, which tasks might you consider dropping, or what functionality might fall out of scope?

Submission

Posting and submitting. By the assignment deadline, post your work on each team member’s portfolio, and then submit this Google form once for the whole team.

Rubric

Component Excellent Satisfactory Poor
Functional Design Concepts are very well-designed, with clear OPs and non-obvious insights about the value they bring. Syncs include examples of synergy and, when possible, concepts suggest opportunities for reuse. Diagram includes all concepts and shows correct relationships. Concepts feature readily understandable OPs, with sufficient state to support them. But action definitions are not consistently clear, some necessary syncs are not included, and concepts are composed in a routine and typical way without examples of synergy or creative reuse. Some concepts refer to specific types when they could be made generic. Diagram includes all concepts and largely correct relationships, with an occasional incorrect edge or two. Concepts are poorly named, or have an unclear purpose or confusing OP. Insufficient state and/or actions. Syncs are similarly unclear or concepts interact by other means. Diagram misses some concepts or has several incorrect edges.
Wireframes Concept actions and visible state are presented clearly; executing operational principles is straightforward and intuitive; interface teaches the underlying concepts effectively. Concept actions and visible state are available in the interface; executing operational principles is possible but not always intuitive; concepts not inferable from interface without additional help Some actions or state that should be visible unavailable in interface; operational principle hard to execute; misleading image of concept projected.
Heuristic Evaluation Application of heuristics suggests refinements to the interface design that improves the user experience, and exposes tradeoffs. The observations largely focus on how wireframes adhere to heuristics. Only relatively minor improvements are identified. Tradeoffs are shallow. Heuristics did not expose many substantive opportunities to improve the interface design. Tradeoffs are missing.
Design Study The design study explores a diverse range of visual media. Typographic and color inspiration are well-extracted and communicated. The design study offers some nice inspiration, but could have drawn from a more diverse range of sources. Design study is missing or incomplete (e.g., only focuses on color or typography). Specific inspiration is not identified or is poorly communicated.
Project Plan - Project is well-planned with feasible milestones and fair division of labor. Contigencies are mapped out with alternative courses of action brainstormed. Project plan is missing or timeline has problems relating to feasibility and/or division of labor. Contingencies are missing or shallow.

Advice

  • Start early. As always, start early. This doesn’t mean you have to finish early. If you make an early start on thinking about your design, you’ll have it in mind over the week, and you’ll come up with novel ideas and insights 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.

  • Simplicity over Complexity. Recall from our lectures on design innovation and the design reviews that more is not always better! You can create novel and compelling user experiences by focusing on a small handful of key concepts.

  • Concept design resources. For concept design, see the tutorials. The most relevant ones are those on concept modularity; concept criteria; concept purposes; operational principles; concepts as state machines; concept state; concept composition and sync; and dependence diagrams and subsets. For inspiration, see the tutorials on great design and simplicity. For more general background on software concepts read this tutorial or this more expansive blog post. The recommended text has chapters about all these topics with many examples, and is available as a paperback book and as a free PDF from the MIT Library.

  • Concept independence. The requirement that concepts be independent of each other is very challenging, and you should expect to spend time figuring out how to achieve it. 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. We’ve written a tutorial that explains this in more detail. Remember also not to be guided by a common (but erroneous) assumption of object-oriented design that all the properties of an object should be in one module. On the contrary, properties of an object often belong in different concepts. For example, the username and password of a user would belong in a concept for user authentication, but a user’s bookmarks would belong in a different concept.

  • More on independence. A concept can reference the objects of another concept at runtime. For example, a Comment concept might contain comments with ids of target objects, which at runtime may be posts, images, etc. But the referencing concept should be independent of the details of the other concept, so while Comment can hold the id of a post, it should not, for example, refer to its author. Beware in particular of an OOP-influenced style in which a concept is like an object class that aggregates all the properties of an object, even when they should belong to different concepts. A concept that manages user authentication, for example, should not include in its state other user properties that are not relevant to authentication (such as a user’s favorites, location or friends).

  • Synchronizations. Remember to include in your synchronizations not only arguments that must be passed between concepts to keep their states in step, but also guards (such as authentication actions). Your syncs are a good barometer of how successful you have been in separating concerns and making concepts independent. Control flow (especially loops) and non-trivial data structure accesses are bad smells.

  • Dependency diagram smells. The structure of your dependency diagram may reveal some important properties of your design. If you have lots of short, disconnected branches with few connections, you app might be a “hub” that aggregates a variety of apps rather than being a coherent app in itself. And, on the other side, long chains of dependencies can be troubling too, because failing to implement one concept can make many other concepts unusable.

  • Wireframing resources. For wireframing, Figma’s tutorials provide helpful background beyond the recitation notes.