Systems of Sensemaking

In this quarter’s theory class, my research team – which includes Anna Krachey and Meghan Corbett – are looking at the authors writings and relating it back to our project Inner Circle. Inner Circle is an online app that helps pregnant women make a plan for family and friends detailing decisions around their upcoming birth.

This section’s writers discussed the relationships between creativity, strategy and design. To better understand these relationships we created a 2×2 grid to plot our interpretations of the author’s perspectives. Whether the authors were discussing business, artificial intelligence, or design, we saw a common theme: using frameworks for sensemaking. But what are the orientations of these proposed frameworks? We saw them on the following scales:

Flexible to Prescriptive: Were these frameworks flexible enough for users to ultimately change and co-create for their own purposes, or did they require users to follow certain steps in a prescriptive process?

Logical to Intuitive: Are the authors oriented towards a more logical, inductive form of sensemaking or do they see sensemaking are more personally intuitive, dynamic and personal?

These authors favor lateral thinking, and using systems which are highly logical in the grand scheme but allow for flexibility in tactics and execution.

“The goal of the strategy hierarchy remains valid — to ensure consistency up and down the organization. But this consistency is better derived from a clearly articulated strategic intent than from inflexibly applied top-down plans.” — Prahalad & Hamal

These authors deal with adapting robotics and artificial intelligence to make them more “human”, simulating skills of lateral thinking. For these systems to be successful it requires one to take emotion and thinking, and codify it.

[On the different perceptions of transitions in robots] “This suggests that realism or time taken to attain an expression might be a crucial factor in how the robot is perceived by human subjects.”  — Mike Blow

The authors are using or creating systemized methods to  categorize inherently ambiguous things such as aesthetics and abductive reasoning.

  • Pierce:  system uses logic, but it comes from an individuals own experience.
  • Mahlke is on the intuitive spectrum because he recognizes that humans project their own emotional sense onto an experience.

“It is true that the different elements of the hypothesis were in our minds before; but it is the idea of putting together what we had never before dreamed of putting together which flashes the new suggestion before our contemplation.”— Charles Pierce

Through a variety of frameworks and perspectives, these authors see sensemaking and problem solving as needing to be flexible as to adapt for the situation at hand. They also value using intuitive thinking, rather than solely inductive reasoning, when designers are solving problems.

“An engineer wants to test; test and measure. He’s been brought up this way and he’s unhappy if he can’t prove something. Whereas an industrial designer, with his Art School training, is entirely happy making judgements which are intuitive.” —Cross

Inner Circle: The birth plan for everyone else

Starting last October, Anna Krachey, Meghan Corbett and myself – James Lewis – began researching pregnancy and experiences surrounding birth. Through the research, iteration and prototyping phase we’ve come up with a product called Inner Circle: The Birth Plan for everyone else.

But, before I get into what the product is, let me tell you the story of how we got there first. We had read a New York Times article entitled “American Way of Birth, Costliest in the World” and were confounded by the following statistics:

  • Approximately 1 in 3 births are done by Cesarean Section.
  • The US has a high infant and maternal death rate for an industrialized nation.
  • The US is the most expensive place to give birth in the world. The second most expensive place is Switzerland, and on average it still costs half as less than it does here.

So we were curious – what is going on with pregnancy and birth today?


As we set off on our research, we spoke to numerous women who were pregnant or recently gave birth. They had a diverse array of experiences and backgrounds, but we came to the following conclusion: Our culture sees birth as a scary, out of control event that needs to be addressed as a procedure. With advances in medical technology, birth has moved away from the home and community and into hospitals. While there are many benefits to that movement, one of the negative impacts seems to be that birth is no longer a normal event that other women in the community witnessed and participated in. Women who are pregnant today have likely never seen childbirth in person, or even an accurate media depiction. Americans are typically shown a hyperbolized scene of a screaming, out of control woman yelling at her partner.

After speaking with pregnant women, a doula and doing secondary research our group came to see a more nuanced picture of labor and delivery. We wanted to design a product to enable women to focus on labor and delivery as a long, hard, completely do-able and natural process.



Looking back over our research we thought of the different women who had positive and negative birth experiences. We divided up these experiences across a spectrum between positive births; those that leave the mother feeling empowered by her birth, setting the tone for motherhood and negative births: where the experience often leaves the mother feeling bowled over – like she wasn’t in control and didn’t know what was happening.

We began to see a correlation between a positive birth experience and the level of assertiveness a woman expressed surrounding her pregnancy, and the labor and delivery of her child.

We spoke to a woman who had a homebirth for her first child. In getting things ready, her midwife recommended she write an email to her friends and family setting guidelines, boundaries and expectations for how they should interact with her during labor and delivery. She wrote out an email which she sent shortly before she gave birth that she kindly shared with us. In it, she said:

“We ask that everyone stay out of the house and possibly at a remote location… unless you have been specifically asked to be present.”


“I have put [my friend] in charge of keeping all close to us updated with text messages so that as we get close to the baby’s [arrival], people can make their way closer to the house.”

Inner Circle

Using what we saw from research and what we know as people with life experiences of our own, our group came up with Inner Circle: the birth plan for everyone else.

Inner Circle helps expectant mothers create a birth plan for her family and friends. It helps women make decisions about their own wishes and boundaries around their upcoming birth.

So how does Inner Circle do that? We’ve started designing the wireframes – which I like to think of as blueprints for a website or app – for our new product. We imagine the user to be a pregnant woman, who is probably in the second trimester of pregnancy. She’s gotten through the first trimester where there is a higher chance of miscarriage, and now she’s likely telling her family and friends.

The BASICS: We start off once the user has signed up for the service with a username and password, but hasn’t used the website yet. She sees a modal window, focusing her attention on five essential questions. In it’s essence, this is minimal plan she can send to her family and friends. However, what we really want is to get the basics down and out of the way. Then she can go explore some of the more thought provoking prompts our team came up with.

ORIENTATION: Once she answers the basic questions, she comes to a full screen. On it she she’s her name and a picture of herself if she’s chosen to upload one. This creates a sense of feeling that this is “her space.”

Since english speakers read left to right, the first thing she sees on the left hand side is her plan so far. On it are her answers and a prompt to explore the questions and prompts to her right under “Things to Consider.” She views some of the prompts with example quotes from other mothers. She clicks a button to answer one of the questions; In the example above it is “If you need anything during your last few weeks of pregnancy, who might be on call to help you? Select a few people »” EXPLORATION: The questions are paired with quotes from the mothers we spoke to during our research. These quotes serve a few purposes:

  • They help give context to the question.
  • They act as examples which let women compare and contrast to how they would answer a question.
  • They give social proof of women setting boundaries, showing you can be assertive and polite at the same time.
  • They reinforce the social spirit of the site: women helping other women through advice and ideas.


The user has clicked a button to answer a question presented on the last screen. Another modal window pops-up asking her to assign a few people close to her that she can call on for help. It also gives helpful suggestions, setting a friendly and helpful tone for the product.

COMPARING: After exploring questions under the categories of “Getting Ready”, “Labor & Delivery”, and “Baby Is Here”, the answers she’s given are shorted for brevity under “Your Plan So Far”. This gives her feedback of what she’s done, and allows her to compare it to the questions she hasn’t answered. Our goal isn’t to get women to answer every single question, but to compare and contrast the questions in a helpful manner which gives her pause to think but doesn’t overwhelm her.

While the user can click on any of her answers to make edits and changes, we included an “edit this plan” button at the bottom of the screen. This is because editing a document is a separate mental space from creating it. Changing questions before having to “commit” to them reinforces the goal of having her explore different options.


Shhhh… here’s a little secret! While this may change (these are only prototypes), the “edit your plan” and “schedule to send” buttons from the previous screen actually go to the same screen! Why is that? Because we want users to take this seriously – this isn’t a short text message to a friend, but a well thought out plan. During testing we often had users ask “I can edit this before I send it, right?” However, some users might not want to edit and are ready to send it out. We want to be explicit that users can send their plan without having to”edit” it if they don’t want to.

On this finalizing screen she sees her name and picture at the top of the page. All the instructions she’s written and questions she’s answered are laid out in full, in the same format her friends and family will receive it in.  She can change and edit her answers, and write an personalized introduction and conclusion to her letter. This part of our product is still in it’s infancy. We’re going to iterate and test out a few versions during the fourth quarter to make sure we get it right. When the user is finished with her plan, she clicks a button at the bottom of the screen to “select contacts & send.” Our team still has to take these wireframes to high level of fidelity, but this part of the flow will be where she adds her family and friends contact information and decides how and when she wants to send her plan.

– fin –

Well this has been a long blog post! Maybe you’ve scanned the headlines and images, or faithfully read the whole thing. Either way, what’s next for our group? In the fourth and final quarter of AC4D our group will pilot our product. This is like beta testing, putting our product in the hands of users. However, piloting is like pre-beta testing. The whole product may not be built out, there will still be bugs to work out and things to be re-designed. In essence, piloting is just another test as we iterate and refine Inner Circle.

One last thing! If any readers out there have experience with web development, especially with programming and databases, we could really use your help! Any advice, suggestions or time you might be able to donate would be a huge help to our group. Please drop me a line at or tweet me at @jamesLdesign.

Testing Timelines

Preface: I’m in a group with Meghan Corbett and Anna Krachey researching experiences around birth and labor & delivery. This post is the second in a series of updates on developing a product to serve pregnant women. You can read last week’s post here.

Last week our group worked on a timeline exercise tracking how women view milestones in their pregnancy – things like telling their best friends, notifying their job or certain medical appointments – rather than thinking just in terms of trimesters. We looked at each step and evaluated the value proposition, emotional value proposition and incentive / motivations for a woman using our app at each of her milestones.

The milestones we came up with were:

  • I’m Pregnant!
  • I’m Telling People (Close Family and Friends)
  • I’m Telling My Boss
  • Formalizing Plans
  • Labor & Delivery
  • I Have a Baby!

Using these milestones, we came up with a timeline exercise. We wanted to make sure we were thinking about these milestones, and how those events affect sharing information, the same way pregnant women were. In it, we asked women to map out:

  • Milestones during their pregnancy
  • When they told their best friends, their parents, and the rest of their social circle
  • When they informed their jobs, clients or anyone else dependent on them that they were pregnant.

We tried to keep things pretty open so women could make it their own. In addition to marking milestones, one participant also indicated her levels of stress regarding her pregnancy and how that related to what was going on in her life.

This week we spoke with a first time pregnant woman, a woman pregnant with her second child as well as a Doula. Our concept of milestones appeared to be correct. Yay!

During this time one of our participants shared an email she sent out to her family and close friends. She was planning a homebirth, and her email laid out what she wanted everyone to do, how to communicate with her and how they could help. Such gems included:

“Please resist any urges to bring things to the house, such as food or drinks, during labor. I may be very sensitive to smells and we also need to keep all of our space clean and clear.”


“[My husband] will be communicating to people if anything changes and we ask that feelings be spared if changes on the day affect you.”

This participant was clearly able to set boundaries and expectations so that she could get what she needed and her family felt like part of the team – even if they weren’t there. We realized, however, that many women may not be able to do this or even think to do it, and speaking with our Doula confirmed this. During our initial research phase we heard:

“I’m just going to go to the Hospital and see what happens.”

We wanted to come up with a system to set these boundaries and parameters, so that women could start mentally preparing as well as focus on their birth. We heard anxiety from some of our research participants like:

“My parents want so much to be helpful, but my father is obese and my mother has cancer. It becomes more about me managing them instead of them being helpful.”

The tests I wrote about earlier, as well at the email I just shared along with many sentiments about pregnant women dealing with family members resulted in our current design idea: InnerCircle – The Birth Plan for Everyone Else.

We’ll continue to develop and refine the idea, but here are the main premises:

  1. Women share different information with different people about their pregnancy. They need a way to manage all that information and the complex relationships surrounding it.
  2. Women also need a way to plan and articulate what they would like their family and friends to do during her labor & delivery. They shouldn’t have to worry about keeping their mother-in-law happy while they are trying to give birth to a baby!

We are currently doing user tests where we will validate these ideas and see how women to respond to writing out directions for those around them. We’ve also come up with a paper prototype test where we’ll have women create circles of people around them in the same way we are planning to do it in our app. We want to see how women pick and choose whom to put in their inner circle – those who are closer and get more information – and those they put in their outer one.

We are currently recruiting pregnant women and new mothers to help test our design idea. If you know of anyone who might be interested, please get in touch with me at

Thermostat User Interface Design Project Comes to a Close

This is the final installment of posts about the iterative design and user testing process I’ve conducted for designing a thermostat user interface (UI) – Read my last update about my latest redesign here.

Over the last eight weeks of IDSE201 Rapid Ideation and Creative Problem Solving I’ve been learning about how to ideate the design of a user interface by wireframes – in this case for a theoretical Thermostat design.

You May View the Full Set of Thermostat UI Interface Design Wireframes with Annotations Here

As a reminder wireframes are models for user interfaces (UIs) that lay out the features of a design – kind of like how blueprints work for buildings. They wireframes may look polished, but they don’t represent the final look of a design. Wireframes are for planning and figuring out how all the elements in a system are laid out. This lets designers like us test and iterate – or come up with multiple, refined versions – before we come up with a final layout.

During this process, I came up with two completely different designs before finally settling on my third. By going through the design process and then testing them, I was able to test my assumptions about how real users would actually interact with my system.

The main test method I used was think aloud testing. Think aloud testing involves paper prototypes, printed physical versions of the UI design,  showing them to a test subject and asking them to complete a task like raising the temperature. The user speaks aloud describing what they are doing and thinking in relation to the task. This is a quick and easy way to see if you’re design is functional and if the design assumptions you made were right – or wrong.

Going through user testing on my various designs, I learned a few things:

  • Users won’t be able to manage the same level of complexity in a system as a designer is able to. While this may sound obvious, after spending hours upon hours thinking and perfecting a design, it’s easy to make assumptions that a task or feature will be easy to use when it’s really not.
  • We’re not just really designing a thermostat. We’re learning how to think in systems, understanding how the parts and the whole relate to one another. We applied the same synthesis and sense-making skills we’ve learned in design research to simplify and iterate upon a user interface.
  • You need to design in flows, not screens. Early on in the process, I was focused on getting every little detail right. I neglected to think in Hero Flows – the sequence of steps a user might take to complete a typical task of the system.
  • Start with assumptions, then move to validation. Designers need to use their abductive reasoning skills and make assumptions when they first begin to prototype. Without doing so, there would be little creativity and originality in our work, and everything would probably end up looking the same. But while assumption is important in guiding our work, we still need to test it with users. Our designs still need to function within the mental model that guides users when completing a task.
You May View My Final Presentation Here

Adding Edge Cases to User Flows for Thermostat Wireframes

This is the latest installment of posts about the iterative design and user testing process I’ve conducted for designing a thermostat user interface (UI) – Read my last update about my latest redesign here.

A Twist! Professor Matt Franks, who has teaching our class wire-framing and iteration design skills, added a twist to our thermostat designs. Edge cases! What are edge cases you ask? Well, in designing our thermostat we created hero flows; hero flows are the ideal paths a user will take to achieve a goal. Hero flows are the main functions we as designers plan for. Through user testing we’ve learned that sometimes users don’t behave in the way we anticipate, and then we adjust accordingly.

But edge cases are those behaviors we don’t anticipate or plan for. Matt gave us the following edge case: what happens when it is very cold inside say 38°F and user sets the temperature to 68°F. But, say the user has a bunch of friends over for a party – hooray! But, uh oh, everyone starts dancing and the temperature rises to 76°F inside above what the heat was set for. Some users might just turn the temperature down – something we as budding interaction designers might plan for.

However, some users might turn the air conditioning on. They want it to get to a nice 68° quickly and don’t want to wait. That makes sense – thermostats are all about temperature regulation. BUT, turning on the air conditioning on when it’s 38°F would brake your air conditioning equipment. Rather than letting our user break the equipment, we need to add a check or balance to the system to prevent them from making a mistake.

I proposed this: Adding a warning message written in conversational language – not technical jaron or a confusing error code – letting the user know the consequences of their actions.

Warning message with suggestion to turn off the heat

I also wanted to add a prompt, asking the user if they would like to turn off the heat instead. This gives them context about what the system is doing and offers a solution to their problem. Clicking “Yes” would automatically turn off the heat without the user having to do it themselves. Clicking on “No” would revert the system back to it’s original state – in heating mode. Cooling mode is no longer an option, but the user will understand why rather than assume it’s broken.

Matt also asked us to add the ability of connecting our thermostat to a local WiFi network – a common feature among newer thermostats like the Nest.

The system tab has a WiFi sub tab added to the thermostat interface
The WiFi sub tab has a short series of screens to allow the user to easily select WiFi networks and type in a password

I designed the thermostat UI to be flexible enough to add sub sections to the respective system areas – or tabs – like the system, fan, temperature and schedule screens. To view all the annotated screens including the edge case and adding the WiFi screen, you may download the full PDF here.

What does she need? Driving design ideas directly from research participants

Oh the serendipity of an AC4D event! On Friday, after our school hosted a talk by Gary Chou – an AC4D mentor and professor of entrepreneurial design – I was speaking with classmate Alex Wykoff and Alumnus Eli Robinson. Eli is currently working as a design researcher and was telling Alex and I about a technique for developing design ideas. And it all comes down to what someone needs.

The idea is this: We go directly to the quotes from our research participants. We look at what they are saying and describe what we think that person needs to solve their problem. For example, one of our research participants told us that most teen fathers are involved with the mother during pregnancy and after birth, but a year later most are gone. Taking Eli’s provocation, I asked what do these teen fathers need? Well they need a way to learn emotional maturity! Need statement done :)

Participant quotes with need statements

Lets look at another example of a need statement that produced a design idea. We spoke to a research participant who told us about a teen mother who gave up her children so she could stay with an abusive boyfriend. Our participant remarked that many of the teen moms she serves have an abusive past and this teen in particular had “real attachment issues.” So what does this teen mother need? She needs a way to learn personal attachment – something she probably didn’t learn from her own family as a child.

“This teen mom needs a way to learn personal attachment”

Taking that need statement, we can develop design ideas for our future in school startup building a system, product or service. Sometimes the process might produce generic need statements or design ideas, but I’ve found if you push it and use an iterative process it can produce some good results. For example, if a teen needs to learn how to create personal attachments with people in her life – especially her baby – how can we create something that helps her do that?

Design ideas generated from a needs statement.

One design idea our group came up with was the “Family House.” A program after school that runs through the evening which creates a supportive family environment for teens who are pregnant or parents. By putting mentors in place, and facilitating group activities that are therapeutic, fun and encourage peer support, teens like the one from our needs statement example could learn how to form personal attachments. This would benefit her and her family in the short and long term.

I’ve added the last step of testing design ideas generated in this manner against the insight statements from our group research. In this case, the “Family House” meets both insights around teen pregnancy:

  1. “Taking care of babies forces teen mothers to learn to take care of themselves”
  2. “Having a role model and being responsible leads to resilient teens”

It’s important to look at design ideas from the frame of research insights, because those insights are what really drive our design process and the future startups our team will be working on next quarter.

Thermostat User Interface (UI) Testing

This is the latest installment of posts about the iterative design and user testing process I’ve conducted for designing a thermostat user interface (UI) – Read my last update about my latest redesign here.

One of the challenging aspects of conducting user testing for my thermostat UI has been recruiting test subjects. I’m new to Austin, don’t know many people outside AC4D, and I find walking up to strangers at a coffee shop painful (and often not successful.) So, with a little help from my friends I went along with fellow classmate Chelsea Hostetter to do some user testing at the University of Texas at Austin.  Chelsea and I each held up a sign on campus asking “Want Free Food? Help me test a design!” It was embarrassing but worked. UT undergrads are a curious bunch and many were enticed by the free donuts we provided.

I was using my thermostat designs from last week, which you may view in full here. The users were all able to complete the tasks I assigned them which were:

  • Change the temperature from 68°F to 72°F
  • Turn the system from heat to cool, and return home
  • Turn the fan off, and return home.
  • Set the schedule to 72°F every Sunday and Saturday
Users doing talk aloud testing on paper prototypes of my thermostat design

While I was psyched they could all complete the tasks, they typically did it in a manner differently from what I had anticipated. For example, when changing the system from heat to cool, users tapped on the “H” icon rather than swiping the system tab into the center.

While this worked for my second and third tasks, I ran into problems with the final task of setting the schedule: “Set the schedule to 72°F every Sunday and Saturday”

While the users understood how to set the schedule, I hadn’t anticipated all the different paths they could take to get there. For instance, they might have arrived on Sunday as the first screen on the schedule page, but their first action was to swipe to Saturday. That’s fine, except I didn’t have those mockups created! They eventually figured out the original flow I anticipated, but it was not the first path they wanted to try. Since I didn’t have all the screens available and it was pretty apparent I needed to, I finished testing early with only 3 of my 5 tests since I knew exactly what I needed to fix.

Secondly, I had thought after users created the schedule point on Sunday they would click the “copy” button to add the same point on Saturday.

However, the testers didn’t notice the text message and instead clicked on Saturday to set the same point. It might have involved more steps for them, but the option to copy the schedule point wasn’t in their mental model. I think instead this might be more of a feature for power users rather than the every day one.

Testers did respond to thermostat design as being easy to use; the touch interactions reminded them of an iPhone and they thought the language was easier to understand than their thermostats at home. One exception was referring to the temperature screen as “Home.” While it might function as the home screen, since it is never referred to as such in the design, it’s silly to ask users to return home during the tasks. I either need to tell them to return to the temperature screen or leave that part of the task out.

I have since come up with some subtle changes to the UI design on the scheduling screens. You may download those annotated wireframes here.

This week I plan on creating more screens to account for all the possible paths a user could take to complete the tasks I assign them. I’m excited with what I’ve come up with so far and feel like I have a strong design I can continue to develop.

Thermostat Version 3: Third Time is the Charm

This is the latest installment of posts about the iterative design and user testing process I’ve used for designing a thermostat user interface (UI). You may read my previous post here.

I have gone through major design changes throughout the process of designing my thermostat UI, and I think I’ve come to something I really like. My first version was too basic. The second version was much improved upon, but it revealed some issues in testing and I felt it was too influenced by the Apple iOS system interface.

One issue the last round of testing revealed was that the home screen where a user changes the temperature and the scheduling screen where a user can set the temperature at a specific date and time, looked way too similar.

While it was my intention to keep them similar – I wanted to keep a consistent look and feel so the user wouldn’t be confused – my plan backfired. During user testing a user got to the future temperature screen (as seen on the right in the image above) and thought they had returned to the home screen. They commented: “It says done.. but i didn’t make the temperature change — I’m getting frustrated cause I don’t know what I’ve done .. as the temperature didn’t change.”

Scheduling seems to have proved the most difficult out of all the features for both myself and many of my classmates. It’s no wonder – scheduling has many functions which have to be set, while other tasks like manually changing the temperature or switching from heating to cooling are much simpler.

I also wanted to come up with a consistent action or motion that could be applied throughout my thermostat interface. While sketching I came up with a different UI that I really liked. Actions, like changing the temperature or navigating between different functions were completed by swiping right or left. The main home screen, where a user manually manipulates the temperature is below.

 You may view the full annotated wireframes here.

Creating the scheduling function was more complicated. I was inspired by a dial on the radio, tuning into your selection. But rather than turning, the motion was swiping. You align up your day and time, and then click on a stationary “+” symbol to add a new scheduling point. Once you click the check box, you can copy that scheduling point and set it to multiple days – which was something I did in previous versions of my thermostat. An animated hero flow – the ideal flow a user would take – of the scheduling function is in an animated gif below.

Because I started from scratch, I didn’t have a chance to test this version. However, I put a lot of work into this and made some significant strides. You’ll hear all about testing next week!

The fine line of privacy in design research

I’m currently conducting qualitative research on how socioeconomics affects pregnancy experiences and birth plan choices with my partners Anna Krachey and Meghan Corbett. Our research participants tend to fall into two categories: pregnant women and the public health professionals who serve them – both directly and indirectly.

The public health professionals are comfortable, talking for ages about pregnant women and sexual health education. Their information and experiences are invaluable. Since they do this for a living they can usually talk about the subjects freely with little concern for their personal privacy. While we don’t publish names or faces, a few of them have told me I could do so if I liked.

Conversely, and not surprisingly, the pregnant women I’ve spoken with are often very concerned with privacy. The more difficult or unfortunate their experiences, the less comfortable they feel sharing their stories or having any photos taken – even if the photos don’t include their face.

Originally I was going to write this blog post about one of our research participants. She had already had a child and then had tubal ligation – that means getting your “tubes tied” so you can’t get pregnant. Unfortunately, the procedure failed and she became pregnant unexpectedly.

I wanted to share her story with my perspective on how the medical system failed her. But the more I wrote, the more protective of her I felt. To meaningfully tell her story, I would have to reveal details about her life. While I wouldn’t publish her name or personally identifiable information, I kept thinking – what if she looked me up and found this post? Would she feel betrayed or hurt?

She did agree to participate in the research, and I was clear that I would present her story anonymously.  But aside from a name and photo, the lines can become blurry – at least for me at this point in time.  If this were design research for a consumer products company and my research participant told me why she hated her cell phone service, I wouldn’t care about sharing her sentiments. Revealing the anonymous stories she shared would likely have little to no consequences or emotional impact on her.

But when it’s about the conflicted feelings she has over an unplanned pregnancy – which could result in a baby – it’s a different story. These are real lives and intimate experiences that I have a great responsibility as a researcher to protect. What if I make a mistake, sharing something a little too specific to her individual experience? What if someone close to her puts two and two together and discovers information not meant for their eyes or ears?

While it’s highly unlikely, even next to impossible, it’s still a concern I have. Sharing someone’s story can spur change and help build support for the eventual product or service my team and I builds – which will hopefully help serve women with unplanned pregnancies like my research participant. That said, I’m still figuring out how to walk that line of privacy as I continue with my research.

Thermostat Version 2: Out with the old and in with the new

This is a continuation from my work on re-designing the interface of a thermostat. You can learn about that and what wireframes are, on my previous post.

After getting stuck with my first ideation of a thermostat interface design, my professor Matt Franks helped me work on sketching the main features of a flow, rather than a whole screen.

Taking it to the whiteboard, I came up with these options:

I decided to focus on my second iteration with a slider to manipulate the temperature. When I took it digital in illustrator, I decided to move from a traditional slider – which goes up and down and stays in the position where you left it – a modified toggle slider hybrid. The idea being:

1. A basic user could tap an up or down arrow to move the temperature +/- 1 degree.
2. A power user could use a two finger touch interaction to hold and then slide the toggle to rapidly move the temperature up and down.

Below is a flow for changing the temperature. You may view all my screens here on google docs.

I also worked on screens for turning the system on and off, switching between heating and cooling modes.

I also did a scheduling wizard which my testing showed needed a lot of work. For the sake of brevity (and my own pride) I won’t go too far in depth on it. Basically I realized after using an iphone every day I integrated a lot of their design solutions into my UI, especially in the scheduling. In testing younger users familiar with smart phones were able to decipher the process quickly – however, when a technologically less savy middle aged user tried to create schedule she got stuck in the middle and failed.

In trying to keep things simple I made setting a scheduled temperature almost exactly the same as setting the current temperature on the home screen. This was a fatal flaw and something I will be addressing this week.