Coursework 1: Design a smart refrigerator app

Acme Co. is developing a new smart refrigerator and has asked you to design an app to go with it. Acme's new refrigerator will come equipped with all the latest technology. It has the ability to identify any object put inside it, including fruits and vegetables. It can also track the weights of the items and how often they have been taken out of the fridge.

Acme wants you to create an design prototype of a smart fridge companion app that supports three tasks. For the purposes of this project, you can assume that these are the only three tasks a user will ever attempt to accomplish using your app. Two of the tasks have been provided by Acme, and you must identify one task yourself.


Acme's marketing department has done some initial research and identified the following two scenarios as tasks they would like the app to support. They would also like for you to identify a third task that users are likely to engage in. Your app should support all three tasks.

For all three tasks you need to finish/create a design fiction. That is, you need to write a short fictitious story about someone who wants to accomplish the task and how your app helped them to do so. The point of a design fiction is to help the reader understand your vision of how the app will be used under ideal circumstances. Please refer to the lecture slides for examples of what completed design fictions look like.

  1. "Is there anything I need to buy more of?"

    Technical assumptions: The Acme refrigerator is able to list out all the current contents of the fridge as well as past contents. It can identify the EAN code of any item in the fridge (see assumptions) and the shelf that item is currently on.

    Design fiction: Alice is on her way home and stops at a grocery store to buy food for dinner. While there she wonders if she needs to buy anything else that she normally keeps in the refrigerator. To find out, she opens her refrigerator app and....

  2. Read and change the current temperature in different parts of the refrigerator.

    Technical assumptions: The Acme refrigerator comes with the ability to change the temperature on individual shelves and drawers but as much as 2oC from the main refrigerator temperature.

    Design fiction: Bob likes avocados and wants to keep them fresh in his refrigerator for as long as possible, he checks online and learns that the ideal temperature for avocados is 3-7oC. His flat mate is very nervous about keeping the fridge so warm since he stores meat in the fridge and ideal storage temperature for most meats is 1.1oC. Thankfully the Acme fridge comes with the ability to set temperatures in different parts of the fridge. To resolve the problem Bob opens the Acme refrigerator app and....

  3. Fill in your task here
    You need to identify a third task that your app will support.

    Technical assumptions: Fill in any technical assumptions you are making about how the fridge works, or any non-obvious technical assumptions about how the app works. The text here should be similar to the text in the above examples. For example, if the app is getting data from a recipe website you should say something like: "The app connects to using an API allowing it to access the customer's allrecipes account and read out recipe ingredient lists. We assume that the user has already linked their allrecipes acount to our app before the start of the task."

    Design fiction: You need to provide a design fiction describing how your task is supported by your app.

  4. Fill in your task here (Groups of 3 only)
    If you have a group of size 3 then you also need to identify a fourth task that your app will support.

Simplifying assumptions

For this coursework you can assume the following:

Potential abilities of the Acme fridge

The Acme engineers haven't quite finished designing the refrigerator, so they are happy to take some of your suggestions about the kinds of information the fridge needs to provide to the app. The following is a list of the types of sensors the engineers are considering putting into the fridge. Your app may use as many or as few of them as you think appropriate for your tasks.

Potential abilities of the app

You may assume that your app will run on a reasonably modern smartphone and has all the Internet and processing power typically associated with such a device. If you could write a small program to do something, then your app should be able to support the functionality. The fridge mostly handles temperature and tracking of items. Essentially it is a big sensor that can change temperature. Anything else you should assume as being done by your app.

You may also make use of the various APIs, services, and data sets that exist on the Internet. The most obvious example would be that your app has access to an EAN lookup table or service which lets it lookup basic facts about each of the products such as its name, weight, brand, etc. You do not need to build any of this infrastructure, just justify that the app you are desiging could theoretically be built.

You can assume your app has access to the following types of data. You do not need to explicitly list any of the following in your technical description.


You will be working in groups of size 2 or size 3. Groups of size 3 will be expected to support an additional task with their prototype (see details above), but will be otherwise identical to groups of size 2.

To declare what group you are in you should submit a text file with the University Student ID numbers of all group members (including your own) with one ID per line. Please use the submit command to do this. If you need to change your group membership you may use the submit command again.

submit hci cw1 group.txt

For those uncertain what "submit" is:. You need to log into a DICE computer and create a text file called "group.txt" which has all the university IDs of the group in it, one per line. Then open a terminal and type in the command above. Doing so will submit the coursework.

If you are still looking for a group please use the provided Piazza discussion forum. The lecturer will also try and help people looking for groups to meet up after class.


To build your prototypes you will be using a combination of mock-up programs, drawing programs, and potentially Processing. Your final submission will be either a Processing sketch or a Figma mockup.

We anticipate that most teams will start using pen-and-paper to create some initial sketches of the app screens. They would then move to the online mock-up tools to create more professional looking interfaces for each of the screens. Drawing tools like Inkscape or Powerpoint might be used to draw specific parts of the interface. Once the interfaces are near completion the team would then turn to Processing or Figma to make them interactive. For Processing, this would likely be done by importing the images into Processing and using the code to dictate what will happen when each part of the screen is interacted with. Additional small UI features might be added at this point, for example having a text box where the user can actually enter text and have it appear on the interface.

Mock-up resources

Feel free to use any, all, some, or none of the following:

Processing resources

We have provided an Example Processing Sketch which shows a couple of screens and buttons that let you move between the screens. Two of the screens are downloaded from and one is a random photograph. You are welcome to use this sketch if you find it helpful. You are also welcome to completely ignore it if it is confusing you.


To evaluate your design the markers will follow the below procedure:

  1. Unzip your sketch, open it in Processing and hit play.
    Open your Figma link and click the play button.
  2. For each task:
    1. Read the task and design fiction
    2. With the design fiction in mind, they will attempt to complete the task using your prototype using a Cognitive Walkthrough protocol. That means that for each screen they will determine if that part of the interaction follows standard design principles and supports the user in accomplishing the task.

You can read the full marking guidelines for more details.

We will not be marking your code on this coursework, only the resulting interaction it creates. Prototypes are by definition not well coded and Processing is quite terrible in terms of efficiency. If you spend a long time trying to optimize your code, then you are wasting your time. If it works, then it is good enough.

Your team must be the primary author of your code and designs in accordance with the normal University policy on academic honestly.

Turn In (Processing):

Deadline: 16th of October by 4pm.

You need to turn in:

Zip the sketch
On the Processing window go to: Tools -> Archive Sketch and save the sketch zip file somewhere you can find it.

To submit the documents electronically use the submit command (prefered). If you don't know what the "submit" command is, ignore the next part and submit using the assignment submission feature on Learn. If we have submissions for you in both submit and Learn, the submit one will be used.

submit hci cw1 report.pdf
submit hci cw1

Turn In (Figma):

Deadline: 16th of October by 4pm.

You need to turn in:


On the main screen for your project go to the top right corner and click the blue "Share" button. On the pop-up click the "Copy shareable link to this file" then paste the link into your report.


On the main screen for your project go to the right column and click "Export [project name]". Then export the large screenshot which contains all of your screens. If you don't want to share this one for some reason, then you need to export all the individual screenshots. Figma will give you a zip file, turn in this zip file.

To submit the documents electronically use the submit command (prefered). If you don't know what the "submit command" is, ignore the next part and submit using the assignment submission feature on Learn. If we have submissions for you in both submit and Learn, the submit one will be used.

submit hci cw1 report.pdf
submit hci cw1

Frequently Asked Questions

Informatics Forum, 10 Crichton Street, Edinburgh, EH8 9AB, Scotland, UK
Tel: +44 131 651 5661, Fax: +44 131 651 1426, E-mail:
Please contact our webadmin with any comments or corrections. Logging and Cookies
Unless explicitly stated otherwise, all material is copyright © The University of Edinburgh