Habitant — Make your Home as Smart as you Want

This is a retrospective on my first project with General Assembly’s UX Designer Immersive.

When Gan, my partner, chose Smart Home as my topic, I reflexively wanted to headdesk. Why couldn’t he choose something I knew about, something like food (which I chose for him so very kindly)? But then, just because I was familiar with it didn’t mean he was. Gan’s not a food blogger, he’s a tech project manager. He must be looking through the same lens as I was, landing on the topic he knew best.

So that’s a lesson about empathy and understanding others, right off the bat.


I set about doing some background reading and research, including asking Gan for his opinion. It turns out he had been involved in policy work to encourage uptake of smart home tech, which has had mixed success at best. Why should that be?

I used to do donor surveys and focus groups as a fundraiser, so trying to probe people’s motivations came quite easily to me. Still, the user interviews were a fumbling process. I drew up questions that seemed sensible, but which turned out answers I didn’t quite expect.

Q: Could you describe to me your daily routine?

A: Well, I get up, then brush my teeth, then… I don’t have breakfast so I just get coffee, and…

Me: [Internally] No, I meant in terms of housework!

Looking back, that seemed to have been some missed opportunity in itself. I think I had started off with a bit too much sense of direction. Even if routines didn’t involve housework, they would still involve pain points, which would be useful information. So I need to listen a lot more carefully and be a lot more open-minded about interpreting the information given by my interviewees.

Also, I felt the ‘salesman’s temptation’ during the first round of interviews, where I could keep raising examples and ask close-ended questions which might have led interviewees in certain directions.

That said, both rounds of interviews went quite smoothly. The first round aimed to understand people’s routines and their pain points in domestic life, as well as their attitudes towards smart solutions. But more on this later.

Affinity Groups and Identifying the Problem

My original intention was to try an identify a single problem area and design an app to solve that problem. But that ran into an issue as I drew up the first round of affinity maps. Every interviewer had pain points that were specific and had little overlap, so it was difficult to decide on a single direction to move.

However, there were similarities in the attitudes of most interviewees that became the base of my problem statement. Many interviewers’ impression of smart home technology included the following:

  • It doesn’t fit into my (or my family’s) domestic routines.
  • It’s too costly to adopt. This includes expense, but also time taken to learn or configure solutions.
  • I don’t know much about smart home tech and it is too complex for me.

These seemed to be concerns of habit and user preference, which probably can’t be solved by an app. But there were also users who know about these solutions but could not persuade their parents, or people whose friends and family used smart home devices. So these attitudes could definitely change.

So, during my second round of interviews, I tried using a website that sells smart home solutions as a prop — first to observe interviewee’s use of the site, and then to ask if it changes their impressions about what smart home technology is.

The results were quite clear. As long as they were exposed to smart home technologies, and asked to actively consider how they would fit in the routine, interviewees were often a lot more positive about maybe using such technologies. But even then, they were very discerning and specific. Some wanted solutions for grocery management, others for home security, but no one was willing to consider a wholesale ‘smart’ apartment.

Therefore my conclusion: uncertainty about what smart solutions are available, and how they can fit specific pain points, makes users less enthusiastic about all solutions. But if they are shown some possibilities, they are willing to take some solutions on board. People do want smart homes — but only as smart as they need, and smart in the places they need.

Sketching and User Flow

So how to bring a solution to this problem? My solution would have to:

  1. Address users better by directly finding their pain points;
  2. Help users see, easily, how the technology can fit into their homes;
  3. Be able to match pain points, or areas of the home, to existing solutions, so users find the right solutions.

So these became the basic features of Habitant:

  1. A user flow that starts with users identifying pain points. On the other side, solutions are tagged by their target pain points.
  2. A house tour function, which literally shows which areas of the home have potential solutions.
  3. A pool of information (supplied by vendors, presumably), appropriately tagged, that can be served up to users given their specific needs.

The user flow above shows how I envision this to work. One of my concerns was to achieve a balance between specificity and quickness. If I asked users too many questions, and they had to flip through lots of pages to find what they want, it could turn them off. But too few questions and they’d have to scroll through long lists to find what they want. In hindsight, maybe I leaned too far towards giving information quickly.


As someone who’s never learned or done graphic design before, I found prototyping really complex and difficult. I will have to put in the hours and get a lot better at Sketch and Invision! I did eventually manage to get a functioning set of pages and link them up.

Some basic user testing with classmates revealed serious flaws in terms of navigation and signposting, leading to much needed improvements like ‘main menu’ buttons and the ability to edit tags in the information screen.


Habitant is, I think, a flawed attempt at solving a rather complex problem. While I do think it goes in the right direction, it doesn’t go far enough in two main respects:

  1. Finding out more about the pain points of the users, instead of just asking general questions of need and area.
  2. Not giving sufficient information in the information screen, which means users still aren’t as informed as they ought to be.

I think, given more time, I could have thought of better ways to deal with these issues. Working with vendors to get their tutorials on Habitant, for example, could have been a much better ‘preview’ of the tech than just a brief introduction.

Also, a login feature would have been nice. Since domestic pain points tend to be persistent, Habitant would be a lot more useful if it could remember users’ searches and what they clicked on, and used that to refine its own recommendations.

So, all that said, I don’t think I did very well in Project 1. But unsuccess doesn’t mean it wasn’t valuable. It was great to have awesome classmates to give feedback, impart their skills and insights and generally help out. Thanks people! Your help was invaluable. I hope I was able to help you too, along the way.

I learned a lot about my relative strengths (research and problem-finding) and weaknesses (solution refining, sketching and prototyping), so now I have a much better idea of what to focus on and improve. Will need to improve a lot, that’s for sure.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.