a Thesis Process | The Design Process(5/5)
This medium series presents the process of creating my digital design Thesis, done during my MFA at Parsons’ Design and Technology department, 2013–2014.
Personas and Scenarios
In order to understand the flow of use of the product, I have created a few personas, and built for them relevant scenarios.
Adam Brown is an undergraduate student. He is studying art history at the University of Maryland. He lives in College Park in an apartment with two other roommates. Back home Adam has always had a TV set, but now he doesn’t want to spend the money on the device or on cable. He still wants to keep watching all the shows he is following, so he turns to online TV. He is afraid to download stuff from PirateBay, since hearing of friends of friends who have gotten a scary letter from the FBI. That is why he mainly streams stuff online and tries to find the official sources first. He uses his parents’ Netflix account and the free Hulu a lot. Adam notices that his friends on Facebook were sharing what they were watching right now with this app called “WatchThis”. He clicks the link on his friend Sarah’s wall. After allowing the app access to his Facebook account, he gets to see all the shows that Sarah is watching. He likes a lot of them, yet some he doesn’t know. He clicks on “Elementary”, a show new to him, and reads the summary. It seems to be interesting. He clicks the link to the pilot episode, which shows him where he can watch it right now. Some links are free, some are paid. The service suggests that he logs-in in order to link his Netflix and other services. He has the option to do so with Facebook, which seems pretty easy, so he does. Fast forward three weeks, and Adam is constantly using WatchThis. Whenever Adam is home alone, eating a meal, he wants to watch TV. That’s when he opens up WatchThis on his computer and sets the time he has to eat. Most days he has time to eat while watching a 45–50 min show, but today he has to make it quick. He sets the time limit to 25 min and picks a random show out of the “filler” list he has set up. There is a new episode of “Family Guy”, perfect for a quick lunch. Adam clicks the link and it opens up Hulu in the next tab. His account automatically shares what he’s watching on Facebook.
The three roommates also have a joint list which is automatically populated by any items that the three of them want to watch and haven’t yet. This makes nights when they all want to watch something together on Jen’s TV in the living room really easy. Jen just goes into her WatchThis app on her computer and opens up the joint list. They go through the list quickly and pick something. Jen then casts the show on the TV using ChromeCast. The app knows that they all watched the show and marks it as “seen” on all the accounts.
The Reynolds family, mom, dad and five year old Max, have a huge screen TV in their living room in Hoboken. They are paying for cable services, own an AppleTV and have a Netflix subscription. They do not have time to go through endless options online in order to find something to watch so they don’t use online TV. In fact they do not use their computer at all for watching, they only use the TV and the iPad. The main user of the iPad is Max, who gets to watch ten minutes of TV every evening before dinner, and tons of time in the car, just to keep him busy. Sharon (mom) learns about this new service “WatchThis” which presents a large range of options, including Netflix, in one place. It also works on iPads, which suits them perfectly. She downloads the app and logs in. She can create a profile for Max in order to monitor his watching. Fast forward one month, the family loves using WatchThis. Max gets to watch ten minutes of TV before dinner. He is allowed to open the app on the iPad and it automatically goes to his account as the other ones are password protected. Mom says he can only watch for ten minutes, so he set that on the slider. He can watch one segment of “Dora the Explorer”. He taps that and then scrolls to find an episode he wants. He has already watched all the episodes more than once, so he knows his preferences. Once he picks an episode and hits play, Sharon hits the AirPlay button to cast the show on the TV through AppleTV.
After Max goes to sleep and Sharon and Dave are done tidying up the house, they cozy up in front of the TV. Now they can go into their profile on WatchThis and go back to watching their shows. They are rarely up to date on current shows, but really like to binge watch when they have time. They are currently watching “Breaking Bad” together. So they tap the queue and just pick up where they left off last. After 20 minutes Sharon falls asleep so Dave marks that episode as seen for him, but not for her. She will catch up later on so they can keep watching together. He can even put a bookmark on the episode for her to mark when she stopped watching.
Prototype 1: Paper wires
Walking through the concept, October 2013
In order to be able to talk through my thought process, I made an initial paper prototype exploring the different features I had in mind.
I started off by expressing my plan to create a personalized service so that any content the user sees on the interface is the user’s own; your watchlist and TV shows followed.
I also wanted to explain the process of connecting to outside services like Netflix and Hulu, information applications like IMDb, and social networks.
Other features I presented were:
• Personal stats for each user, including time watched, number of shows followed and more.
• A social stream showing matching actions of the user’s friends.
• Joint watchlists for friends, couples and families.
My main exploration for prototype 1 was to consider how the main page interaction will work. I attempted a few methods of information organization and tried to come up with a new experience for watching online television.
The conclusion indicated that the most interesting direction was organizing content by types of experience. I initially tried these: Quick Watch, Movie Night, Guilty Pleasure and Binge Watch.
Prototype 2: Digital, free-standing wires
Figuring out the main features
In this iteration, I transitioned into the digital space and presented snapshots of the interaction. The main interaction with the content was through this initial division: New Episodes, Quick Filler, Binge Watch and Movies. Each section also presented its own time selection, so that the duration of watching could be adjusted according to personal preferences. Each title would open a drop down menu with the list of available items. I also showed the ‘first time use’ and account setup, the settings available for each show and the site structure, and I introduced the “Addiction Level”. I wanted to have a gauge which the viewers could set in order to indicate how much they liked a show. I also added a “Hell No” option for disliked contents. These different levels of addiction would play into the order of the content within the queue: high addiction on top, and low on the bottom. I concluded from the testing that the phrase “addiction” might be a bit problematic. I have yet to find a better term for this purpose.
Prototype 3: Digital wires, fully fleshed
Figuring out the main structure
The main goal of this iteration was to understand the structure of the service in its current form — a desktop website. I divided the service into a few sections:
• The landing page / main page would display available-for-watching episodes from shows that the user is following.
• The Discover page would allow the user to browse through more content, add it to lists or just play it.
• The account page is where the user would add services and change settings.
I explored the option of having four different content parsers on the main page: Quick (a show around 20 min), Show (around 45 min), Movie and Binge. I introduced a slider interface that allows the viewers to quickly switch from one option to the next without feeling that the page is reloading. I explored a few different interfaces for the main page.
Upon testing I decided to go with a more visually enticing interface for the content: big images for each show.
Prototype 4: Digital, interactive prototype online
Prototype 1 on Invision, November 2013
In this iteration, I worked off of the wires from the previous prototype and started to explore how the viewers would flow through the interface. This made some gaps in the flow very apparent so I completed those while converting the prototype into an interactive one.
In this version, I first addressed the issue of browser mode vs. TV mode. I realized that I needed to take into account the type of controllers used by the viewers and their distances from the screen. I wanted to give the viewers a chance to change the interface, when needed, for an easier interaction. The TV mode would present larger content which is easy to see from far away (“The 10 foot experience”) and the interface will allow for easy interaction with only a mouse.
One popular demand during feedback was to drastically change TV mode so that it will be very different from the browser mode.
Through testing, I came to the conclusion that I had to take into account other controllers, like a TV remote and game controllers. I tried to keep this in mind when I designed a few options for the additional information for each show. I intended to steer clear of the common “hover” option in order to make the interface approachable by different controllers.
Another main concern that was raised was the amount of information on the screen and the lack of hierarchy. The term “Show” also proved to be ambiguous and I agreed that it could benefit from some more clarity.
This prototype was a great opportunity for testing my initial ideas and figuring out which features I would like to include in the final product. I came to the conclusion that the main interaction with the product is too familiar and too close to what we have now. I decided to put this iteration aside and start from scratch with some brand new and hopefully different concepts for interacting with a list of TV content online.
Prototype 4B: Visual design snapshot, digital
First take on visual design, November 2013
I played around with a few visual styles for the service and finally created one take. My goal was to keep the interface clean, while making sure that the different states of the functions were very easy to quickly understand.
In testing, this version proved to be too cluttered, presenting too much information with no hierarchy. Some concern was raised about too much use of white, and again the lack of drastic change between TV mode and browser mode was expressed. I learned that I can not shy away from the norm of using a black background for the TV mode, given the great demand among testers.
Tech Prototype 1: Parsing through a database
I created a simple test site that can parse through a list of shows, and fish out just the current ones. I tried to practice dealing with databases and dynamic data. The next stage would be working with the GuideBox API and managing to parse through their live database.
Prototype 5: Paper wires
Rethinking the boring interface, December 2013
The goal of this iteration was to try to leave the confinements of the ordinary media selection interfaces, like those we see on Netflix/Hulu/Amazon. I wished to go beyond the grid of static movie posters and TV show images. I started by trying to rearrange the content on the page, and also the additional information about each program. I decided to explore the idea of signifying multiple episodes from the same show with a digital stack of items. I also tried to show the addiction levels as different sizes. I tried different information presentations for different controllers.
One idea I came to is utilizing the advantages of the online platform by displaying all the content as dynamic video. In this case, instead of showing a static image, each show would be signified by a video of the title sequence of the show, and/or scenes from the last episode watched. My hope is that this will entice the viewers to watch the next episode.
Another observation I made and wanted to incorporate is the level of attention required from the viewers for each show. This difference between a high, medium and low attention, could help in the tagging and selection process of the viewers.
Prototype 6: Digital freestanding user flow wires
First semester final presentation, December 2013
In this iteration I wanted to convey clearly the conclusions I got to by testing prototypes 4 and 5. I came up with a list of exciting and important features that I knew I wanted to include in the product, and presented them through short use cases. In addition I presented two versions of interfaces that I developed from prototype 5: a web interface and a TV interface.
The features include:
• First time use and sign up, discover and search for content, get service recommendations, add new content, setup settings for each item.
• Social interaction through the service, see what your friends are watching and get recommendations, share, create easy collaborative watchlists that are automatically populated by joint content.
• TV and browser modes, difference in size, color and dynamics of control.
• Second screen experience, get access to information that is useful while watching; like IMDb, twitter feed and options to share.
The exploration of the web version consisted of an interface in which there are differently sized items to show the level of personal addiction, stacked to signify the quantity, and organized by time. The items are separated by the type of experience the user is looking for: Quick, Catch Up, Movie and Binge. Each item has its own video player, already showing the title sequence or recap scenes.
The TV version was centered around a full screen video player that plays on entry to the service. The transition between items is linear, allowing for a quick and easy interaction with any controller and device.
I feel that at this point I need to decide what scope I will go for in terms of my thesis project. I need to decide how many versions to make and how many platforms I want to design for. This will change the way I approach the design and which route I will take: browser vs. 10 foot experience, mobile vs. desktop, game consoles or smart TV app.
I am currently exploring the idea of having a mobile app that casts to a television only. This way the experience is being limited to the mobile platform and the TV screen.
I intend to create a few rapid prototypes and test them out during the next week.
Updates are yet to come!
Prototype 7: Digital mobile prototype
Peer review at MFADT
I had the privilege to present the current state of my thesis to a group of eager first years and in doing so, test my seventh prototype. I wanted to use this opportunity to explore the scope of the product and decide on the platforms for which I wished to design.
I wanted to test a version of the product that will consist only of a mobile app which would cast to a television screen, which means beginning the interaction by using the smartphone and being presented with all the information on said platform. Once casting to the television via Chromecast or Airplay, the content is presented on the big screen. At that point the phone becomes a controller.
In this iteration I created a simple prototype for a smartphone controller for the video playback screen in order to determine if the mobile+casting option is viable. The most relevant feedback I got was that of the viewers’ wish to keep using their smartphones while watching, a datum which asserted my initial assumption. I need to make clear for future iterations that once the casting is on, the viewer can still interact with the service simultaneously with using other applications.
One other point that was raised dealt with the abundance of shows on the interface. Continuing with the project, I will take into account more types of users and design for both the power viewer who follows 30 shows and the occasional viewer who only watches a handful. I want to make sure that the interaction works well for both.
Main features, main interactions
February 3, 2014
When presenting the concept for my thesis, I am usually faced with this question: What about the rights? You can’t take content from Netflix and HBO.
Well, I have to make this clear now and in the future: I will only provide free content from official sources and paid content to those paying for it. So there will be access to all the free content in the free tier of Hulu, and to all the available episodes on CBS and NBC. If you have a Netflix and HBOgo accounts, you will get their contents as well. The videos will also be branded so that the user will know which service is providing which content.
The next step for my project is trying to understand what the service will be — what are the features and what are the devices? My current idea is to have the service be casting based, meaning that a mobile device will cast the content to the television via Chromecast or AirPlay. Once the mobile device is connected to the television and is in casting mode, the mobile device turns into a remote control and the main interaction happens on the big screen. The mobile device will also supply second screen interactions while playing the video such as displaying IMDb information and relevant Twitter feeds.
If this is the case, I will have to address two states in the interface: The mobile device while not connected, and both the mobile device and the television interface while connected.
In terms of features, the 2 main features and benefits of the service are:
The service will collect all the content and information in one place, making it easy for viewers to search through options, see what is available and watch videos from one place.
The service will allow the viewers to cast the content to the television and watch their videos on the big screen.
The three main interactions with the services are:
Watch (or consume)
The service will serve the viewer with options on what kind of watching experience they want, offering either a “Quick watch”, “Catch up”, “Movie” or “Binge watch”.
The mobile device will cast the content to the television and be used as a remote and as a second screen experience.
The service will help the viewers keep track of what they wish to watch, both movies and TV shows, and keep track of which episode they are on.
A tagging system will make it easy for the viewers to get the exact content they want right now, using personalized craving levels and attention levels for each show.
The service will allow for an easy way to connect to all services in one place and help the viewers discover and join new ones.
The joint watchlists will help viewers watch together by automatically generating lists of the common items of all viewers. Couples or friends watching shows together will also find it easy to keep track of joint shows.
The service will allow the viewer to know what friends/others are watching and this way discover new content.
Consumption user flow, paper wires
February 9, 2014
Now that I know what will be my app’s main structure and functionality, I can start to consider what the main flow of interaction will be. I prepared basic paper wireframes in order to understand and test the “Consumption” part of the interaction: both the state in which the casting is on and when it is off. I tested the main flow with about 6 testers.
I am currently serving watching options by using four sections:
•Quick: Available episodes of short shows you are following or episodes you want to watch again.
•New: Newly available episodes of shows you are following — high addiction.
•Movie: Movies you have added to your watchlist and want to watch.
•Binge: Shows you are following and have more than 5 episodes available to you.
The testers expressed difficulty with the term “New” and the term “Addiction level”. “New” proved to be confusing and was thought to mean new shows for the viewer to check out, as opposed to new episodes from shows they already follow.
According to two testers, the term “Addiction” has a negative connotation to it and hints to a guilty feeling accompanying the experience. I need to think these terms further and find better and clearer solutions.
Some testers failed to understand that the service is already offering them personalized information that is curated according to their preferences. This is hard to convey in a preliminary test, so next time I will try to go through a little bit of the app’s setup with the testers, and give them the feeling that the app is now personalized to their needs.
Most testers did not notice the casting icon — they engaged with it only when it was pointed out to them. I assume that the icon was not prominent enough. Once the casting started, the notion of using the phone as a remote seemed to be accepted immediately.
While testing the iPhone as a remote for the casted TV interface, I let the testers have control and tried to not steer them in any specific direction. I wished to see what would be their intuitive gestures. I also enquired all testers about the actions they would perform during a watching session. They pointed out these actions and gestures:
•Hit pause/play — tap once in the middle, tap twice in the middle.
Turn volume up and down — swipe up and down, use volume keys on side of the device.
•Move forward and backward within the video — grab the marker on the timeline, swipe left or right to scrub.
•Go back 10–30 seconds — hit the designated button, swipe left to scrub.
•Mute other applications, go to other applications. In this case, I suggested having the app still open at the top of the interface across all apps, for a quick return and video controls.
Two testers who wanted to share a certain part of a video, suggested taking a snapshot of the visuals. I feel this can be accomplished by adding a bookmark feature that will allow sharing of a scene or segment from the video via social networks, linking back to the service (hence, not breaking copyright laws or spoiling plot twists).
In terms of the technical side, Dan (then Boyfriend, now Husband) and I have been looking into prototyping using Chromecast. Google has recently opened their doors to developers and they are now offering a Chromecast SDK (Software Development Kit). We now begin to understand the process and are trying to get the sample code to work on my own device. We hope to be able to test the phone as a remote control by using the Chormecast API.
I’ll give this route a week, hoping it pans out. If not, I’ll look into remote control apps that connect smartphones and computers in order to mock up a responsive interface.
Status Update and new paper wires
February 17, 2014
I presented a status update on Tuesday, February 11. In it I went over the main features and interactions.
Two main features:
• Aggregation of services
• Casting via Chromecast or AppleTV
Three main interactions:
• Share and Discover
(See Feb 3 entry for details)
I then asked for help with two problematic terms for features in my service: “Addiction level” and “Catch-up” / ”New”. As I’ve discussed before, the word addiction stirs negative connotations. The term “Craving” was brought up as a replacement and was received warmly by the class. I integrated the new term in the wires that will be tested on Tuesday. As the second term still proved problematic, for the next round of testing, I decided to use a very (hopefully) clear phrase: “Your new episodes”. My intent was to make sure that the viewers know that these episodes are newly available and are of shows they have been following. I will test these assumptions on Tuesday.
In the status presentation, I spoke of the feedback from the first round of tests of the consumption user flow (casting on and off) and explained my next steps. Since, I was able to further explore the user flow and wire the rest of the service, taking into account the feedback from the last testing. The testing wires for Tuesday now include the whole mobile user flow when casting is off: the main screen with serving options, the menu, TV shows watchlist, the social feed and a show page.
I hope that the testing on Tuesday will help me identify pain points in the user flow that I can solve before designing the interaction via casting, which is the next step.
I was also encouraged to work on a short mission statement for the project.
In terms of the technical aspect, I showed the Googlecast SDK which we was inspecting. Since then Dan managed to get a basic application to talk to Chromecast and will continue to explore in this direction.
Figuring out the main serving options
March 3, 2014
When opening the app, the viewer is invited to choose from a selection of serving options. These provide shortcuts to content, organized by the type of viewing experience that the user prefers. From the beginning of the project, I have been talking to viewers in order to try to understand how they watch television and how they choose what to watch next. Early on I came to four main experiences: Quick, Binge, Movie and Catch Up.
While conducting my tests in the past few weeks I’ve noticed that watching experience is very individualistic. I decided to try to come up with as many serving options as I can and test them in order to understand which would actually be used by what viewers. I organized the options in order from most used to least used, as I saw it. I had about 15 testers mark all the serving options they would use in blue and the top three serving options they would use the most in red or pink.
The results were very interesting as there were no clear winners. From this, I concluded that what the viewers really need is an adaptive service that allows them to pick and organize their own serving options. This way, every viewer can use only the serving options that would be useful to them.
Midterm presentation & next steps
March 13, 2014
On March 13 I had the opportunity to show my mid-term presentation — my project as it is today. I presented the latest progress into digital wires, using a keynote prototype. I gave a brief background, explained the need for the product and showed the main features and interactions of the service.
Both Emily Wengert and Nick Fortugno remarked that the most innovative and interesting part of the service was the social aspect.
Emily focused on how the app was successful in mimicking a real-time watching experience by using the pop-up comments. She suggested that this could be pushed further, maybe by incorporating voice recordings and instantaneous messaging.
Nick discussed the fact that we can no longer have a conversation about current shows because we no longer watch at the same time, and referred to the fear of spoilers. He also talked about the need to know what your friends were watching and have that lead the experience, watch what your friends are watching, binge your way up to where they are. Nick suggested that the service’s main purpose could be to coordinate social watching.
Colleen, Emily, and Nick all agreed that the tagging and categorizing aspect of the service are a little overbearing and could be downsized.
Emily also noted that the entry level language is a little difficult. I could ease new users into the service and add advanced features gradually.
She also stated that a lot of effort was required of the user in order to set up the service for the initial use. I will take this remark into account and see how I can simplify the process.
I will attempt to put more emphasis on the social aspect of the service and simplify the overall use. I plan to create a few more paper prototypes in order to explore more directions before I finalize the digital version.
Next, I will have to decide what will be the extent of the final prototype. Deciding on one of a few options I currently consider depends on the time I have left.
April 1, 2014
The next step of the process was figuring out what would be the best way to present my concept. I chose to create a video that depicted a sample of user flows. This video had to be short and exciting and needed to entice the viewers to explore the product further.
I’ve lost my objectivity about the product long ago, so I decided to get my peers’ help in deciding which were the coolest features. Only the top features will be presented in the video. I created a simple check mark paper form and handed it out in class. I then went over the list of proposed features, explaining each quickly and with the help of a visual presentation. My peers marked the ones they thought were the coolest. I then collected all the forms and tallied the score.
The winners were:
• See what your friends are watching
• “Real time” comments + hidden comments
• See who is following a show
• Joint watchlists
In addition to the video I wanted to present a prototype. I’ve been working on a web app version of the app for quite some time. At that point I had much of the front end ready and was on the way to create a static database in order to populate it and create an illustration of the concept. This was when Dan stepped in and took on the challenge of making my thesis project real. This was also a way for him to learn more about APIs. So as I went on to do what I loved, which was designing, Dan worked on the back end of the proof of concept app.
April 18, 2014
I started making a rough storyboard for the video.
I tried to focus on the features that were voted most cool, showing the general use cases of the service.
The video narrative
The main protagonist is Dan, who at the beginning is watching TV alone. The opening scene explains how the service connects to Chromecast and presents the serving options. After Dan starts watching, the screen splits and Jeannette is seen on the left. Dan and Jeannette are watching the same show. Captions explain that Dan is watching currently while Jeannette was watching a week before. She posts a comment and it pops up on Dan’s phone (the purpose here was to explain the “live comment” feature). Dan then posts a comment of his own and keeps watching.
At a different location, Jeannette is looking through her Facebook timeline on her phone. She sees Dan’s recently posted comment and goes through it into WatchThis app. From there she shows a few of the social features- the friends’ timeline “Watching Now” and a friend’s profile page.
Moving on, Fei is seen putting on a show as “Background Noise” (here I wanted to show how the user can cast a show and still multitask on the phone). Fei sits down to check her emails, when a blue top bar appears to indicate the casting of WatchThis. Through this bar she can return to the app easily.
The next scene shows Shira and Martin sitting on the couch. They pick out a show from their joint list and play it. Here I wanted to show how the phone is used as a remote: Martin asks to skip the title sequence of the show, so Shira presses forward on the phone interface and the whole video including the music (Happy — By Pharrell Williams) fasts forwards until the titles are over.
The last scene presents a feature that brings joint watching to the front — “WatchThis together”. A group of friends are sitting on the couch with Dan. He opens the app and adds their names to the Watchthis Together section. The service then shows him what options they can all watch together: shows in which they are all synced, fillers that they have in common and new shows that they might all like.
I had reserved a Canon 5D camera and the shooting had to take place on the weekend of the 25–27 of April. This gave me a definite deadline for completing all the designs and wires I needed.
After much discussion, I decided to leave the TV preview feature behind. This proved to be very difficult in terms of tech and besides, I felt that the concept of the product was strong enough without it. Consequently, for this MVP version, the users had to look at options on their phone and only the videos could be casted on the TV. I think that previewing on the TV is a great feature, but I had to give it up for the sake of time. However, I thought it worthy of being mentioned in my presentation as a future feature.
The app was connected to TVRage API, pulling all the info (four thousand shows total) into the app setup. The serving options have been functional already and Dan started working on creating a user database. Creating every nook and cranny of the app meant that I had to deal with many design problems of which I had not thought yet.
April 28, 2014
I have newly found respect for cinematographers. Even though I’ve experienced every aspect of filming days on many occasions before, this was the first time I had to fill all the roles by myself. The shoot went on schedule and I had prime material to work with.
Editing Editing Editing
May 3, 2014
I feel that video is a powerful means to convey a concept, in terms of look and feel. I did my best to fulfill my vision and used Adobe After Effects to bring the digital interaction to life.
Since I had planned to use the video as my symposium presentation, it had to be limited to four minutes. In order to accomplish that, I had to cut a scene out. I decide that the “Background noise” feature was the least important.
Most of the screens are already working and the user database is functional. Both Dan and I are using the app and updating our info in order to test its usability.
I decided to reframe the project since it had become more about the social aspect. I changed the tagline to “A Social Interface for Online TV”, placing the interaction with friends at the center of the service. I knew this was the most interesting and exciting part of the service and so it deserved the honor.
May 11, 2014
As I was writing this, the last version of the video was rendering out. Next step would be finalizing the website for the product.
May 15, 2014
The project is done and you can check it out here: www.watchthisapp.orandaan.com
I would like to thank everyone that helped with the making of WatchThis:
My Mom, Jeannette, Veronica, Michael, Fei, Sarah, Kamilla, Matt, Shira, Martin, Mike, Kunal, Jamie, Ted, Barbara, John and Colleen.
A special thank you to my BTSE (Best Thesis Section Ever) and BTTSE (Bestest Thesis Section Ever) for their support.
I could not have done any of this without the love, support and coding of my amazing boyfriend (now husband) Dan, who built the working prototype from scratch.
This medium series presents the process of creating my digital design Thesis, done during my MFA at Parsons’ Design and Technology department, 2013–2014.