News and blog posts from our students and faculty

Category Archives: Startups

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 ‘getqueery.com’ seems pretty reasonable to me.

To get the name ‘getqueery.com’ 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 http://getqueery.com/ 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

Posted in Startups | Leave a comment

New Quarter, New Queery

Welcome to Quarter 4, everyone!

Alex and I last posted, Queery was a fully fleshed-out design concept that we presented to a panel of entrepreneurs and designers. The initial response we received was very positive, and overall, we’re pleased to see that Queery is resonating not only in the hearts of trans* folk, but in people who are interested in being allies to the trans* community.

As a reminder, Queery is an invite-only safe space for trans* and gender variant folks to discover their local community through face-to-face meetings. Queery aims to create a community around get-togethers and fuel connections through matching folks by common interest.

Where are we now?
For the past two weeks, Alex and I have been working on developing a pilot program that we can work with the community. We are looking to test out Queery with people who want to provide feedback on the service so that we can make it better. It’s one thing to test folks with paper prototypes, but another to test with a working website.

Below is a peek into the finalized wireframes for the Queery website.

Since we have started our piloting, Alex has been hard at work setting up an EC2 instance and a GitHub repository to make sure that we have all the development tools we need for future coding work. I’ve been working on making sure that we have all the pages and styling we need to match the wireframes.

Going forward, we are seriously thinking about our business plan and how Queery will sustain itself. Will we be receiving grants from LGBTQIA organizations for assistance, or will this be powered by its amazing users? We are hoping the latter.

Want to Help?
For any of you who identify as trans* or gender-variant, we would love your help in piloting Queery. Would you like to meet new people in the Austin area? We can set you up with one on one meetings with other folks based on interest. Please reach out to us at spectrumproject@ac4d.com if you are interested.

Posted in Methods, Startups | Leave a comment

BringUp selected for the 2nd round of the $50K Arch Grants Global Startup Competition

Although Will Mederski and I may have been in radio silence around AC4D recently, that doesn’t mean we haven’t continued to work on BringUp.

This past fall we got our software about 2/3rds complete with help from 2 students from MakerSquare. The automated parent signup process now works, and you’re welcome to try it out by texting the number  27  to 512-861-8455.

This winter, we submitted BringUp for the 3rd Annual St. Louis Arch Grants Global Startup Competition (www.archgrants.org) This organization provides $50K grants to about 20 companies willing to relocate their headquarters to the St. Louis area, along with lots of free accounting, marketing and legal assistance. It’s free money, no strings attached. Will and I are proud to announce that BringUp has made it to the 2nd round of the 2014 competition!

The 2nd round is a bit of a lighting round, as we had one week to prepare a 3 minute YouTube video, as well as an additional presentation. Luckily, Will and I were readily prepared from the work we did last year at AC4D. Creating this material on top of SXSW and a bad case of strep-throat was no problem at all. Please check out our video here: https://www.youtube.com/watch?v=v25N0fNBCCs

Posted in AC4D In The News, Social Innovation, Startups | Leave a comment

The Spectrum Project Update 7: Testing, Testing, 1, 2, 3…

As my design partner Alex explained in his blog post, from CoffeeRoulette was born Queery, a service exclusively for the trans* and gender variant community for pairing people together for safe, one-on-one interactions with one another within a curated community.

When we last left you, we were going to test our wireframes with users—so far, we have tested three users and plan to test another two users by Sunday, and write up a full report by then.

The response has been extremely encouraging. “Where were you six months ago when I moved to Austin!?” said one of our participants while pointing at our wireframes. “You need to make this, invent a time machine, and then give me it.”

Our preliminary tests have also unearthed some usability issues of our wireframes—the confirmation screen for the application after the meeting has been set is unclear, and some of the icons on our navigation bar were not clear enough to convey meaning.

We have since updated our wireframes to not include the navigation bar, and to instead, have an easy, one-at-a-time flow that prevents the user from doing too many things at once. In our new organization, we will have singular flows where a user sets up a meeting, has reminders for that meeting, and only until they complete a meeting and rate the meeting will they be able to set up a new meeting.

Additionally, Alex and I have started asking the hard questions in terms of edge cases:

  • What if someone feels uncomfortable or unsafe during the meeting, how can we stop it?
  • How will we be able to monetize this service to pay for itself and keep it going for the community?
  • How do we pitch this idea to coffee shops, and how do we get more coffee shops involved in trans*issues?
  • What happens if someone who is not supposed to receive an invite is sent an invite (through a mis-typed e-mail address, for example)?

Before our presentation next Saturday, we want to think about these questions and more while we continue to refine our wireframes this week.

We’re also getting fired up for our own reasons—because both Alex and I are cisgendered, we get asked a lot by others, “Why make an application for the trans* community when you are not trans* yourself?”

We will never be able to fully understand the struggles of someone who is going through transition. What I can understand is the anxiety I feel when I walk into a new place with new people, and now I am suddenly expected to walk around to everyone and introduce myself, with no knowledge of how the conversation is going to go. I can understand wanting to stay online with my friends, as I have done that for years and years, only meeting my internet friends once in a while if I had money. I can understand the pain and awkwardness of a conversation going south.

I get giddy thinking about the folks who we have talked to and who are interested meeting one another and hitting it off. I trust that with the right advisors and with the support of the trans* community, we will be able to build something that the community can take over from us and call it their own.

Again, Alex and I are continually thankful for the folks who have been testing our wireframes, providing us feedback, and guiding us on the way to Queery. We’ll see you for a final blog post next week.

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

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.

 

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

The Spectrum Project Update 5: Validating Assumptions

When we last left off, we had presented the first iteration of CoffeeRoulette—a service that helps forge friendships between two trans*friendly people over coffee and a game.

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.

This past week, we’ve been testing these features and more by using scenario validation. Scenario validation is a process by which we create multiple scenarios in which a (fictional) user would be using our application, along with screenshots of the application as they are using it.

Then, we give the users a feedback sheet asking questions to rate different statements about the application from 1-5 (where 1 is that they strongly agree with the statement, and 5 is that they strongly disagree with the statements). Statements can range from, “I feel like I can trust the people I meet through this application” to “I would like to use this application more in the future.”

We tested with folks inside and outside the trans*community—we felt that testing outside the community was important to validate our assumptions should we choose to expand our curated community from solely the trans* community. The responses we received were interesting and helpful. They ranged from:

“I really like the one on one aspect of this…I go to Meetups and it’s just hard to connect with one individual person.”

to

“Why isn’t this a dating app?”

It’s helpful to hear a validation of our design idea, and that, for the most part, we’ve been met with optimism and kindness. We also know how helpful it is to receive critical feedback on our idea to kickstart our thinking. We were provided that this Saturday when Alex presented our idea to a critical audience instead of a friendly one.

Some of the questions that were asked of us were, “How do we know that the games are in the coffee shop?” “What’s your business plan? How will you make money?” and “What if people steal the games?”

We had answers to some, and on others we had none. We knew our idea worked and people were interested in it, and it felt more “real” to us than ever before, but there are still more hurdles for us to jump before it becomes an actuality.

 This week, we’re working on incorporating the feedback, doing our last round of user testing, and finalizing our prototype in code. We’ll be taking in all of your feedback and making the idea more solid and more real.

Look forward to the next update, where we will have a more solid version of CoffeeRoulette to show you.

Posted in Methods, Startups | Leave a comment

Healthcare: A Proposal for Supporting Recovery

Over the last few months Jacob Rader, Bhavini Patel and Scott Gerlach have been studying healthcare.  Our research focused on the documents and records that patients interact with and how these artifacts affect their relationship with the medical industry as well as their understanding of their own health.  Through contextual, qualitative research we had the opportunity to learn from a wide variety of people and identify many opportunities for design to make an impact in the healthcare system.

 

 

Patients

In talking to patients in at-risk communities we encountered a disconnect between the quality of care that people have access to and their perception of that care.  Put simply, most people’s perception of healthcare is largely linked to the extent that their healthcare reaches out and meets them on their level.

Insight
Patients will not be proactive in their own care, they need the system to guide them and help them establish accountability.

Through our research we found that when healthcare was at its best was when patients were being proactively engaged by their healthcare provider; the provider would meet the patient on their level and would facilitate care for them.  Even in situations where the technical care was good, if the system didn’t reach out to them, patients didn’t feel as stable.  Whereas, people who have access to healthcare that addresses simple things like helping them schedule appointments and arrange transportation feel much more supported and cared for by their providers.

 

Professionals

On the other side of this we saw that healthcare professionals are stretched very thin, pulled by both the volume of patients they care for and the bureaucratic demands of their work.  Much of the time and energy that professionals have to expend is not directly perceived by patients.

Insight
Due to the technical nature of modern healthcare doctors have lost a common language for communicating with patients.

As modern medicine has developed it’s become increasingly complex and specialized forcing doctors and medical providers to develop a vernacular and understanding of the care their providing which is increasingly disconnected from their patients.  Additionally, most professionals’ technical workflows don’t lend themselves to an understanding of the patient’s experience of healthcare: so problem areas like confusing or conflicting documentation don’t get addressed and become an additional obstacle that patients must negotiate.

 

Good Communication

When the two previous insights are layered together, we start to understand why miscommunication and misunderstanding so often develop in medical care.  If we understand some of the factors driving poor communication between health actors, it becomes crucial to define what good health communication looks like.

Good health communication happens through interactions that meet the patient on their level.  It gives patients small, understandable pieces of information as well as the time needed to process them.  It gives patients actionable information and prompts when they need it.  Ultimately good health communication helps a patient build understanding while encouraging self reflection.

 

Supporting Patient Recovery

Our goal is to leverage interaction design to help extend more support and clarity to patients without demanding more time and energy from professionals that are already stretched to their limit.  In our research the most pronounced need for this sort of good health communication is in the transition from inpatient hospital care to outpatient recovery.

From the moment a patient enters the hospital, the hospital staff must be preparing for that patient’s departure.  The high-volume nature of the hospital along with the reality that so many individuals in the hospital have a part to play in the care of each patient means that there must be very clear goals that create some alignment between all the professionals.  Near the top of that list is ensuring that the patient can leave the hospital as soon as they are well enough to do so.  The consequence: as they are leaving a hospital’s care, patients receive a condensed burst of information about their recovery.

Many of the doctors and nurses who participated in our research reported that the majority of patients who call during recovery are asking redundant questions that had been addressed with the patient through written or verbal instructions prior to them leaving care.

Clearly, patients are not processing the information they are being given in a way that is relevant to their recovery.  This doesn’t just lead to confusion and redundant phone calls, it also leads to complications in recovery.  Patients don’t understand or adhere to the treatment plans that doctors have in mind for them.  They don’t heal properly, aggravating weakened areas which often forces them to be readmitted to the hospital.  This causes extra strain on an overloaded system.  Readmittance is a problem area that many hospitals are actively trying to problem solve, in part because of new guidelines in the Affordable Care Act.

 

Our Proposal

The current system overloads the patient with a deluge of technical information at a single moment.

We propose taking all the information and sending it to the patient in manageable pieces over time via text messages.

We see a system that reinforces the education that patients receive while in care with timely reminders after they return home. What might this look like:

Patient is informed about the text messaging program as they’re preparing to leave care.

The patient starts receiving texts while still in care and the messages continue after care at targeted times that corresponds to the patient’s recovery.

Weeks out of care and the patient is still receiving helpful recovery information and appointment reminders.

 

Impact

We believe that a system like this will help on a number of levels.  Firstly, it will connect patients with information at appropriate times in a formats they are more likely to digest and act on.  Secondly, it will reduce preventable complications and readmissions.  Finally, systems like this will encourage patients to think about their health on a more continuous basis and will help them feel more connected to their own health and the healthcare system.

Posted in Regulation, Social Innovation, Startups | Leave a comment

The Impact of Storytelling: An update on our design process around pregnancy, labor and delivery

James Lewis, Meghan Corbett and I are pushing ahead with our design idea around pregnancy, labor and delivery.  You can read our last update on the blog here.  Our design idea which is becoming a “thing,” is called Inner Circle: The Birth Plan for Everyone Else.  Our research last quarter pointed so strongly to our culture managing birth as a scary procedure that often needs intervention (get the baby out!!!) instead of a hard, long, completely do-able and natural process that our bodies are designed for. We were motivated to design towards the notion of making this concept more accessible to women.

We were so inspired by hearing women’s stories around their birth experiences; both good ones and not so great ones.   The women that had had great experiences felt so empowered and strong; that this experience had set a tone for their start of motherhood in such a powerful way.  The women that had less great experiences felt bowled over,  like the choices about their own birth experience were being made for them, around them, and not by them.

We’ve spent so much time processing and brainstorming what we could do to bridge this divide; how can we design to support women in having a more positive birth experience?  How can we translate the stories of the empowering experiences and offer some of the components that supported those women to women who may not otherwise have access to them?

Our last blog post detailed the intent and function of  Inner Circle: The Birth Plan for Everyone Else . We started out with the idea that women needed to be able to clearly delineate lines of communication to pull supportive people closer and keep the people that pull at them or need boundaries set kept further away during the labor process.   We started building the skeleton of the interface, called wireframes, last week and presented it in class in a formal presentation.  We’re now in the idea validation phase, where we are creating short scenarios of how a user might use our tool.  These scenarios will be accompanied by short storyboards to help accentuate the emotional value proposition of using our tool.   We’ll use these documents in user focus groups with pregnant or recent mothers to give them a good sense of what our tool does and we will use discussion questions to provocate ideas to further improve the concept.

The ask??!  Help us!  We need your story and your thoughts!  We have two testing sessions at AC4D this week: Thurs at 7pm and Sunday at noon.  Here’s a link to our doodle schedule if you’d like to sign up: 

Testing will take about an hour, and you’ll get a chance to connect with other women around your experience with this important issue.  And there will be snacks!

 

Posted in Startups | Leave a comment

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.”

and

“[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 james.lewis@austincenterfordesign.com

Posted in Reflection, 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?”

Hmpf.

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.

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