Testing Our Concept through Scenario Validation

When we last left off, we illustrated how we used the power of storytelling to elaborate on our design idea Inner Circle: the Birth Plan for Everyone Else— a smartphone app that guides expectant mothers through a series of questions regarding their impending birth, empowering them to have authority over their birth experience.

Over the weekend, our group tested some of the features of Inner Circle through a user-testing method called scenario validation. Scenario validation acts as a litmus test for whether the intended features and functions of our application are viewed as needed and useful by our intended audience. To do this, we create multiple short stories with accompanying visuals in which a fictional user would use our application to help solve a specific problem at a specific time. These sketches contained the minimal flows needed to communicate the feature in order to test the idea.

To validate the concepts, we held one group session with a total of 4 expectant and recent mothers, some who had hospital births, and some who had homebirths. We read aloud one scenario and had participants fill out questionnaires about each scenario. We then held a group discussion with participants about the features and usefulness of this tool and how they had perceived it.

As we expected, this type of concept validation proved to be invaluable. The feedback we received about the core concept was overwhelmingly positive:

“I think [Inner Circle] would be helpful for somebody with their first pregnancy. It seems to ask questions that I wouldn’t even think to ask. It feels like it really fills a void.”

“There’s something nice about having a birth plan for everyone else. It’s something that’s needed and I didn’t know that I needed it.”

“Every pregnant friend that I had, I would tell them, this would go into the package they need to prepare for their birth.”

Most importantly, scenario validation allowed us to see what features might need a clearer value proposition:

“I don’t think it would be that difficult to just send two different emails. I don’t know if I need an app to facilitate that for me.”

The discussion and feedback from participants informed us that a tool that creates communication hierarchy should be secondary to a tool that provocates the creation of a birth plan for friends and family.

This week, our team will be concentrating on constructing the wireframes which prompts the user to answer questions related to the planning of their birth–the location, people involved, communication boundaries, and tasks which need to be delegated. This feature will be complimented by the communication hierarchies which will disseminate information to the appropriate people–all people will receive opt-in links to tasks such as food prep whereas other people will also be able to volunteer to pick up an older child from school (inner circle only).

At the same time, we will be reviewing previously conducted research with mothers to make sure our design addresses the issues they wished they had known to prepare for. Our goal is to present this information in creating a birth plan for future mothers in their planning stages so that they know what to expect and will be feel more confident and assured entering into motherhood.

“This empowers you to be the boss lady, which is an important way to feel going into becoming a mother.”

Look for another update within the week. As always, if you have any thoughts about Inner Circle, please don’t hesitate to comment here or email me at meghan.corbett@ac4d.com.


Our Continuing Adventures at AmbiguityC4D: Q3 Progress Report Post 1

It has been a month since we presented our research, top insights, and the three design ideas at our final presentation for quarter 2. Since then, our group has been trying to settle on one idea to push forward to wireframe and test with.

This has proven to be harder than we had anticipated.

To get to the three ideas we presented at end of quarter 2, we used a 2×2 matrix to evaluate which ideas we felt passionate about against which seemed feasible. Daddy Doula, My Birth Coach, and the Doula Marketplace each originated from the intersection of high passion and feasibility, but were all so amorphous as to what they could do that we weren’t able to settle on one over another.

We revisited our insights and thought a lot about what we saw as the goals of our final idea.

On Wednesday, we made a breakthrough and came up with this idea:

The Peach Project is tool that enables the user to share information about her pregnancy journey with curated communities of her choice, while building a visual history and journey of her pregnancy experience. Through provocation, this platform will prompt her to externalize and articulate her feelings and then share them with her chosen community and the peach community at large.  Sharing tacit knowledge and stories also allows for feedback, support, and empathy from others, strengthening the mother to be’s feeling of confidence around her impending birth experience.

We finally felt we were on the right track and were pretty amped up about the numerous possibilities when we met with Matt Wednesday night. He pointed out to us that while certain aspects of the idea hit home, once again we were trying to incorporate too many features into one product. “What does this platform really do?”


Yes, ideas are free. But ideas that we were excited about seemed to be few and far between. We were spinning our wheels on the same thought avenues time and time again. We needed a new framework to view our research through.

Jon suggested we chart out a few main phases of pregnancy and then think through the value proposition, emotional value proposition, and incentive for each of our participants through this framework. For example, we thought about Lily’s experience with pregnancy and asked “what was she probably thinking when she first found out?”, “what about when she started to tell people?”.


This exercise was immensely helpful in getting us out of our rut. It enabled us to really understand the changing needs of soon-to-be parents throughout pregnancy and what specific areas are most stressful/have the biggest area of opportunity. While each phase includes a certain amount of stress, finalizing plans and the actual labor and delivery periods stood out as an especially tricky time.

From there, we zoned in on these two goals for our idea:

  • The mother-to-be feels connected to and supported by her chosen network of friends and family by assigning communication responsibilities to her closest friends
  • Soon-to-parents are able to easily create boundaries around communication with wider circle friends and family, enabling the mother to better focus on the process of labor and delivery.

One of the provocations for this design idea is that historically, women were supported through their pregnancy and birth experience by a network of women relatives and friends. The introduction of hospitals into the birth process has led to a deterioration of this system. The internet allows us to use social media as a way to manifest a new kind of support connection. Although this connection is crucial, the ability to create boundaries with family and friends is equally important in being able to focus on the labor and delivery process.

Inner Circle will help mitigate the overstepping of boundaries by friends and relatives who mean well but cause anxiety to the mother by being overeager or over-communicative.  Minimizing these distractions and concerns will allow the mother to better focus on the hard and long task at hand.The app will also act as a tool to delegate and manage tasks such as child and/or dog care easily and clearly, further allowing peace of mind and focus.

We are now in a user-testing phase, meeting with participants and verifying that our assumptions about the usefulness and incentives we saw for this new idea are correct before we start wireframing possible manifestations of this idea.

If you have any thoughts about Inner Circle, please don’t hesitate to comment here or email me at meghan.corbett@ac4d.com.

Ideal Thermostat- Iteration #6: Final Iteration and Reflection

After eight weeks of Rapid Ideation and Creative Problem Solving, the sixth and final iteration of my ideal thermostat is complete. Last week, we were given the additional requirements of two extra tasks for our fifth iteration and I came incredibly close to an error free round of user testing. The only problem arose when users were prompted to delete a schedule. Every user I tested wanted to select the schedule first before tapping the delete icon.

Please follow along in the full PDF version of iteration 6 here.

After sketching out a few iterations of the delete schedule flow, I realized that a great interface is often flexible in that there is more than one way for users to complete a certain task. If some users want to tap on the schedule to select it before deleting, maybe I should incorporate delete into the edit mode. This solution seems so obvious to me now that I can’t believe I hadn’t realized it before. I was trying so hard to stick with the button conventions I created that I had forgotten to consider what would make sense to the user.

Re-listening to the audio recordings of my think-aloud user testing participants from last round, I heard one user ask, “what does the arrow on the schedule mean?”. While I was unable to answer her question while she tried to complete the tasks, it was a great question. The arrow was a remnant of functionality from an earlier iteration where users could skip ahead in the schedule. It no longer has any use as a stationary selection indicator, but I chose to keep it as a second indicator of the active schedule. This seemingly minor design detail had a large impact on the way the user viewed the capabilities of the system. I easily corrected this mistake by getting rid of the arrows.

Thinking about it now, I think this oversight highlights a flaw in my approach iteratively designing redesigning this thermostat. As designers, we have to realize that every design decision can portray unintended functionality if we don’t consider conventions already in place. In this case, the arrow still represented a stationary selection indicator that users.

So how did the user testing go this time?

Unfortunately, I did not have an error-free round of user testing, but I did learn a few more things that has altered the way I view my thermostat framework:

  1. Users appreciated that they could delete a schedule two different ways. Many initially deleted the schedule through the new editing mode delete option but noticed that there seemed to be another way to delete as indicated by the trash icon on the main schedule mode screen. Two users even asked to attempt the task again so they could experience this alternative flow.
  2. In this round of testing, two users interpreted the task “turn the fan on for two hours” as needing to enter schedule mode since the fan is on for a certain amount of time. Honestly, I think they had a good point. If every other function on manual mode stays activated until turned off, why wouldn’t the fan on manual mode work the same way? Timed usage of the fan would fit the users mental model better if it were included in schedule mode instead.


In this final blog post I would like to consider the evolution of my ideal thermostat by comparing the final design to the ideal thermostat concept model I created before I had even started designing the interface:

Just a few weeks ago, the vision I had for my ideal thermostat was simply a reduction of unnecessary features included in the Honeywell thermostat’s current concept and the addition of smart scheduling capabilities and an energy efficiency indicator. Let’s compare that first iteration of the concept map against one of the final design:

Clearly my understanding of the necessary components of an ideal thermostat has changed immensely over this iterative process. When I started this process, I was worried that I didn’t know enough about the way a thermostat worked and it prevented me from confidently designing an ideal thermostat concept map that was more than just a simplification of the Honeywell design.

This class has forced me to realize that certain rules such as universally conventions (green for okay/yes button) should be followed, but other “standard practices” should not constrict us. I can now think more critically about what I want in a design and not worry about whether it already exists or if other people would like it, because I have the skill set to test it and iterate on it. I have also realized that a poor user-testing round should not be looked at as a failure but as an opportunity pinpoint what worked and what needs more sketching to solve.

Ideal Thermostat – Iteration #5: Design Details

Last week, I posted the fourth iteration of my ideal thermostat interface in which I aimed to give users a better understanding of what the system was accomplishing through visual indicators. I also made changes to my schedule mode which showed a huge improvement in user testing when it came to adding and deleting schedules but I now realized that I had designed two different interactions based on the same action of tapping a schedule—entering edit mode and selecting a schedule to delete. This is a problem because the system would not be able to determine which action the user intended to do. I decided to rework the flow so that users would tap the trash icon to enter into a delete mode, similar to the way they tap the add icon to enter add mode…

…then the user taps on the schedule the want to delete…

…and confirms that they want to delete the indicated schedule.

View the full PDF of annotated wireframes here.

Think aloud user testing of the previous iteration indicated that the difference between the auto and on setting for the fan setting was not clear. I realized that I was trying to inform users of the fact that the fan activates when heating or cooling is needed. While this is true, it is not necessary for the user to understand this technical reality. I have since eliminated the auto fan icon, so that the fan’s functionality matches the user’s mental model; turning on the fan is used to manually circulate air for a period of time.

Lastly, I realized that too many users seemed confused about which days of the week were selected in the add schedule menu so I filled in the circles of selected days.

Adding new tasks

Up until the last iteration, we have been creating the core functionality of our ideal thermostat meaning that we did not have to create flows for tasks that users would interact with infrequently. Now that we have worked through the basic functions, we have been given two new tasks to set-up the necessary technical considerations that allow the basic functions to work properly.

  1. Allow the user to connect to a wireless network or enter the date and time necessary for the scheduler to work
  2. Prevent the user from being able to turn on the A/C during the winter, which would break the system.

Keeping with the simple nature of my thermostat, I decided that a connection to a wireless network would be unnecessary since no functions require it. Instead, the first time a user enters schedule mode, they are prompted to manually enter the time and date. This allows the schedule mode to function off this information. Once the user input the date and time, the settings icon is pointed out should they need to change the time or date.

To address the users that try to turn on the air conditioning in the winter, I added a modal that will pop up to alert users that cooling could break their A/C unit.

So how did the user testing go this time?

For this round of user testing, I approached people at Mozart’s. I discovered a few things this round:

  1. Users had no problem navigating the new fan functionality. They would tap the fan and then tap to add more time until the desired amount of time was displayed. This seems to better fit user’s mental model like I suspected.
  2. Problems arose when users were prompted to delete a schedule. Every user I tested wanted to select the schedule first before tapping the delete icon. One user told me she viewed the colored schedule as in a selected state. It seems like I may be sending unintended signals to the user.

I will have to think long and hard about how to address the issues with deleting a schedule and how to indicate which schedule is active without it looking selected. However, if I can fix that, I think the next round of think aloud testing could be error-free!

Ideal Thermostat – Iteration #4: Simplifying the Design

Last week’s iteration of my ideal thermostat interface included an overhaul in the way I thought about scheduling. In my previous iterations, I had always considered the schedule as a menu you could enter. Last week I made scheduling a mode you could toggle between; manual mode or schedule mode. The idea behind this was that you could switch over to manual mode if you didn’t want the system to change on it’s own or switch to schedule mode if you wanted to input a schedule that the thermostat would follow. This design decision eliminated the need for a hold button or a vacation mode since manual mode could accomplish the same goals.

While the new manual mode was well accepted by users during another round of think-aloud user testing, the functionality I had envisioned for the schedule mode proved to be overly complicated. After talking it over with Matt, I decided that the ability to skip ahead in the schedule was an unnecessary feature, which made my job to design a bit easier.

Now let’s delve into this week’s iterationview the full PDF of annotated wireframes here.

As with the previous iteration, the temperature is displayed front and center. I have made one significant change to the layout though. I eliminated the option to turn off the fan, because as Matt so helpfully pointed out, you cannot heat or cool your home if the fan is off. The fan is the method through which the heating or cooling is achieved. This conversation highlighted a gap in understanding I had about the way a thermostat functions and showed me that I need to do more preliminary research before I design. Luckily, this change was an easy one to make.

I also reconsidered the functionality of the dashed circle that appeared around an icon when selected. Instead of using it as a visual indicator that the system understood the user’s command, it now indicates when the heating or cooling is currently running. The fan uses the same visual indicator since as I mentioned, you cannot heat or cool without the fan.

Thermostat Off Screen

My conversation with Matt also made me realize that there was no need for a physical toggle to turn of the thermostat since turning the airflow off would disable the fan as well. To make the icon more clear, I decided to use the word “OFF”.

To fix the issues I had with users not knowing the schedule can scroll, I reconfigured it so the screen cuts through some of the content.

So how did the user testing go this time?

For this round of user testing, I approached unsuspecting victims at Dominican Joe’s off South Congress. I learned a few things this round:

  1. A user mentioned should be some indication that the temperature will “hold” in manual mode because it seemed unclear. Thinking about it now, I’m not sure if I agree but I will consider whether it should be part of a first time user experience introduction.
  2. Now that there are only two fan options, it is not as apparent what the difference is between the fan being on or automatic. I need to make this difference clear or get rid of one of the two.

I am feeling really good about the progress I have made with this interface. Yes, there are still some issues, but overall, I feel like I am getting better responses and encountering fewer issues during user testing. I’m sure developing more tasks will bring up a whole new set of issues, but I am more confident that I can handle them by trusting this iterative process.

Ideal Thermostat – Iteration #3: Fixing Functionality

Last week you saw the second iteration of my ideal thermostat. I had reworked the scheduling interface, adjusted the aesthetics of the entire layout, and had become excited with the idea of adding a home and away toggle so the thermostat could more easily adapt the inconsistent schedules many of us have.

While I made great strides in the scheduling interfaces, I hadn’t made enough adjustments to the home screen icons to make them understandable. Many of my user testing participants struggled to locate which of the three icons they needed to touch to perform simple tasks like switching between heating and cooling mode.

This week I addressed these issue head on. During my discussion with Matt, it became clear that scheduling stuck out since it’s functionality was so different from the toggle menus of the icons around it. I integrated my idea of the away and home toggle switch with the scheduling so that there were two separate screens on the thermostat that could be switched between; manual mode and scheduling mode. This left much more room on the screen to visualize each option of the system and fan settings.

Annotated wireframes of this iteration can be found here.

This new manual mode screen proved to be very understandable during think aloud user testing. However, I seem to have back tracked in my new concept for the schedule mode screen.  Once again I feel like my tasks may have been poorly worded, but more likely my design implementation was flawed.

Users have not been fully understand the time and temperature pairing as I visualized it. This became especially clear when I asked them to skip ahead to a temperature setting that was scheduled for later in the day. I don’t think they understood why you would want to skip ahead. I think having the time prominently displayed on the left threw off users. The visual style of the blocks also does not indicate it’s scroll-ability which is something I will need to work on.

Back to the drawing board!

Ideal Thermostat – Iteration #2

This week I am living the saying “one step forward, two steps back.”

Since last week’s iteration of the thermostat, I have been searching for a way to solve the problems I encountered during think aloud user testing, the biggest of which was issues understanding the scheduling interface. I also tried to make the current state of the system mode, fan, and scheduling understandable at a glance by adding text under the icon.

View my full annotated thermostat wireframes iteration 2 here.

Results Think Aloud Testing Iteration 2:

  1. The added current state text on the system mode, fan, and scheduling actually added even more confusion as to what the icon would do. Many participants believed that the icons represented the only options available.
  2. I decided to switch from a visual schedule to temperature and time pairs, which was well received during my think aloud testing.
  3. The physical switch to turn off the entire thermostat is being overlooked by participants. Most look for a on/off switch on the screen first.

I have been thinking hard about what people’s schedules look like. While many people work 9 to 5, a shift away from this kind of work schedule is trending. More and more people work from home or have inconsistent work hours. Current thermostat scheduling, assumes that users know ahead of time when they will leave for work or go to bed and that it will be consistently the same. Even a learning thermostat like the Nest would have a hard time learning one person’s constantly changing schedule, let alone a whole family. Shouldn’t our technology evolve take into account the lifestyles we actually live?

With that concept in mind, I have decided to add a home and away toggle. The user would set what they want the away temperature to be in scheduling preferences. Then, just a simple touch of the toggle before leaving would change the temperature to that preset preference and override any schedule that was in place until the user returned home. People with a regular routine still have the option of creating a schedule so that thermostat would be set to a preferred temperature when they wake up, during the day, or sleeping, but they would also benefit from the ability to easily switch to away mode on those rare occasions that their schedule changed.

I obviously need to correct the issues I am having with the system mode, fan, and routine scheduling, but I am most excited to work through this home/away setting and create a task for that over the next week.


Ideal Thermostat – Iteration #1

As I mentioned in my last post, we are redesigning a Honeywell Thermostat in our Rapid Ideation and Creative Problem Solving class this quarter. This week, I referred back to the concept models I created, and built out wireframes for my ideal model interface.  Wireframes are visual guides for the framework of an interface. They allow a designer to test for usability before all the color schemes and font choices are finalized.

The Honeywell thermostat interface incorporated many functions that were buried deeply into the system—you had to click through many different screens to navigate to these options. The category titles gave little indication of what settings or preferences they contained. This focus on incorporating technology must have taken priority over the main utility of a thermostat to heat or cool a home since adjusting the temperature pop-ups up an unexpected amount holding options.

Concept mapping this current state of the Honeywell thermostat and all its complexity allowed me to pinpoint the need for a simpler hero flow (meaning that there should be less obstacles to navigate through to get to your desired end goal such as turning off the system or setting a schedule). I started to consider what functions a typical user would want to perform. After many hours sketching and digitizing wireframes, I have come to this interface:

View my full wireframe PDF here.

This new interface prominently displays the temperature front and center since it will be interacted with most often. In the corners, I placed a few other important functions—current temperature, heating/cooling, fan, and schedule so they are easily accessible.

Ideal Thermostat v1 Home Screen

Both the system mode options and fan options are accessible by touching the their icon. A toggle menu then appears around it. After 3 seconds of user inactivity, the toggle menu disappears to keep the home screen clean and tidy.

Ideal Thermostat v1 Fan Options MenuOnce the wireframes were created, I needed to test the functionality with real people. Overall, the test went rather well. Through my user testing I have been able to identify some problem areas that need to be addressed.

1.     One user viewed the icons I have chosen to represent the system mode (air waves) and fan as togglers between heating mode and cooling. Another user identified the schedule icon as a calculator. The simple solution would be to add text under these icons to give the user a better idea of what they do, but I am going to explore other symbol options first. I like the aesthetic of having as little text showing on the home screen, as necessary but functionality will win out if there is no workable alternative.

2.     Displaying both individual days of the week buttons as well as shortcut weekdays and weekend buttons in the same organizational scheme did not seem to be as big of an issue as I expected it to be. One user did want to chose both the weekdays button and individual days though, so I will need to reassess they way those options are presented.

3.     Editing the schedule is not as intuitive as I hoped although the wording of my prompt may have added to the confusion. Even with the directions above the schedule, users jumped right to touching the addition symbol beneath the schedule, thinking it would increase the temperature.

Receiving real user feedback was probably my favorite part of this process. It gives me a better idea of the usability issues that were not apparent to me because I was too close to the design. Now that I have this first round of user testing under my belt, I feel like a have a clear idea of what works in my design and what doesn’t.

On to the next iteration!

Gaining Understanding Through Concept Mapping

Our Rapid Ideation and Creative Problem Solving class this quarter will be centered around learning creative problem solving methods through redesigning the Honeywell Prestige Thermostat… six times.
Before we can redesign this overly complex system, however, we must understand the current system as is.  One way to do this is by visualizing the content and functionalities of the system in a single diagram called a concept model. This concept map details the main sections of the inferface as well as the hierarchical relationships between sections and features. In the process of creating this model, I tried to simplify multiple screens while still capturing the depth of the whole experience. Here’s the concept model I created of the current system:

It is clear that Honeywell has incorporated many advanced functions into this thermostat. While this may attract some advanced users, I believe these additional features  would not be used by the majority of users who primarily interested in comfortably and efficiently heating or cooling their home. A thermostat used to be a relatively simple device. You could adjust your home’s temperature, toggle between off, cool, and heat mode, and turn your fan on, off, or to auto. As time has gone on, thermostats have been designed to incorporate new functionalities that seem like a good idea conceptually, but fall short in their understanding of the typical user experience. Who wants to stand at their thermostat for more than a few seconds at a time?
Reflecting on the typical user experience, I believe an ideal thermostat would have ease of use as a secondary goal. The following ideal state concept model resulted:

This simplification of the existing system refocuses attention back to its intended primary goal: heating and cooling the home. As a secondary goal, my redesign emphasizes energy efficiency through an indicator on the home screen, so that users adjust to be more environmentally friendly and save money at the same time.
This ideal concept model will be continually revised as we receive feedback from our user testing, but it provides a framework to create wireframes from.

The True Value of this Entrepreneurial Assignment

Pet Prints has kept me quite busy these last few weeks. In this update, I want to share few takeaways I have realized through my iterations of this project.

Don’t assume you know what your target market wants. Gather information in person.

It is easy to fall back on social networking sites like Facebook and Reddit as a way to gauge interest about a new idea, however, it is one thing to say you would buy something from behind the screen of a computer, and another to follow through with a real purchase. This information also tends often viewed through a positive bias as it is clear how many people responded with interest but it is unclear what ratio those people represent in terms of how many people saw it but did not feel strongly about the idea presented.

This is precisely what happened to me when I posted my custom prints idea on Reddit and received 30 upvotes. Without context of how many people saw the post, 30 votes of agreement don’t indicate whether my idea is liked by many or very few, but I read into it as a well-like concept and pushed on without a second thought.

Next time my approach will change to seek out my target market in context to observe them and more ask pointed questions so I can better critique my concept.

View your business from the customer’s standpoint.

As I mentioned in my second post, the ordering process I originally set-forth on my facebook page was difficult to navigate and relied heavily on the customer to reach out to me through email to place an order. This leaves too much ambiguity for the customer to sort through and could easily cause them to lose interest. By looking at this process from the view of my customer, it became clear that I needed a platform where products could be viewed and purchased on the same website. The increase in sales seem to indicate that this change to a new website was a positive one.

Ask your target market what they would pay for your product. Adjust quality and time spent accordingly.

Price point is important. If you set the price point too high, you lose a share of your potential target market who now can’t afford the product or view it as not being worth the amount of money. By gathering information straight from your target audience, you can better structure your business to meet the demand. In my case, I decided to offer digital downloads of my pet prints for less money. Customers can purchase the file itself and do whatever they see fit with image, whether that be printing it themselves or using it as their computer background. This product type ends up being more affordable to customers on a budget as well as less work for me.

Build time in for mistakes.

You are going to fail a few times before you get it right. I was so afraid to make decisions about this project early on, because I didn’t want to make a mistake. Looking back on it, I have realized that the best thing you can do when given a project out of your comfort zone is to just jump in knowing you will make at least a few mistakes along the way, but that the mistakes are part of the process. An efficient use of time and using the right tactics to solve a problem are critical to any business, but both of these skills come with experience. I need to be confident that any experience will shape my strategy positively, even if the experience itself could have been approached better. By building in time for mistakes, it takes the pressure off.

Reflecting on it now, the lessons I have learned from this project are exponentially more valuable than the money earned through my business. I’m guessing that is what Matt, Pat, and Jon hoped we would glean from this experience.