Assignment 1 - Product Design
|Issue date||Monday, 19 August 2019|
|Final submission||Sunday, 1 September 2019, 23:59|
In this assignment, you will put on your designer hat and learn how to design a software product, coming up with ideas, features and designs. You will be guided on the various phases in designing your (possibly first) tech product.
Grading and Admin
This assignment can be done in groups of three or four students. If you are unable to find yourself a group, you will be randomly assigned to one.
This assignment is highly open-ended. We provide milestones so that we can grade your application in a consistent way, even though everyone would be building different apps. This assignment is also designed to introduce you to the various phases of app design and the milestones are there to ensure that you learn about the elements in a structured way. We will also provide some related tips, references and a little bit of help to get you started. These milestones constitute 70% of the assignment’s grade.
While the milestones may be easy to meet, simply meeting them will not give you full credit. We ask for quality submissions, not run-of-the-mill work.
To score the coveted remaining 30%, use your creativity to design an application that separates yours from the rest. We will not restrict your potential by restricting the kind of application you can build. We expect that you (pleasantly!) surprise us with what you are capable of doing.
Please do not hesitate to approach the friendly CS3216 staff if you need further assistance. We can be contacted at email@example.com.
The objective of this assignment is to ideate and design an app that solves a real problem, and use empirical user testing to validate your idea and design. Your team will pick and target an audience to solve their problems. You will need to think critically about the features and user interactions within the product, and how each of these supports the user in solving the problem. This is followed by interviewing them to iterate on improving the design and user interactions. The final product will be a document that is sufficiently detailed to be handed off to a developer to be turned into the final working app.
For this assignment, you will be designing and building a mockup of your app’s user flow. There are a large number of available UX design tools in the industry.
We recommend using Adobe XD, a powerful design tool that is able to convert the designs into interactive mockups too! The interactive mockups are automatically published onto an online link and can be run on mobile devices like the real thing as well. Adobe themselves provide lots of free XD resources and design templates that follow the latest design trends:
Apart from Adobe XD, here are some other tools you can choose from:
- InVision: We have secured a free education edition for your use. See Coursemology for more information on how to obtain an account.
- Sketch: an industry standard but is not free and available only on macOS.
- Paper and pencil for wireframe sketches.
Whatever tool you choose, it has to be able to produce a mockup that fulfills all the assignment requirements. In particular, the mockup should be able to demonstrate user flow through the app.
A note about terminology
Throughout this assignment, we will refer to user flows. In traditional user interface (UI) / user experience (UX) circles, these refer to flow chart diagrams that represent each screen as shapes. However, modern design tools make it easy to build high fidelity mockups, and we will instead refer to what NN Group calls wireflows as user flow mockups.
Phase 1 - User Requirements Gathering
Every good app / platform / website / service begins with a problem they are looking to solve for a target user. As this assignment is due on 1 Sep 2019, we recommend you pick a target user who is abundantly available around you, e.g. your fellow NUS students. This way you can easily conduct your user testing.
Study your users. Think of a problem/pain point you think they are facing now. List down the problem/pain point and assumptions you have about:
- Why are they facing this problem
- How are they living / dealing with this problem now
- How can your product / service solve this problem
- What platform (desktop / mobile / app) will best serve to solve this problem?
- Will your product / service solve this problem in a way that does not cause them more stress, effort and time?
List the above in a user persona card. A persona is a fictional representation of an ideal user of your product. You can have more than user persona card if that helps! There is no fixed format for this, but it should contain at the very least:
- A stick man or portrait (use stock photo)
- Fictitious name for your user persona
- Age, gender, current occupation
- Answers to the problem / pain point and questions above
You can fill in more information if you feel it can help you visualize your product, such as personality, brand affiliation, life goals and aspirations, level of experience with technology and more. The goal of the user persona is to allow you to think in the shoes of your user, so try to include details that make this easy.
Once you have listed these down, it is time to proceed to user interviews. The goal of this round of interview is to validate your problem and assumptions about your users. While this may seem premature, it is important to remember that the earlier you reject a bad idea, the less costly it is.
- Identify users that fit your user persona cards
- Interview them about the problem(s) you think you are trying to solve
- Validate your assumptions
- Avoid asking leading questions
Phase 2 - Prototyping
After your interviews, list down at most three primary user goals your product should achieve. As a team, brainstorm features that would lead users to achieve these three primary user goals.
The features you pick should answer why they are necessary and how they reinforce your business idea. You should focus on quality and the impact each feature will bring. Products are not successful just because of the number of features they have.
In general, remember that you are building a Minimum Viable Product (MVP) 1. The goal is not to build a complete feature set of the product, instead, the number of features should be just enough to test out your idea and validate that it is worth executing on.
A good example is Instagram, which if you follow their product timeline, they hit 100k users in a week without things like hashtags and explore.
At the same time, you should not miss out on the essentials such as authentication and settings, or the lack thereof. A large part of WhatsApp’s popularity was due to simply having the phone number as the user account and their focus on the core essentials of messaging!
As you are designing a product for the real world, it is also important to ensure that your ideas and business logic are sound, realistic, and executable. Answer these questions:
- How will your product acquire users? Why will users use your product over what they are currently doing to solve the problem?
- How will your product be executed?
Digression: Good Artists Copy; Great Artists Steal
You should do some research before starting to work on the mockups. Professional designers do that all the time. Here are some articles and references to learn more about user interaction design:
You might also find pattern libraries useful. A pattern library is a collection of user interface design elements, such as a login page, a news feed, a profile page, a credit card entry screen, etc. They are recurring solutions that solve common design problems.
- Mobbin - A website created by fellow School of Computing student Lim Ji Ho that showcases the various screens found within popular mobile apps.
- pttrns - Another mobile app UI pattern library with the addition of Apple Watch apps.
- Material Design Tools - Customize and download Material Design icons and theme assets
- Apple Design Resources - Assets and tools for designing for Apple devices
Now it is time to get your hands dirty!
Use any tool you want - even Powerpoint if that’s easier - or just plain paper, markers, and pencil. At this point we value speed over quality since you will likely need to change them based on user feedback, so use whichever tool that allows you to sketch the user flow the fastest.
Wireframes are “low-fidelity” mockups. This means that they should not contain any design specific elements such as colors, font or unnecessary details like user-generated content and images. These distract from the aspects in which the testing is focused on, and slow down the speed which they are produced. Instead, focus on relative size and position of elements, key user interface elements, and interactions such as which elements can be clicked or tapped, dragged, and so on.
Whichever tool you use to sketch your design, make sure you can “transition” from different screens and states easily. If you are designing on Powerpoint, this means making each screen or state a slide, and if you are designing on paper, use a different page for each screen, and sticky notes for modals, popups and other ephemeral UI elements. Tools like InVision allow for interactive user flows which you may use for user testing, but may take longer to build and are not required until milestone 7.
Remember that these mockups will be shown to the user during testing. Do not draw out the links between buttons and screens or let the user see more than one screen at once - after all, users can’t do that in the actual app! (You may use these annotations or comments for your own reference, but remember to hide them before starting user testing.)
Sketch out the user flows for each of the major features you have listed above. You may have more than one flow for each feature, and the flow can even start from outside your app. When you create your design, keep your user personas in mind.
These are some examples of user flows you may want to sketch out. In some cases you may also have an explicit hypothesis you may wish to test.
- When the user hears about your app from a friend and visits your website or the app store page.
- What should you write on that website to entice users to click the “Sign Up” or “Download App” button.
- When users click Sign Up, what do they see next? What details do they have to fill in? Are you making users go through too many steps before even signing up?
- When users login or use the app for the first time, what do they see? What can they click on?
- When users login or use the app for the second time, what do they see? What can they click on?
User flows should naturally intersect with each other. This is fine - real apps do not artificially limit the user in which buttons they can press.
Phase 3 - User Interviews + Iterations
Now it’s time to put your draft design to the test! The test we are conducting is sometimes called “Wizard of Oz” - we will simulate user interactions by taking the place of the computer. This may seem silly at first, but it is an important tool to validate your design at this stage. Here is a video which shows an example of this form of testing using paper prototypes.
Playing the Wizard of Oz
You may find it easier go out in pairs to conduct this form of testing. One of you need to act as the computer, so you need a second person to record your results. Test with only one user at a time, not a group. This is to avoid one user’s actions and opinions from influencing the results of other users.
Ask them for five to ten minutes of their time, and if they agree, start by giving them a little context for what you are about to show them. For instance, if the app in question is NUSMods, you might tell them that they have just received a link from a friend telling them to check out a new app for organizing their NUS timetable. You may also give them an explicit goal to accomplish, such as “you would like to sign up for an account”.
Instruct them to think aloud and use their finger to point at where they will click or tap. A quick way to explain “Think Aloud” to your users is “Vocalize your thoughts. Let us know what you’re thinking throughout the way”. Explain that you will be acting the part of the computer, and reassure them that there is no wrong answer. Do also tell the user to notify you if they are done using the app/website or don’t have anything else to do. This will make it clear to you when the user has totally lost interest, given up on your UI, or have no more use for your website/app.
Now open the first screen they’re supposed to see. Observe what they click on first, second, third, etc. Remember to “transition” your mockup as they interact with it. Do not say anything during the whole process. If users become lost or confused, let them be lost or confused. Only prompt them for what they are thinking if it appears that they are not thinking aloud. If they get stuck, simply move onto the next set of mockups.
For any buttons or screens that you have not mocked up, you can reuse any existing mockups and tell the users what they should see - “You clicked the School of Computing link. We don’t have those screens today. So please pretend that you see results for the School of Computing on this screen. Okay?”. Alternatively, you can describe the result of the action to the user in words instead - “You see a pop up open with a yellow warning triangle, the text ‘This will delete your results. Proceed?’, and the buttons ‘Okay’ and ‘Cancel’”.
Remain as neutral as possible during testing. Only ask follow-up questions after the user testing session is completely over. This would be your chance to ask:
- Did you notice button X on this screen?
- Why did you click here and not there? What did you expect to happen when you clicked here?
- You seemed lost on this page. Why were you lost? What did you expect to happen?
Rinse and repeat with three to five 2 different users.
After you have completed the interviews, it is now time to review the results and improve your user flow. For example, you may want to ask yourself:
- What did the user click on first? Was that what you wanted the user to click on first?
- Which features did users totally miss? Does that mean those features are not important? If they’re not important, throw them away. If they are, how can you revise your design so users notice the features and actually click on it?
- Are there too many steps for the user to accomplish their goal? At which point did the user become visibly frustrated?
- What assumptions did you make when you create this design? Did the user testing confirm or reject these assumptions?
As you iterate your design, remember to refine your sketches and improve their quality. Be bold in your earlier iterations. It is perfectly normal to throw out entire screens at this early stage. With each iteration you should solidify your design - while earlier iterations may require large redesign, later iterations should only produce minor tweaks.
Phase 4 - Design Mockups + More Iterations
Now that you have the basic information architecture and user interactions planned out, it is time to add meat to your wireframe. Convert your wireframe into a high fidelity prototype using your chosen prototyping tool.
Compared to a low fidelity prototype, a high fidelity prototype will usually look similar to how the final app will turn out. Colors, fonts, logos, images and user interface elements from the target platform are used in place of wire boxes. Testing with a high fidelity prototype should be the next best thing from testing with a working prototype. This allows for stronger suspension of disbelief, allowing the user to act more realistically.
You may find it useful to develop a set of shared assets such as the app’s logo, color scheme, font and common UI widget so your mockup looks coherent when are built by different members of the team.
Since a high fidelity mockup tries to emulate the final product as much as possible, you should try to make the prototype itself interactive too. Your chosen prototyping tool should allow the user to directly click on elements, which should transition the prototype to the next screen or state. This also frees you from acting as the computer, which gives you more time to observe the user instead.
A well-developed app has many moving components - log in, sign up, active, inactive states and so on. While you do not have to include every single possibility that your user will encounter, it should be sufficient for your users to test it satisfactorily.
More testing! More iterations!
Similar to milestone 6, you must now test your high fidelity prototype with real users. At this stage, your prototype should be more complete, so there should be less shuffling around paper or clicking through slides. You can still step in for the computer for any screens or states which you have not added to the prototype, or for interactions like drag and drop which are less easy to prototype, but there should be less intervention on your part.
As you should already be fairly confident in your information structure and basic user interaction, you can instead focus on design details, usability and user experience. For instance, you may wish to check if the chosen color and design of your primary call to action button is sufficiently differentiated and noticeable. In addition, because you are using “production” colors, fonts and UI elements, you can test for a wider range of issues, such as legibility, affordance3 and engagement.
However, remember that the primary goal of the testing is still to observe the user interact with the app. If you need to ask specific questions about elements of the design which the user did not comment on during testing, you should only do so at the end of the test.
Final Mockups & Assignment Write-up
With the previous draft’s user testing results, you should come to a good conclusion on what your MVP should act and look like. The final mock ups should be complete and sufficiently detailed to be handed off to a developer to realize them. Include mockups of the onboarding, first use, and (if applicable) login flows.
Your final mock ups should be accompanied by a write-up that describes how your group has met all the milestones for this assignment, summarized all the results and observations from your user testing results and make it easy for the teaching staff to understand how the submitted mock ups are organized.
Also, we want you to take note that the different milestones in Assignment 1 has been structured for you to gain a good sense of what it takes to produce a Product Requirements Document (PRD), a document used in companies (Facebook, Amazon, Google, many other tech companies…) to describe the product being built. The PRD is usually produced and has to be approved before further product development can take place. Once produced, it drives the efforts of the entire product team and the company’s sales, marketing and customer support efforts.
The broad structure of the PRD is as such:
- Product Purpose (Milestones 1-3)
- Description of the problem that you are trying to solve
- High level description of what the product does and how it solves the problem
- Who is the product for
- Competitive Analysis (Not included in Assignment 1)
- Identify competitors who are launching similar products
- Identify features of competitor’s products worth emulating or avoiding
- Identify the ways in which our product’s features can deliver greater value than the competition
- Features (Milestones 4-8)
- Describe each feature at the level of interaction designs and use cases
- Requirement traceability - identifying which requirements are in support of which objective
- Metrics to be measured (Not covered in Assignment 1)
- Schedule for Product Development (Not covered in Assignment 1)
- Key milestones and overall timeline for product development
In particular, most of the PRD’s importance is in the articulation of the product purpose (Milestones 1-3) and the features built to serve its purpose (Milestones 4-8). This is also what we are focusing on in this assignment. Hence, besides being mindful of how and why Assignment 1 is structured in this manner, you should also illustrate (to the best of your ability) how each feature addresses a particular aspect of a problem that your target user faces - what is known as requirements traceability - to demonstrate that your feature was developed and iterated with thought for the problem faced by the target user and not simply because it’s cool or funky.
For further reading regarding PRDs during your free time, feel free to check out this link.
Phase 5 - Growth Hacking
Growth hacking is defined as the process of rapid experimentation across a marketing funnel, product development, sales segments, and other areas of the business to identify the most efficient ways to grow a business. A common misconception about the term is that it has to do with coding.
A wonderful application is useless if there are no users using it! In this section we will discuss some ways to get users.
When should you launch a website for your app? If your answer is to launch only after the app has been released, you are missing out! Just like movies trailers, which are released months before the actual launch of the movie, you can launch a landing page, which is a website designed to gauge interest and convert visitors into leads/users.
A landing page should:
Explain what your app is about and aims to generate interest in it.
Contain a form that allows you to record a visitor’s information. Businesses often promise some sort of deal/promo for the first X users who sign up.
Great examples of attractive landing pages can be found at:
- 19 of the Best Landing Page Design Examples You Need to See in 2018
- 12 Great Landing Page Examples You’ll Want to Copy
Use a CSS framework like Bulma or Bootstrap to save yourself some time. Remember that the design has to be attractive and that your message has to be succinct! You can even consider landing page creators like MailChimp landing pages to skip all the work.
A landing page cannot effectively convert visitors into leads/users if there are no visitors to begin with! Going back to the movie trailers example, it would be like creating a movie trailer, but not showing it through public display screens and television advertisements. Hence, you should think of some potential marketing strategies to get the word out about your app.
- Make promotional videos. View past CS3216 final project videos here.
- Griddit, a live chatroom app, got Prof Ben Leong to do an AMA using their service.
- Letterbox had a member going around the school on an Airwheel and giving out flyers.
- Paste unremovable stickers on the benches of School of Computing.
- Put up posters in inappropriate places like restrooms.
Videos are not the only way to market an app - to obtain marks in the coveted 30%, think out of the box for non-disruptive, creative and effective marketing strategies. We want a well thought-out marketing plan including details on how you would implement it. Your strategy must obviously be realistic, i.e. do not suggest giving out $10 to each user who downloads your app if you do not have a good plan of getting those funds or a millionaire on your team.
In view that this is a brand new assignment, the detailed grading scheme is still being worked out by the teaching staff. We ask for your kind understanding. It is possible that the scheme would evolve as we grade, but not to worry, this assignment is only worth 10% of the final grade and the goal is learn the Product Design process, so don’t fret over the grading.
Also, students who dutifully follow all the instructions above and hit all required milestones will obtain 70% of the grade. The remaining 30% will be awarded based on the relative outcomes for the various teams. The top team might be awarded up to 30% while the worst performing team less than 5%.
Mode of submission
By 1 Sep 2019 23:59 hrs you should upload the following to Coursemology:
- Your write up named
group-<number>-milestones.pdfcontaining the answers to milestones 1-4 and 10-11.
- Your mockups and testing results - zipped together - named
Clarifications and questions related to this assignment should be posted to the CS3216 Slack channel #ay1920-assg1.
Good luck and have fun!
Affordances are an object’s properties that show the possible actions users can take with it, thereby suggesting how they may interact with that object. ↩