DinPlan

The Task

In this assignment, I had to create a prototype in the form of a mobile application that supports activities within ones own home, for example housework, maintenance work, purchase of goods, etc.

I also had to create an advertisement video for the prototype that will attract the curiosity of future customers.

Results

I created a prototype for the application DinPlan. DinPlan is an application that mainly would combine three already known technologies. It would combine the technology OCR, optical character recognition, with two other functions. OCR is technology that reads images of physically written text and converts it into machine coded text. The two other concepts consist of a function that can produce recipes by allowing you to fill in what you have at home and a function that can create future meal plans. What is original about this app is that the combination of these three concepts creates something new. DinPlan allows you to scan your physical receipts using OCR, in other words you don’t have to fill in everything manually, and creates a database for your collected goods. DinPlan then uses the database to create a meal plan for you as long as your supplies last, so you don’t have to think of what to cook every day.

Here is the commercial I produced of the application.

If you would like to test out the application yourself you can try it here: https://invis.io/NRXIR4W4PWD#/419896245_DinPlan_Logga_In

Designprocess

I began the work process by conducting an ethnographic study in the form of an interview with my “stakeholders” (in reality it was voluntary people, but for this fictitious scenario I call them my stakeholders) in a collective group. The interview was relaxed and open to discussion without prepared questions. The interview was about what ideas and applications could facilitate the work with household chores or homework for them. I asked them, among other things, what they thought was difficult when it came to specific activities within homework. They came up with many good suggestions and I wrote them all down to then develop them further and sketch them. The reason why I chose to interview my stakeholders at the beginning of the entire design process was because I wanted to make sure that I was actually designing something that they might be interested in. Worth mentioning is that for this work I used the same four stakeholders throughout the process. The age range of the stakeholders varied between 24–54 years.


After working with the ideas and sketching them, I finally chose an idea that I myself could identify with and became interested in.

The problem my application was supposed to alleviate is figuring out what to cook, starting to cook, knowing what kind of goods you have at home and prevent the probability of realizing that a couple of ingredients are missing.

After I had my idea sketched down I began working on creating a prototype.

After the first prototype was completed, it was time to begin the next phase of the design process. It was time to test the prototype and let both me and my stakeholders look a little deeper at what I created from their idea.

The process began with me carrying out a so-called “Participant Observation” where I myself inserted myself into the everyday life of my stakeholders. I asked my stakeholders to show me what their everyday life around cooking looked like. I participated in the cooking, in conversations about them and everything that had to do with my current problem. I also had the opportunity to perform this method several times because cooking usually happened about three times a day for my stakeholders. While I participated in the active observation, I simultaneously took notes and noted interesting details that could be relevant to my further design development.

After conducting several observations, in which I participated and got to know my stakeholders more, I gathered my stakeholders to perform a method called “Bodystorming”. I wanted us all to participate in it together to break the ice, but also to spark the thoughts and opinions of my stakeholders from interacting with each other. This would be useful in my next step. The bodystorming consisted of acting out scenarios with the developed prototype and using it actively and criticizing it during the process. I also actively participated in the bodystorming, but kept a slightly more passive role to record what my stakeholders said and not to risk taking over too much. However, I still participated and made sure that the method and process was rolling and not stalling.

After we performed the bodystorming method, I asked my stakeholders to sit down to perform the next method called “The Love Letter & the Breakup Letter”. Here my stakeholders had to write letters and express their feelings about the prototype. I also participated in this process because I had been involved in the two previous processes and had developed some new opinions about it. The stakeholders wrote down their feelings about the prototype on paper, some wrote less while others wrote long detailed letters, which I then collected. This felt like a nice end to the whole process where the stakeholders had to take their time to think through their feelings and then write them down in a letter directly addressed to the prototype. It was also useful for me as I could draw from both my collected notes and the written letters to think about what needed to be developed in the prototype.

After testing my prototype, I took the time to go through the prototype again and make some adjustments like adding extra buttons and additional pages to the prototype. Among other things, I added a page where stakeholders have the option to add products manually in case they ever forgot to receive the receipt, or if they bought goods before they even downloaded the app that they want to add to their database.

After making some adjustments and further developing the prototype, I let my stakeholders test the prototype one last time. This time I did not participate in the process, but carried out an ethnographic study in the form of an observation of my stakeholders. In other words, it was a so-called “Fly-on-the-Wall Observation”. The stakeholders were given access to the prototype and were allowed to use it as if it were a real application. While they clicked around, I observed how well they understood what all the buttons did and how well they could click around and use the app. The observation went well and the stakeholders seemed to mostly understand the app correctly and showed no bigger signs of frustration or confusion. I chose to complete the observation with a short interview where I asked them if they had any additional input and overall they seemed satisfied with the function and design of the prototype.