top of page

In early July of 2016, 15 strangers met in Chicago to begin the immersive phase of their design bootcamp.


No, it wasn’t an episode of Real World.  There weren’t any cameras (we hope), and we only lived together for 11 hours each day. It was DESIGNATION- an 18 week long course designed to push students to their creative limits and beyond as they learned the fine art of user-centered design and ultimately chose their individual design paths; User Experience (UX) or User Interface (UI). For me, that path led me to the wonderful, pixel-perfect world of UI, but we’ll get to that later. First, let’s take a look back at the project that started it all.


In the Beginning


On the first day of our immersion phase, we were divided into teams and introduced to the mock project we would be working on. Our problem was stated simply; Create an interface that would universally control smart home devices. Because many smart home technology companies exist and each of them have their own applications or dashboards we were instructed to throw that problem out and to move forward as if all of the devices would work seamlessly together in one interface. So, pay no attention to the magical compatibility behind the curtain.


Defining the Problem


Currently, smart home technology is controlled through device-specific platforms resulting in users having to access multiple applications to manage their smart devices. Our team was briefed about the problem and open-endedly challenged to design an interface that could control any smart home device, leaving the platform open for us to choose.


Identifying Our Users


29 products explored

14 industry research papers read

38 people surveyed

  1 SME interviewed

  6 users interviewed

  5 competitors analyzed


The very first thing that we did as a team was to discuss what smart home devices and types of technology we were aware of. From there we each conducted a brief search online to see what types of smart home technology and companies existed. Then we set to work crafting a research plan and thinking ahead to user interviews. We knew that, in order to create a user-centered design, we needed to identify who our target users, and what their needs, were. I drafted questions for a user interview guide then created a matrix to schedule interviews in such a way that every team member had the opportunity to take on both the moderator and note taker positions. Our team conducted five interviews, two of which I was directly involved in as either the note taker or the moderator.


We interviewed participants who were potential or current smart technology users and, using cards with illustrations of different types of smart home technology, we had them do a card sort. Asking the participants to place the cards in order of importance, we then recorded the results, transcribed the interviews, and set about identifying patterns. Once all of our data was collected we broke down bits of the information and placed them on post-its. These data points included everything from demographics to personal narratives about our users’ experience with smart home technology. From there we created an affinity diagram and began the process of narrowing the data. For this part, I jumped in and offered suggestions for categories as I am cheerfully in my geek-zone finding patterns and organizing information. When we were through we had categories that ranged from demographics to things like user wants and pain points.

While we first envisioned that smart home users would all be in the “young and hip” crowd we were surprisingly wrong. Over half of our users were aged 39 or above, were married homeowners, and were female.

Empathize and Define

Katrina- “The Busy Caregiver”


2  personas

1  app map

8  user stories

4  scenarios

5  design principles

1  problem to solve

Through this synthesis we were left with a much clearer picture of who our users and their needs were. So, we dove right into the next step; creating user personas and stories. Each of the four team members created two personas to begin with and from these we chose two to move into the next round of testing. One of the remaining two personas was a young father who was an early adopter of technology. Ultimately, as we began to explore the personas more and applied them to feedback we later received during user testing, they were narrowed to one; Katrina.


Empathizing with our users


I created Katrina by honing in on the older segment of our user population and identifying what their concerns were. For many of our interview participants, home surveillance was their greatest concern. So, I developed a persona that was an older professional woman whose mother had been forced to move in with her after suffering a stroke. Katrina’s interest in smart home technology began when doctors informed her that if her mother would have been able to receive medical attention sooner, the extent of her injuries might not have been so severe or permanent. This left Katrina feeling constantly worried about her mother’s well-being while at home alone. As Katrina was very dedicated to her job, she couldn’t afford to be hugely distracted or to have to leave work because of concerns for her mother. Furthermore, she knew that if she could both see and hear her mother at any point (and from anywhere), she could respond immediately to an emergency.

Throughout our interviews, a common thread became apparent between our participants. Many of our users were driven to explore smart home technology in response to a traumatic event that took place in their home. Katrina “The Busy Caregiver”, although a fictitious person, had concerns that were reflective of a large number of the users we interviewed and uncovered through research. She represented the mother who worried about her children when they were alone with a sitter, or the pet owner who wanted to peek in on their furry companion during their lunch break. She characterized the feelings of anxiety and disconnect that many of our interview participants voiced, while away from home.

Design Direction:


With one clearly developed persona and a small mountain of data, we defined our

problem statement-


“Busy caregivers need a convenient way to understand, and respond to, what is happening at home to ensure peace of mind.”


And created 5 design principles-









Our team next outlined a user flow, taking into consideration the most important steps a user would need to take to make use of our app. We started with the onboarding process which would take the user to an installation screen where they would connect their smart devices and then be directed to their dashboard. As a team, we decided to choose one device to develop out for this step so that we could test user response so we chose the camera feature as surveillance seemed to be the primary concern with the users we interviewed and surveyed.

We each created paper prototypes which we then tested on a new group of participants. After observing how our participants clicked through our prototypes a few flaws were uncovered. The biggest of these was that some testers didn’t intuitively understand what some of the labeled icons on the dashboard would take them to. Each team member had created divergent names for the applications features and what we found was that the participants’ mental models didn’t always align with those names. We regrouped and concluded that we needed to come to a consensus about how we should label the features. Through a quick card-sorting activity with a fresh batch of testers, we were able to identify feature names that were familiar and identifiable to users. Using this information, we designed our clickable wireframes in Axure.

Making It Clickable and Pretty

It was while designing the wireframes that I really began to think once again about our persona, Katrina, and who she represented. I stepped into her shoes, and into those of other concerned users and considered how I would want to feel while using this app. Designing an interface to be simple-to-use is the easy part. Instilling comfort and, more importantly, empathy into a high-tech gadget application is a bit trickier. I did one small thing in these wireframes that continued to influence my design process throughout the remainder of the project. I gave the user a digital “pat on the back”. Something as simple as adding a phrase like “Good to Go” as feedback and positive reinforcement was received extremely well by all of the users we tested in the next round. Users often read the text aloud and commented appreciatively about the feedback.

Once the colors were chosen I began the process of creating the high-fidelity key screens. During this process I went through several iterations. The first iterations really display a great deal of room for growth. The first things to go were the dark iconography and the umbrella icon. For this app we were originally designing a feature we called “Scenes”. This was a feature that would allow users to set routine functions such as automatically dimming the lights in the evening and locking the doors. Users might call a routine like that “Bedtime” or something similar. In a quirky moment, I decided to use the umbrella icon as the ‘Scenes’ feature encompassed a number of functions. They were “umbrella-ed” under one feature. Get it? Don’t feel bad. No one really did. So, I dusted myself off and jumped back in, going through two more iterations until I settled on an icon that made sense to our users and making the interface cleaner and less outdated. After gathering as much feedback as possible from my teammates, instructors, and other members of our program, I wrapped up the final iteration and started work on the prototype.

Our team built our clickable prototypes in Invision and then set out to do usability testing. Users were given a specific task flow which was to navigate through the onboarding process, add a device, go to the camera screen, and then respond to a notification modal. Testers were asked to use the think-aloud protocol so that we could record and take notes. After each team member’s screens were tested, we asked the participant to rate things like color, comprehension, and feelings, on the Likert Scale. In the notifications screen of my prototype, I included a “reminder” icon which was an illustration of a finger with a ribbon tied around it. What we found, through testing, was that our older participants recognized the icon’s meaning immediately. But, for younger testers, they had no idea what the finger with the little ribbon meant.

One participant even stopped in his tracks and said, “Uh..its giving me the finger? I’m not sure what this is.”  

As a part of this phase of the program, each team had to narrow their final product down to one design. This meant one of two things; We could either create a “Frankenstein” of our designs, or someone’s work was going to get thrown out. There were a number of insightful observations that our participants made and pain points that they noted. As a team we looked back at our designs and the user feedback that we had collected for each of them and discussed what should stay and what should go. As I reflected on my own designs, I now saw many gaps and holes and number of things that I wanted to throw out and do differently. I understood why my iconography was difficult to understand for some users, I understood why my somewhat cluttered and heavy design was not received as well as I would have liked. Looking back, I can identify how outdated and cluttered my overall design appeared and it was no surprise to me that, with current trends leaning towards clean and minimal designs, mine was not winning many popularity contests. Overall, the users liked my colors and did find them friendly and comforting. I believe that it was more my bold application of them, that turned some of them off. My feedback modals and text was universally well-received, however, so that element flowed over into the final product that our team delivered.

Reflection and Re-iteration


In a span of four weeks I had the opportunity to take everything I had learned about design and apply it directly to a real-world problem. There were ups and downs, a-ha moments and uh-ohs, and things I did that were surprisingly well-received along with some that were decidedly not. The journey was very much a trial by fire, but I took a tremendous amount of knowledge and skill away from the experience. I also noted many changes I would make if I could do the project again knowing what I do now. My personal design style has improved and changed a great deal since I did this project. I’ve gotten more comfortable with when and how to use white space, my layouts have become cleaner, and I’ve dropped the bulky, outdated iconography and sectioning. I’ve also learned a lot about my own perception of my work and the importance and value of feedback and critique. Ironically, as I’ve moved through this program, I’ve realized that I often think I haven’t made enough use of a layout’s space. However, aesthetically-speaking, it’s been pointed out to me on more than one occasion that I already cluttered a design or that what I thought was too little, was actually just right. It’s cliche, but it turns out that less is actually..more. That concept could certainly be applied to my smart home interface in any future iterations. Coming into this program I had only just discovered that my personal style was very heavy, gritty, and bold. I don’t think that there’s necessarily anything wrong with that, but I have certainly learned that there is a time, a place, and an delicate application process to pulling anything off. If it takes a good eye to spot these sort of rookie design flaws, then I would certainly say that eye is at least now open.

bottom of page