Minimal Viable Product (MVP)

Think of the MVP milestone as the “beta release” of your final project: it does not need to be polished, but it should realize the bulk (~80%) of the intended narrative and visualization functionality of your final project. In-class, you will present your MVPs to gather feedback as you make the final push towards the end of the semester.

Due: Monday, 4/29, 9:30am ET (critiques due Friday, 5/3, 11:59pm ET)
Submit Presentations on the Google Sheet →
Submit Critiques via Google Form →
In-Class Presentations on Mon, 4/29 and Wed, 5/1.

Table of contents

For the MVP milestone, all the major components of your final project should have a working prototype implementation. This implementation can have many rough edges (and even bugs!), but there should be sufficient styling and working functionality. This also means that any narrative elements should be largely in place (i.e., no Lorem Ipsum or other dummy text).

Your MVP should be in a sufficiently developed state that we are able to judge how your final project will ultimately function (including what the takeaway message(s) or insight(s) will be for your intended audience). To facilitate staff and peer feedback, your MVP should also be deployed to a publicly accessible URL.

The remainder of this milestone will involve an in-class presentation of your work followed by peer design critiques due 11:59pm on Fri, May 3.

In-Class Presentations

We will use lecture time on Mon, Apr 29 and Wed, May 1 to present and critique each other’s MVP milestones. Presentation order will be roughly reversed from FP2 (i.e., if you presented your wireframes first on Monday, you will likely present your MVPs last on Wednesday).

Like FP2, your presentation should last approximately 5 minutes. You might consider pre-recording a video to keep to the time limit and ensure a high-quality presentation, but you are also welcome to present live. Your presentation should roughly cover the following content:

  1. On your title slide, include the names of all members of the team, and and crisply state the question you are addressing, who your intended audience is, and what the purpose or goal of your final project is.

  2. (~1 min) A brief reminder of the key takeaway message(s) for your intended audience.

  3. (~3 mins) A demonstration of your working MVP implementation from the perspective of your intended audience (i.e., walk us through your MVP as though you are the intended reader).

  4. (~1 min) A discussion of some key data analysis results or design decisions that have driven your MVP work. For instance, why did you pick these particular visual encodings, or storytelling/interaction/animation techniques to convey the data? What alternative ideas did you explore, or are you considering? Etc.

  5. A final slide that provides a short list of questions you would like your peers to comment on, either during post-presentation Q&A or as part of their critique. Do not spend time explaining/narrating this slide; rather, simply leave it up to spur discussion. This final slide should also include a URL to your working MVP so that your critics can explore your work after class.

Peer Critique

As part of this milestone, each team will be responsible for giving feedback to three other teams. This feedback should be based not only on the in-class presentation, but you should also spend some serious time testing out the MVP implementations concretely.

Critiques should be about 2–3 paragraphs, and we encourage you to follow an “I like… I wish… What if…” structure. Open your critique with aspects you liked about the final project work thus far and why you liked them. Next, what are opportunities you noticed to improve the project heading into the final deliverables? Think not only about minor tweaks (e.g., color, layout, etc.) but larger-scale changes as well (e.g., different visual or storytelling forms). Finally, do you have any ideas that might not be directly connected to the MVP, but could push the team in new directions? Throughout your critique, be as concrete as possible—high-level feedback can often be less helpful than we realize because it can be difficult to interpret or know what to do with. By being specific, you give the team feedback they can immediately begin working with.

Here are some prompts to guide your critique (note, you do not need to cover all of them nor are you restricted to critiquing only these aspects of their MVPs; we provide them here only to spur your design thinking):

  • Visual Encodings: Are expressive and effective visual encodings applied? How well do they reveal the most important features or trends of the underlying data? Is critical data easily seen, or is it unnecessarily “hidden” and only revealed in response to interaction? Is the target audience likely to understand the visualization?

  • Narrative Design (i.e., Storytelling, Interaction & Animation): Are the takeaway message(s) for the intended audience clear and crisp? Do the supported interaction and/or animation techniques enable more effective discovery of interesting trends, patterns or outliers? Do they engage the viewer in a process of meaningful exploration or learning? Are they well-implemented, without notable performance issues or usability problems?

  • Design Quality: Assess the overall design quality in terms of organization and presentation. Are elements appropriately titled or labeled? Is there appropriate spacing, layout, legible type, and other forms of design styling? Is it clear where to begin viewing/interacting with the design? Is the overall display confusing or cluttered? How successful is the prototype in meeting the intended goals?

Submit the critique for each team using this Google Form. Critiques are due by 11:59pm on Fri, May 3, and will be graded for how thoughtfully you’ve engaged with the team’s project, and how constructive and actionable your feedback is.

Grading

This milestone is worth 10 points, even split between the quality of your MVP (2 points), your in-class presentation (2 points), and your three peer critiques (3 x 2 points).

Each component will be graded on a check-minus / check / check-plus scale. That means that if any component is of particularly high quality (e.g., an MVP implementation that demonstrates impressive functionality or polished narrative; a creative and/or engaging in-class presentation; or, a critique that deeply engages with a team’s MVP and offers thoughtful and actionable feedback), it may be awarded 3 points.

Check-minuses (or scores of 0 points, for particularly problematic submissions) will be awarded for any of the following issues:

  • Significant missing or incomplete portions of the envisioned final project. As a beta release, we do not expect your work to be polished, but we do expect that you have made substantial progress implementing all the central/key aspects of your final project. The more you have implemented, the more we (and your peers, via their critiques) can help you improve your work ahead of the final deliverables.

  • Severe bugs that cause your MVP to largely fail to display, or for major components to not work correctly whatsoever.

  • The developed visualizations—and particularly the takeaway message(s) or insight(s) for the intended audience—is particularly unclear or ungrounded in the data.

  • In-class presentation was substantially over time, or difficult to understand.

  • Peer feedback is high-level or relatively shallow, and doesn’t provide the team much concrete, actionable feedback to improve their work.