Design proposal

This section describes a project milestone. See the schedule for due dates.

Your design proposal builds on your Project Proposal.

Where the Project Proposal was about understanding users and their problems, the Design Proposal is about brainstorming possible solutions and generating prototypes for feedback. This document reflects the Explore Phase of the Design Thinking process.

What to include

This document should be a Wiki page in your project named Design Proposal. Make sure to link this page to the README.md file so that users can easily find it.

You should include the following sections.

1. Ideate

This section should include the following:

  1. A list of ideas to address the problem statement. You will not likely have “one solution for everything” but instead will have a bunch of ideas for each use case. Your solution will be some combination of these.

    Tip: Put down everything; a bullet list is fine. This should be more ideas than you include in your solution e.g., you may initially have 10-20 broad ideas, that you will distill to a smaller number in your solution below.

  2. A proposed solution. Which combination of ideas from above do you want to pursue? Which ideas together reflect the best solution to your problem statement (from the Project Proposal)?

    Tip: Write a paragraph explaining why you think this combination of ideas is most suitable. You can consider technical reasons, logistical challenges, even design problems like how features will work together.

    This does NOT need to be an exhaustive design document! It’s enough to have a paragraph or two explaining your thinking, and a bullet list of 5-10 sentences describing features that you expect to implement. You want enough detail to know what to prototype, but no more than that.

2. Prototype

Finally, you want to generate low-fidelity prototypes that reflect your solution.

You should have:

  1. Mockups of every screen that you anticipate needing. Generally you will have one or more screen to address each user story. These should be low-fidelity or wireframe diagrams i.e., screens showing a sketch of the screen contents, with labels if necessary to make the sketch clear.

  2. Some indication of progression through the application. Explain to us how the user progresses though the application (e.g., “clicking on the Create account button on this screen moves to the Create dialog”). Drawing arrows between screens is fine, as long as you label them to make it clear how and when transitions occur.

    Tip: It’s highly recommended to create prototypes in Figma, or some other online wireframe tool. Make sure to include these diagrams in your actual design document i.e., as screenshots or images. You cannot just provide links to Figma!

Where to store this document

Your proposal should be contained in a Wiki page titled Design Proposal, and linked from the README.md file of your GitLab project.

How to submit

When complete, submit for grading.

Caution

Note that only one person on the team needs to submit team deliverables. The submission will be associated with your team, not the person that submitted it.

Login to Learn, navigate to the Submit > Dropbox > Design Proposal page, and submit a link to your top-level project page.

Proposals must be submitted by listed time and date.