Meghan is an empathetic animal lover and people person that recently moved to Austin from Spring, Texas. She loves children, the Sims, and anything tropical. At a young age, Meghan asked for a box of 96 Crayola crayons—you know, the mega box every kid wanted—for Christmas and then proceeded to color code the entire box… for three years in a row. As Meghan got older, her passion for art grew, along with her Catholic faith. Through her work with her church’s children’s religious education program, she realized her desire to make a difference in peoples’ lives.

Pursing her vague ambition to combine art and philanthropy, Meghan attended the University of Notre Dame where she was formally introduced to the world of design. Several client-sponsored projects have sparked an insatiable desire to improve everyday experiences through graphic and industrial design. It is Meghan’s view that you do not have to be older and experienced to change the world. She hopes that AC4D will help her do just that.

Meghan’s inner child frequently runs wild, howling at the moon and lounging on cushy surfaces. In her free time, she enjoys Redditing, binge-watching TV series on Netflix, reading, cooking, and exploring Austin with her wonderful boyfriend, Cory.


Recent Blog Posts


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


Posted in Design Research, Methods, Startups | Leave a comment

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

Posted in Classes, Design Research, Methods, Reflection, Social Innovation, Startups | Leave a comment

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.

Posted in Classes, Interaction Design | Leave a comment

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!

Posted in Classes, Interaction Design | Leave a comment