New Quarter, New Queery, New Hubris

As Chelsea and I continue our quest to bring Queery to life, we had to start extracting a singular thread of reality from the mystical cloud-of-what-could-be.

In many ways I think this has been the most challenging aspect of our work thus far. Every decision is a hard-fought battle between individual expression of hopes and desires which is constantly tempered against what is appropriate for the community we are trying to serve. These decisions usually are a compromise in one measure or another and they ultimately pick a singular reality at the expense of all others.

That’s not to say that we can’t go back and try other solutions, but if you have ever been in any software development shop for any period of time you know how expensive and rare that is.

While we have been slowly building our app, it is clear that our ambitions were considerably beyond our talents.

We reflected on this, stressed out a bit, and considerably scaled back the fidelity of our pilot. We now have a Google form to handle what the schedule flow would have covered and we will be hand-matching individuals as they sign up.

Chelsea also created this nice sign to remind us to keep it real.

I’ve kept an eye on that sign to remind myself to work within the now instead of the what-could-be and to see if either of us had the courage to bump the day counter up.

It’s been over a week and that number hasn’t changed.

How to create a pilot app for $1.54 (and a fair amount of time and aggravation)

Fair warning, this is a technical post and doesn’t cover much (if anything) design-related. I just wanted to share what I used to allow for us to build up a prototype without much cost.

As we are knee-deep into the fourth and final quarter at AC4D, the task is to pilot our ideas within the community. The amount of fidelity can vary greatly, but one of the goals is to assess whether or not our abductive leaps have landed on solid ground.

I set a rather ambitious goal to actually build our application in its entirety. I also wanted to explore a few technologies which I haven’t had the time to investigate otherwise, but I believed were going to be a solid fit for our project.

The first thing I did was to go to Walgreens and purchase a pre-paid Visa card. Many online services, especially the ones I wanted to employ, require a credit card to be on file before utilizing any free trials. This allows me to create a solid budget constraint and to avoid any security issues with my personal credit in case the data is stolen, which happens more often than you’d like to imagine.

The next steps occurred in a less-than-ideal order, but it worked for me.

I went to Amazon Web Services site and configured an EC2 instance. The Linux micro instance is free for one year. Since I am no stranger to their pre-configured Ubuntu instances, it was an easy choice.  I could create a complete separate post about this step, but the short-short version goes like this: Read the directions they give you, read them again, attempt what they describe. Rinse, wash, repeat.

Once the EC2 instance was up and running, I poked a few holes in the firewall to allow for an SSH connection and HTTP. I also created a set of SSH keys so that I could safely connect to our git repo and deploy code. You don’t have to have a git repo, but I certainly recommend some form of version control other than copying and renaming folders.

So why choose EC2? Freedom and cost. The EC2 micro instance supports nearly any stack you could possibly wish to use. If I had chosen a typical hosting service, I would pay a lot more and have rather limited choices as the IT manager for hosting services usually likes to keep their servers in lock-step and tend to lag on support for the latest libraries. EC2 is free for a year and I can do what I like. That’s an incredible deal.

Having said that, if you would like to save yourself some incredible configuration headaches, Digital Ocean is a rapid up-and-comer in the hosting space which provides a ton of flexibility, a great management interface, and very little challenge in configuration. You just pay a bit more for the convenience.

With this much configured, I wanted to get a server up and running as quickly as possible. I had played a little bit with Meteor in the past, but I wanted to try it for our project for a few reasons:

Firstly, it is a complete stack with a Node.js front end and an integrated Mongo data store. My view is that if I need to use HTML, CSS, and JavaScript, why not let that be all I have to learn instead of trying to pile on Python or Ruby? Granted, CherryPy and Flask are pretty quick-and-easy, but a simple stack means that it’s easier to bring people onboard to help. Mongo is a recent favorite technology of mine since it doesn’t require a strict schema. I can add new attributes without having to retrofit.

Secondly, it takes only 4 lines to install, create a project, navigate, then start a server. I would be able to discover any network issues very quickly this way.

Thirdly, it is intended for use as a web app. Updates to data or behavior are pushed out to the user without having to ‘bounce the server’ (stop the server, make chances, then start the server).  This also means that the site is always ‘live’. As the users interact with the system, it can constantly update the other users’ view. In the case of Queery, this means that the moment a new meeting is available, other users could be notified. Static web pages can’t begin to come close to the level of interaction possible.

So far, everything I have described has cost $0.00. So where does the $1.54 come from?

If you want a domain on the cheap, 1and1 is impossible to beat. If you want a .com, it’ll set you back a whole $0.99. This sometimes means you need to get creative with you domain name, but ‘’ seems pretty reasonable to me.

To get the name ‘’ to point to the EC2 box, I had to use Route53.  I honestly don’t know if there is another way to use DNS to point to an EC2 instance, but for $0.55 including tax, it seemed like a pretty reasonable deal.

It was quite a learning experience to get this up and running, but you can now visit and sign up for our pilot!

As the pilot progresses, expect a few followup posts on how to implement multiple views in Meteor and how to use the HTML5 geolocation and vibration APIs!

I hope this has inspired you to think a little differently about just how far you want to go with your pilot. Got any questions or suggestions? Feel free to contact me via email or twitter

The Spectrum Project Final Update – From 0 to Queery


As my partner, Chelsea Hostetter, and I have reached the end of quarter 3, it is time to summarize what this time has meant for us and where we will be heading as we step into our final quarter at AC4D.

However, before we dive into that, some thanks and recognition is in order.


Firstly, to our participants, including the Transgender Education Network of Texas, the Central Texas Transgender Society, and PFLAG . You have been incredibly generous with your time and personal stories both triumphant and painful. Thank You.

To our classmates, who have provided both support and challenge via their critique. You’ve helped us to create a better design. Thank You.

To the professors of quarter 3, Matt Franks, Kijana Knight, and Jon Kolko. You have all been instrumental in helping us to make sense of the data and continuously refine our ideas into something greater than it was before. Thank You.

Finally, to our friends, family, and loved ones. You have been our design guinea pigs and our most ardent supporters. Thank You.

Previous posts

For handy reference, here is the history of our posts in chronological order:
Spectrum Project – First post
Spectrum Project – Update 2
Spectrum Project – Update 3
Spectrum Project – Update 4
Spectrum Project – Update 5
Spectrum Project – Update 6
Spectrum Project – Update 7

At the beginning of this quarter, we had 300 design ideas.

Although we had picked 3 to present for our final, our hearts were not set on any particular idea. Initially, we were leaning much more in the direction of either a comic book or a videogame as we are both quite interested in such things.  However, we carefully reevaluated our design ideas and tried to strike a balance between presumed impact, our passion for a particular idea, and feasibility given our skill sets.

Our first concept : A Birchbox for the trans* community

We ended up with our first idea, which was Clique. A Birchbox for the trans* and gender variant community. The was a high level concept which strived to create a space to grow mentors who would curate boxes of things they wish they would have had during the earlier stages of their transition.

We brought this idea to the class for critique.

We carefully wrote down what each of our classmates and Jon had to say and systematically walked through each of the points to see what we wished to address.

We reexamined why we wanted a box and what this all really meant for our community. Our next iteration on this concept was to ditch the box but carry forward two concepts, mentorship and curation.

We asked the community what they wanted to learn about and what they were willing to teach.

Our second concept : Mutual mentorship

What resulted was a concept called Three4Three. We democratized the mentorship concept so that everyone is a mentor. By sharing their strengths, each member could gain confidence while making new connections.

Speaking of connections, this is where our curation concept was carried forward. Instead of curating a box, we thought to curate the community instead. Most websites are open and free. They want to have as many users as possible to that they can receive more advertisement revenue. As such, they do not work particularly hard on removing negative users as that would cut into the bottom line.
Out of concern for our community, we intend the opposite. With particularly strict controls on who can enter, we create a safe, trans* positive environment.

We then brought this idea to our classmates.

Again we were brought some incredible challenges from our peers. We thought carefully about why we felt mentorship was so valuable. After some consideration, we landed on the concept that companionship was the most valuable aspect of the interaction. So we then decided to carry forward 2 concepts: a curated community and companionship.

Our third concept : Friendship and networking over coffee and a game

Coffeeroulette was our next concept. It simplified the meeting of two individuals so that instead of a teaching session, they would meet over coffee and a game.

It was also around this time that we started thinking that this would be a mobile application.

We printed out a series of scenarios with common user tasks and had members of the community try to imagine themselves in those scenarios.

What we learned was that overall, the concept was solid, but there are foundational trust issues which needed to be addressed. We refined our idea once more, and tried to reduce the concept to its most distilled form.

A fundamental question : Can we bring two random people together?

We had a fundamental question which needed to be answered: Can we bring two random people together for coffee?

The answer is yes, however there are some caveats. Fortune smiled upon us as our random pair happened to both be enthusiastic programmers. Most importantly though, was that they both had a friend in common. This mutual connection was the linchpin to the establishment of their fundamental trust.

It was after this test where the mechanics of our community growth were established.

A network of friends

For this concept to work, we needed to create a network of friends. So we decided that instead of allowing for a free-for-all registration system, we would be invite-only.  In particular, we recalled the invite-only, early beta trials of other social networks and realized that after a certain point, a few things happen:

1. The invites become commoditized.
2. Someone is a little careless with their invites and negativity increases.
3. At a certain size, the community is subjected to Eternal September.

We needed to control two critical issues; the flow rate of invites and the quality of who is invited. From this, our ratings system was born.

We recognize that invites are a form of social currency and that there will be pressure to give an invite to acquaintances. In these scenarios, people who are not particularly trans* friendly would normally gain access to our network and wreak havoc if left unchecked.

We ask our users to rate one another and the location where they met after every meeting. With enough negative ratings, not only is a user ejected from the system, but the person who invited them has their rating lowered as well. This, along with a per user invite cap, provides backpressure so that they think very carefully before handing out access.

Between our scenario and live tests, we proved that while a game wasn’t necessary, having a common subject does help start the conversation.

Our final concept

From this, Queery was born.

We then brought this concept back to our users via usability testing. The response was great and we rapidly refined our interface. With some fantastic help from Matt Franks, we ended up with a smooth application which allows users to schedule a meeting around their selected topic, find each other with a discreet signal, and rate the interaction.

On Saturday, Chelsea presented our refined concept to a crowd of designers, entrepreneurs, and AC4D professors. The presentation is available here. We received some wonderful compliments and some sage advice on where to go next regarding business models and technical strategy.

So what’s next?

Over the next quarter, Chelsea and I will be building this concept into a live demonstration application and we need your help!

We’re are looking for mentors in entrepreneurship as neither of us have a sturdy background in finance, marketing, or sales. On the technical front, we are currently leaning toward an HTML5 responsive mobile webapp. If you can find the time to impart some of your wisdom, perhaps over lunch or coffee, we’d love to hear from you!

The Spectrum Project Update 6 : Getting specific

Last week, my design partner Chelsea Hostetter introduced Scenario Validation, where we allow the user to read through and imagine particular uses of our application.

In particular, Chelsea highlighted the core of our application which we believe works well:

CoffeeRoulette’s best features include:

  • a curated community of trans*friendly folks, initially seeded by the alpha testers in the trans*community.
  • a no-hassle 45-minute timed meeting to meet with others (but not feel bad if your time runs out and you don’t want to meet them again)
  • a way of connecting others in a generally anonymous, one-on-one way to protect the privacy of individuals.

Having these fundamental concepts of the structure of our community and the ground rules of a time constrained meeting between anonymous participants, we were able to rapidly try various permutations of the meeting mechanics, continuously refining our concept along the way.

After a certain point though, if the design idea is to become real, you have to prune your options and make some lasting decisions.

With that said, we have landed in a pretty solid place and have decided that the way we would like to go is to ditch the games, focus on the trans* and gender variant community, and give people the most direct path from invite to first meeting.


After receiving a lot of feedback, we changed the name one more time. ‘Queery’ plays on two concepts, the primary one is that this is for a nonconforming community, the second being that so many of our participants have questions and would like to find some friends with whom they could explore these questions.

From the image above, you can see the first few screens a potential user would encounter. The very first is an email invitation from a current member.  We believe that this social vetting mechanism is a great way to keep the community safe and to keep the quality of the interactions high.  After clicking on the link, the user is sent to a web app (see via your smartphone for our inspiration) where the user is given a carousel of discussion topics. Most of the topics are rather broad and inclusive of the broader community, some are very specific to the trans* and gender variant community.

The user has to make 2 selections, create a password, then they are given an option to confirm the meeting. We decide the location and discussion companion, but the rest is driven by the user.

Our goal is to help introduce members of the community to one another in a safe manner. We hope that these meetings will help our members forge friendships and build out healthy, supportive social circles.

So how do we know this idea is useful for our community?

More testing!

Our mission this week is to complete a series of usability tests which allow our potential users to give us feedback on not only if the app feels easy to use, but also if is it useful for their needs.  Preliminary feedback is certainly looking good.

Would you like to help us test? It takes an average of 30 minutes, you’ll get free coffee, a sneak peek at our design, and the chance to help the community. Please email us at

The Spectrum Project Update 4 : CoffeeRoulette

As Chelsea and I mentioned in our previous post, we made a pivot to focus on getting strangers to come together over common interests. As we came to a consensus on our vision, we needed a way to externalize this and test it with participants. So we made the analog version of our ideal service:

Initially,  we had imagined a site where users could be matched based on their common interests and exchange their knowledge.  After receiving some feedback from the community, we decided that the stress associated with being a mentor as well as the number of steps between a user signing up and getting to their first meeting were unnecessary barriers.

We believe that at the core of this iteration there were some fundamental assumptions and issues which needed to be addressed. The initial interaction between two strangers can be harrowing, so how can we make that first meeting go more smoothly? Even more fundamental than that, can we get two strangers together for coffee?

So we tried it out! We grabbed some friends and participants and had them meet in a coffee shop. We recorded the session and took notes on the participants’ feelings of how they felt about how the meeting went and any shift in the feeling of trust they had in the other person before and after the meeting.

Two of the key takeaways from this test were that trust started high and remained high if both participants had a reliable third party to vet the relationship, and that the meetings, while pleasant, were lacking something. Our intuition guided both Chelsea and I to believe that what was missing was purpose. A common purpose can unify disparate groups and peoples. For our purpose(promoting safe relationships within the trans* and gender variant community), we chose to have our participants play games as they are lighthearted, social, and fun.

Games can be useful for so much more than idly passing time. But don’t take my word for it, Jane McGonigal, author of Reality is Broken, had this to say about what games do to build trust between strangers during her TED talk :

There is a lot of interesting research that shows that we like people better after we play a game with them, even if they have beaten us badly. … Playing a game together actually builds up bonds and trust and cooperation and we actually build stronger social relationships as a result.

With that in mind, Chelsea and I have decided to make a few tweaks to our design which take this into account. Instead of forcing users into mentorships which they may not feel comfortable with, while providing for a common purpose which builds trust, we are now having users select which games they would like to play.

We’d like to try this new idea out and have participants share with us their feelings on the experience. While we’re lining up participants for live testing, we are also looking for participants to join us in a group study where we share scenarios with you and get your feedback.

Following Chelsea’s storyboarding process, we have illustrated a few scenarios which we would like you to critique.

If you can donate an hour of your time, please email us at and we will contact you with a list of sessions to choose from.

Thanks for following our project and we hope to hear from you soon!

The Spectrum Project : Update 2 – In an ideal world…

As our project continues, Chelsea and I will be volleying back and forth with blog updates.

When we last left off, we presented Theory of Change and received some initial critiques.

We have refined the idea to give a more prominent role to mentors in the community, and have shifted the role of the box from ‘box of stuff’ to prompts for gaining experience in a skill.

As presented yesterday, Theory of Change is a community focused on improving in one particular aspect of their lives (in this case, beginning one’s transition) where we provide a curator/mentor to facilitate that change via prompts and tasks (the box). The users would participate in community discussion and constructive critique as they post photos, videos, and audio related to the prompts. The curator/mentor would guide the discussions and provide tactical feedback based on their expertise.

In an ideal world, curating a box would be a relatively uncomplicated task as the curator/mentor should have a fair concept of what beginners need. Users would have the guidance they need to get started, and a virtuous cycle would begin where the next generation of curator/mentors could be cultivated from the users as they gain confidence and experience.

Our critique session yesterday as well as some incredible feedback from one of our participants has brought about some interesting questions which I would like to pose to the trans* and gender variant community.

What mentors did you have during your transition?

Tell us about a specific moment that you really enjoyed with them.

What would an ideal mentor look like to you? What skills or personality traits would they possess?

If you could send a message to yourself at the beginning of your transition, what guidance would you give?

Please email us at with your answers. Your feedback is vital to our process.

IDSE201 – Final Revision of a Thermostat

Explore, Build, Test, Revise

The past 8 weeks have been a iterative exploration into the design of a thermostat, but the lessons learned along the way are much more varied than simply ‘do it again’.

By utilizing a process of exploration, user testing, and iterative development of wireframes, I was able to gain insight into how to made a useful product while projecting my own opinion of design into the world.

What follows is a listing of my lessons learned, with explanations of the process and tactics for receiving actionable feedback to drive product improvements.

Lesson 1: Explore what already exists

With any new project, having a starting point is important. Exploring the field to see what already exists can serve as a icon to aspire to, or a warning sign of what to avoid. In any product or service, tradeoffs have to be made. Seeing what was prioritized by others allow you to gain insight into their view of the world.

Lesson 2: Map it out

Making models allows you to visualize the organization and hierarchy of a system. It also allows you to project your own opinions and receive feedback before making a single screen. Above, you’ll notice the concept map of the Honeywell model, below is the original concept map of my ideal thermostat.

Lesson 3: Have an opinion

Having an opinion, well formed or otherwise, allows you to start. You can always change your mind later.  In the original concept model, I projected this concept of a thermostat as networked component, an instrument in the orchestra of a comfort control system. I also specifically split the interface between a central control located in proximity to the HVAC system and a mobile control which is in constant proximity to the user.

Lesson 4: Reduce the unnecessary 

This is more relevant in legacy systems which have built up extraneous features over time due to politics and scope creep, but distilling an idea down to its essence is, in my opinion, good design.  In the case of this thermostat, I view it as a means of controlling the comfort of the user. Every feature should be focused on maximizing the comfort of the user or be absolutely necessary for the proper functioning of the system.

Lesson 5: Build a thing

Until your concept is externalized, it avoids reality. The faster you can produce your first iteration, the sooner you will be able to expose and explore the difference between your ideals and what the real world expects.

One of the tools for rapid ideation are wireframes. These are medium fidelity illustrations which can be generated quickly, are easily editable, and give a reasonable amount of detail such that a feature can be developed by a software engineer without further explanation.

Lesson 6: The user is not like me

Thankfully, you don’t have to be an expert software engineer to build a prototype. Paper prototypes are cheap and fast to make (albeit slightly less than ecologically sound). Using these paper prototypes, and a list of actions which you wish the user to try, it becomes quite easy to know if your idea holds up against current cultural norms and expectations.

Lesson 7: Emotional resilience is a necessary skill for a good designer

Putting your ideas out in the world can be a very challenging task. To achieve an objective view of the quality of your work, you need to test your idea with strangers. The best method I’ve seen so far is to use a list of clearly defined tasks for the user and have them think aloud while attempting to achieve the defined tasks one at a time. Think-aloud testing allows you to quickly grasp if the user is understanding your system or if they are having trouble processing certain intermediate steps toward achieving their goal. Your ability to process this feedback from the user and use it to motivate change in your design is a critical factor to the success of your product.

Lesson 8: Try it again

Making revisions based on user feedback acquired via think-aloud testing with paper prototypes, allows you to build your way toward an ideal state without needing to have everything ironed out ahead of time. You can react to situations as they develop, like suddenly changing requirements, without scrapping the entirety of your product. Overall this method is a rock-solid way of articulating your vision and accommodating the user’s desires.


So how did my final revision stack up to my ideal? Let’s use what we’ve learned from Lesson 2 to find out:

If you compare this concept model versus the original ideal, you can see that I did not deviate too far. Having a clear vision of the technologies I wished to use and my philosophy of a thermostat as a user comfort system allowed me to focus on how to improve user flows rather than to explore (and likely get lost in) much larger ambiguous thoughts like whether to use a digital or analog interface, whether the device should be networked, and whether it should do more than control the HVAC system.

In summary, the method of explore, build, test, and revise is one which I am very comfortable with due to my background as a Software QA Engineer. This method of design maps very closely to Agile software development process and the expected outputs are rather similar. Rapidly developed, incremental changes based on real-world feedback, instead of large amounts of time in ‘the cave’ tend to result in higher quality products.

IDSE201 – Revision 6 of a thermostat


At the start of last class, Matt gave us two new requirements:

1. The device must be able to connect to the wireless network (or have a really good reason why not)

2. You need to prevent the user from breaking the A/C system by turning it on in the winter.

This late breaking shift in requirements is typically called ‘scope creep’ and can ruin an otherwise healthy project. Many times it involves deep changes as flows have to be completely redesigned to accommodate the new features and behaviors.

Much like the now infamous $1000 project, this was met with a mixed reaction. In my case however, I was fairly confident that I would be able to competently address the new requirements.

Expecting the unexpected…

When starting this class, I realized that I had two advantages :

1. I have over 6 years of QA Engineering experience which involved staring at interfaces, breaking flows, and exploring edge cases on a daily basis.

2. I sat in on the start of the Rapid Ideation class last year. I specifically asked about scope creep and how that was handled. Jon’s response last year made me sure that later in the quarter I was going to see a shift in requirements.

The third advantage which I didn’t realize I had was dumb luck. I love many of the concepts behind the Nest thermostat and home automation. As a technologist, I keep up to date with what technologies are being used by professionals and amateurs to make their homes more interactive. The MSP430, Arduino, RaspberryPi, Samsung TecTiles, Electric Imp, and many more technologies are adding connectivity and remote sensors at near-consumer prices. It was natural for me to look to wireless networking as a means of vastly improving home comfort.

In my original concept model, I explicitly thought of the role of a wireless network to allow for not only remote control via a mobile device, but also intelligent climate control via remote sensing and data.

Adding a means of connecting to a network was a necessary thought. In all honesty, I had thought that it would be hardwired since the control wires to the HVAC system would have to be run as well. However, since ‘connection’ existed and was abstract enough, it was easy to switch from hardwire to wireless without too much mental gymnastics.

So how does one manage a wireless connection?

Thankfully my system control flow had room for a one-line addition of ‘Connect to Wifi’ which would facilitate this small wizard. A list of available networks, sorted by signal strength, is presented to the user.


Expecting the unexpected of the unexpected…

What do you do when your wireless network is hidden or otherwise not listed? Time for some input.

Being thorough

So while the keyboard isn’t super pretty, it is functional. It allows for all manner of input except for non-English language sets.  However, the real thought goes into answering the question, “How many ways can this go wrong?”

Here are a few examples:

Some alternative cases worth pondering are if there are multiple networks with the same name, if there are multiple wall units in the same home, and how does the system handle brownouts or temporary power outages?

Having a dialog with the user

Sometimes you have to talk the user down from the ledge and help prevent them from doing harm to themselves.  In this particular instance, if the user were to turn on the A/C in cold weather, it would break the unit.

While this is very language-centric, there are few cues which drive home the point. By adding a notification at the top of the interface, the user can see this is an unusual condition. The red X makes it clear that what just happened is a no-no. Finally, the removal of color, my indicator of whether heating or cooling is occurring, makes it clear that the system is doing neither.

Final Thoughts

Overall this was a fun set of challenges. I wish I had more time to clean things up before today’s post, but rest assured everything will be addressed before the final presentation.

Here is the latest edition of my thermostat specification.


IDSE201 – Revision 5 of a thermostat

One more time…

Getting this far into the iterations, the work shifts from radical changes to polishing and refinement.  If you compare my previous specification to this current iteration, the two major changes you’ll notice are the addition of Scheduler flow screens and a special new addition, callouts…


The major improvement for this iteration is the addition of callouts. A callout is a way to drive the reader’s attention to a specific interaction so they know exactly which part of the interface you are referring to.

In the example above, I am making a generic tap on the screen to wake the unit from sleep mode.

While it may seem really simple, the addition of callouts to one’s specification allow for the designer to really take a step back and review their work.  Each time I added a callout, I asked myself the following questions, “Does this make sense?”, “Am I keeping the flow consistent, or am I making the user traverse the screen too much?”, “Would I want to tap this much to achieve this goal?”

Another fun thing to do after one has added callouts is to composite the screens.


By layering the screens on top of each other, a few things became obvious:

1. Red is annoying. I need to make the callout more neutral. My specification looks like a grammar school teacher was having a bad day.

2. I am doing the right thing. Notice how most of the arrows land in the middle of the screen? I am keeping the flow consistent and not causing a lot of screen traversal.

I expect a few more dramatic changes to occur as a twist has been thrown into the next assignment. Not only do we need to add Wifi support (already considered that if you look at my first concept map), but we also need to handle an exceptional state where if the house is too hot (like during a party), but it is in the winter months, the A/C system will break. How can we save the user from themselves?



IDSE201 – Revision 4 of a thermostat

As shown above, these are the revisions of the thermostat mentioned in my previous posts. I’d like to share my design process with you so that you can see how I got from flow diagram to interface and iterated on that interface.


The basis of our research was to explore a Honeywell thermostat and provide a flow diagram which displayed the possible user actions. This particular model of thermostat gave an incredible amount of precise control to the user and installer. What resulted is a bit of a “dragon’s tail” step-by-step wizard flow for installers.

A certain amount of abstraction is necessary for sanity and effective communication, so the ‘Installer Options’ wizard was simplified to a single node among the numerous menu options.


The first step after researching an existing system is to create your ideal version of the same system. In my case, many of the controls were dropped as I found them to be superfluous. I wanted a very stripped-down system where the user is presented with very few options. I also wanted an intelligent system which takes advantage of modern technologies.  These opinions are expressed via my ideal flow diagram.

I immediately thought to separate the controls into two systems. Ideally, I only wanted an Arduino in the wall with no accessible controls, but Professor Matt’s prevailing wisdom reminded me that some users occasionally lose their phones or forget them in inconvenient locations.

The mobile phone interface made a lot of sense to me as users almost always have them closer than the nearest thermostat control. Why not allow users the opportunity to control their thermostat remotely? Secondarily, the complexity of the schedule control in the Honeywell unit convinced me that it belongs in a phone where users are familiar with scheduling systems.

Ideally the system would also be able to calculate the efficiency of the home’s insulation (R factor) and use local weather data to predict necessary changes to the heating or cooling schedule.


After creating an idealized model, it was up to me to determine the interface I wanted to expose to the users. Initially I had wanted to present identical controls for the fan and temperature controls. A quick visual pass proved that using the same up and down arrows actually confused the users rather than provide a consistent feel. The red and blue arrows were also not entirely clear in their function. Lastly, the user did not have a clear enough indication that the system was reacting to their input. While I had wanted to obscure the temperature as I feel that users don’t care if it’s 70° or 72°, but rather if they are warm or cool enough; this ultimately only served to confuse the user.


For my next revision, I created clearly different controls for the temperature and fan. I also used hinting via partially obscured icons to give the user a feeling that other spaces were accessible if only they swiped the screen. This is a fairly modern interaction and it hasn’t entirely caught on. For this revision I also needed to move beyond my intuition and have some measurable means of ascertaining the usability of my system.  The tools I used for measurement are paper prototypes, think-aloud testing, and a SUS score.

Paper Prototypes

I created screens for the Hero Flows (ideal user actions) and a few common mistaken actions in Adobe Illustrator. I then printed out sheets of screens and cut them out individually.

I ended up with quite a few screens as I have two interfaces to test, both the wall unit and the mobile app.

Think-Aloud Testing

I needed to test this with users who were not familiar with my system. To remove any undue guidance, I used think-aloud testing where a participant receives no guidance other than a singular task from a list and simply blurts out their thoughts in a stream-of-consciousness style.  An example task would be “You are too cold. Change the temperature from 70° to 72° so that you are comfortable.”

Users would say many things like “Well, I guess I would click on the fan icon if I wanted to change the fan speed.” I would wait until they actually touched the paper, then I would present them with a new piece of paper which reflected their decision. All without saying a word. This unnerves a lot of people as they feel they are being tested as much if not more than the interface. To avoid unnecessary stress, it is always good to thoroughly preface the test with guidance and assurance.

A few techniques which worked very well for me were to start by telling the user that I ‘would like to play a game with them’ rather than asking something like, ‘Would you like to test my UI?’ This kept the atmosphere playful and light. I also told the user that they are welcome to quit at any time.  It’s important to give them an out. Present them with an example of an interaction by putting an interface in front of them and actually touching the paper yourself. I reassured them that if they have any difficulty it is because I made a mistake in the interface.

Two mistakes I made which you should try to avoid are to give overly positive feedback when a goal is achieved (because when they fail it will be more painful for them) and to explain the think-aloud process throughly. Let them know they will hear a prompt of “Please keep talking” if they fall silent for more than a couple seconds.

SUS Score

After the user completed the task list, I presented them with a sheet which allowed them to rate their experience. The questions alternated between positive and negative statements so they had to pay attention and could not provide a straight-column score without trashing the interface’s usability rating. There’s some slightly tricky arithmetic with this system, but the results speak for themselves. I received an average score of 87.916 which is quite reasonable.

In a larger company, the SUS Score is more conventionally used as a point of persuasion. Typically there is a before-and-after scoring to prove that usability improved in a measurable fashion.

Despite my high score, there were some fatal flaws. Some users could not understand the partially obscured icons or the notion of swiping between spaces. Other users did not appreciate the mix of icons and text as that makes internationalization and localization efforts more difficult and assumes a level of literacy on the part of the user.  The most fatal flaw however was the lack of a confirmation on the schedule flow. When a user completed the task of setting the new schedule, they would tap the home button on the interface which would leave the app instead of committing the change. A simple ‘Done’ button would alleviate that issue.


With this latest revision, I have made some considerable improvements.

Firstly, the icons are all in a fixed position which perfectly mirrors the wall interface. Learn how to use one, and you’ll know how to use the other. No more hinting or spaces. The user has every option available to them at all times.

The second most obvious change was to bring back the Schedule shortcut to the bottom of the interface. This is a nod to the genius of if you haven’t tried this out via a mobile device, do so now. You’ll thank me later. Their spring-up space for the ‘Next 7 Days’ forecast is a great way to expose a complex bit of information behind an unassuming control.

I also added a ‘Done’ button on the ‘Add Schedule’ flow to specifically guide the user to commit their change.

In the latest revision of my annotated wires, I specifically call out new animations on the icons to create fun moments of interaction as the user switches between controls. The thermostat fills from the bottom, the fan blows the other controls away, and the system control gear spins while sliding the other controls away.

While I am dying to get a demo spun up via Meteor, I have been told to hold off for one more week to clean up my specification a little more.

We’ll see if my willpower holds out over the Thanksgiving break…

In case I haven’t mentioned this before, please provide feedback via the comments or one of my numerous methods of contact. Thanks!