SitterHub is an iOS app that I developed during my User Experience Design class at General Assembly. The app allows working parents to find and book last-minute babysitters, and relies on reviews and ratings from each user's social media connections to recommend reliable caregivers nearby. The app solution was based on a thorough interview- and survey-based investigation into the lack of easy ways for working parents to find backup childcare.
The Problem Many working parents living in New York have a problem finding reliable, last-minute childcare when their child is too sick to go to school; their regular sitter calls in sick; or something else comes up unexpectedly. These parents often rely on calling or texting friends and neighbors, desperately trying to find someone to take care of their child so they can get to work. Sometimes they find a last-minute childcare solution, but often they end up having to take a sick day and stay home from work.
Hypothesis Statement I believe that working parents need to be able to quickly find reliable, trustworthy babysitters that live nearby and are recommended by other local mom/dad friends who they know and trust. I’ll know I’m right if I see parents using the app to find and hire sitters, and sitters posting their profiles on the app.
User Research - Survey
I designed a survey about finding last-minute childcare, and asked my friends on Facebook and my neighborhood listserv to take it. As an incentive, I offered to buy every survey-taker a beer, and 83 people took my survey. Here are some key stats that i discovered:
92% are women 69% are between 36 and 45 92% live with spouse or partner 90% have 1 or 2 kids 88% have kids 2-7 years old 86% work full-time away from home 89% rely on regular babysitter or daycare
Here are a couple of screenshots from the survey results from Survey Monkey:
User Interviews and Survey Quotes
I conducted six user interviews with working moms and dads. Each family’s work/life situation is a little bit different, but virtually everyone I spoke with shared their frustration with the lack of a good system in place for finding quality childcare in a pinch. These parents said they often resort to texting, emailing, or calling a handful of friends or neighbors, hoping to find someone to care for their child so they can get to work. Between the survey and the interviews, the main concern that was expressed by the users was trust: they want to be able to find a last-minute caregiver they can trust, based on recommendations from close friends and neighbors. These were some actual quotes i got from my interviews and the survey.
During the competitive analysis, I analyzed these three babysitter-finding products: care.com urbansitter.com sittercity.com
These apps/websites provide the user with a service to find a babysitter, and are geared more toward long-term babysitting situations (like full-time or part-time, recurring jobs). As a result, the user has to tap their way through several screens, filtering out many options based on several criteria. This is time-consuming and tedious when someone just needs a babysitter for a day. Also, although the sitters that are listed in these apps have reviews (like Yelp), the people who wrote the reviews are strangers to the user which is a problem (unknown person = no trust). Finally, these products require a monthly subscription ranging from $15 to $39 per month which was too expensive for people who occasionally need a back-up babysitter.
In order to solve this problem for our users, my product would have Facebook integration and leverage the users’ own social media connections to make babysitter recommendations. My mobile app would also need to be as simple and efficient to use as possible, because the users are pressed for time when they are interacting with it.
Based on all my research from the survey and user interviews, I created my persona, Margaret, in order to help me visualize my app's main user, her habits, motivations, and needs.
Minimum Viable Product
In order to start mapping out the main user flow, I sketched out the happy path of a user searching for, finding, and booking a babysitter.
User Flow - happy path
After looking at the first user flow with my classmates, it became clear that there were additional screens and tasks that needed to be considered, so I quickly sketched out a second version. This one included features like email confirmation, a user's profile and other screens related with a hamburger menu.
User Flow - Happy Path
Based on the survey results, user interviews, and competitive analysis, I developed a user flow for the “happy path” of looking for and hiring a babysitter. This flow assumes the user is already logged in (skipping the on boarding process), and has already created a user profile with credit card information for making payments through the app.
With the user flow in place, I created the site map for both the working parents (looking to hire a babysitter) and the babysitters looking for a job. A third leg of the flow includes the hamburger menu with options for posting a job, creating a profile, saving bank information, looking at the user’s social network connections, and other related tasks.
Once I had a site map planned out, I was able to start sketching out the key screens and features. I scanned these drawings and brought them into the POP app for a quick test, in order to see gaps in functionality and flow.
Lo-fi prototype - Round 2
I shared the first round of lo-fi prototypes with my classmates and friends, and there were many features that were still needed. So I sketched out a second batch of prototypes, and this time fleshed out several new screens. This particular flow is for a parent looking for, and booking a babysitter through the app.
Lo-fi prototype - Additional screens
These are some of the screens that would be needed as part of the hamburger menu.
My next step was to create medium-fidelity wireframes, and add annotations to help identify each feature’s functionality and behavior. In thinking about the user, it was important to keep the features and gestures as simple as possible in order to help the user complete their task as quickly as possible.
Visual mock-up - Round 1
This was the first version of the visual mock-up, and I struggled to come up with a good color scheme that would appeal to working women (most of the users), but not be too girly. My testers didn’t like the colors either, so I had to go back to the drawing board.
Visual mock-up - Round 2
For the second round of visual mockups, I tweaked the colors, added some photos and transparent overlays, and simplified the calendar based on feedback from people who tested my earlier prototype. I also fleshed out a couple more screens to bring more of the app to life.
After staring at the home screen for a while, I decided it was too fussy and needed to be simplified. So I changed it up a bit, and also renamed the app Sitter Hub (instead of SitterNYC, which was too location-specific).
For the usability testing, I got 7 friends to test my app and give me feedback. I asked each person to complete tasks such as searching and booking a sitter, updating their profile, looking for help. It was fascinating to find out that some of my assumptions were wrong, and some interesting patterns emerged:
Delightful things easy to use, efficient, intuitive Facebook friend integration very popular babysitter intro video
Painful things calendar too fussy- simplify pay rates - show more options or a slider how to confirm if sitter is available? need some way to interact with sitter before booking concern with paying ahead of time
The usability testing provided me with some great feedback for the app’s next iteration. Nearly everyone objected to only being given 3 options for the babysitter’s hourly pay rate. My testers also didn’t like the idea of having to book a sitter without first getting in touch with her ahead of time, nor did they like having to pay her fee ahead of time. Here is a visual summary of the changes that need to be made in the next round.
Commuter Pal is an digital product concept I helped develop at the Empathy Jam hackathon, which focused on coming up with digital solutions to problems affecting New York City residents. Check out the a re-cap of the whole research and design process below.
On Sunday, August 20, 2016 I attended the Empathy Jam hackathon, presented by the UX Lab meetup, and hosted at General Assembly in New York. It was a super fun experience, and I am grateful to organizers and sponsors for putting together such a great event.
I was especially interested in participating because, unlike other hackathons whose focus is on coding and programming skills, the Empathy Jam was a "research and design event that brings NYC's residents and government together to collaborate on new ways to feel connected, supported, and excited about creating our city's future."
The Challenge "How might we use technology to improve the experience of living in a city by creating new ways for people to connect with one another?"
The challenge posed to the participants was narrowed down by asking people to think of solutions that fit in one of three categories:
The event kicked off with introductions from the event's organizers Shannon Copfer and Meaghan Nishiyamaof The UX Lab, who got us excited to put on our problem-solving hats.
Sonya Bentovich of Sachs Insights then gave us a great presentation on user research, with some super helpful advice on how to frame questions in an open-ended, judgment-free way.
I teamed up with Allison, Lexi, and Boya to tackle the day's challenge. We spent some time writing down as many ideas as we could come up with individually, in an effort to start giving shape to our problem and solution.
We discussed several potential problems that NYC residents face... here are a few:
-lack of public bathrooms -safety in parks and public spaces -lack of adequate bike lanes -piles garbage and bad smells in the streets -lack of green spaces in many parts of the city -rats -housing prices in outer boroughs getting too expensive for the working and creative classes -too much car and truck traffic in Manhattan -public transportation woes: total gridlock when there is a sick passenger during rush hour... now easy way to know what is happening with train delays... poor sound quality in train loudspeakers (and no visual way to communicate live updates for people with hearing problems)
After a spirited discussion, we decided to focus on figuring out a solution related to the city's public transportation system, which affects hundreds of thousands of people every day.
One of the best parts of this hackathon was getting outside for an hour and talking to people. We went to the Union Square greenmarket and found many people who were very interested in talking with us about their experiences using the NYC transit system.
We spent about one-and-a-half hours interviewing people. Young couples, tourists from France and the UK, long-time New York residents of all ages. Here are some of the questions we posed to people:
-Tell us about your experience with using the subways and/or buses in New York
-What are some of your challenges/pain points with using the city's public transportation system?
-If you had a magic wand and could change one thing in the transit system, what would it be?
Between the four of us, our team interviewed 15 people and got some great insights into how the transportation system could be made better. My favorite interview was with Stewart, who was running the Brooklyn Brewery stand at the farmers' market: not only did he answer our questions while tending to customers, he offered us some free beer! After our last interview, we headed back to General Assembly to continue our project.
After the user interviews, we worked together to digest the data we collected. We wrote user insights on post-it notes, and created an affinity map grouping similar answers together. Some of the most common complaints with the transportation system include:
-Train delays - no way to know what's happening when you are on the platform or in the train
-Platforms are too hot in the summer
-Platforms are unsafe and anyone can be pushed into the tracks
-Poor sound quality in train announcement intercom systems
-No way to know when next train is coming
-Weekend train service disruptions
-Subway system is not stroller/wheelchair friendly
-Need WiFi in more stations
Based on our user interviews, the biggest problem people have when using the public transit system is the lack of real-time information about their train/bus, especially when there is a delay or problem. We defined the problem, and came up with a solution that would make using the city's trains and buses a better experience for New York City residents and visitors.
Our proposed solution included two parts:
1. A mobile app of real-time transit alerts and suggestions of alternate routes
2. Digital signs at all subway station entrances indicating whether the trains are running on time or with delays. Additional digital signs at the platform level (located over the turnstiles, or someplace that would be visible to people BEFORE going through the turnstile)
Mobile App User Flow:
For the mobile app, we sketched out two different user flows:
1. The user's first-time on-boarding experience of logging in and saving their typical commute from home to work.
2. The user's happy path of getting an alert that their usual train or bus is delayed, and being given alternate route suggestions.
We hustled to sketch out some key screens for the happy path. The first screen shows an alert that would pop on the user's phone, indicating there is a delay with the user's favorite train/bus line. The user would then swipe or tap to get further information, and be taken to the screen that suggests alternate route options. When one of the new options is selected, a map would show the user how to get to the alternate station.
With our paper prototypes in hand, we headed back outside to find more people that would be willing to test our app concept and tell us what they thought about the app's various features and functionality. We got a lot of great feedback, and went back to work on reiterating on our prototype.
One thing we learned, for example, was that we should not be using the acronym ETA because not everyone knew that it meant "estimated time of arrival". Another finding was that people wanted the app to offer them alternate route options in an efficient and minimal way, without needing a prompt from the user.
We also started throwing out name ideas for our app, in an effort to come up with something short, clear, and related to commuting. We were in a rush to get ready for the presentation, and settled on Commuter Pal. If this app progresses from a concept to a real, viable product, we would most likely revisit the name and do some A/B testing to land on something better.
We also designed some renderings of the digital signs at the subway entrances and platforms. This helped to create a visual representation of our product's physical component, which we believe would be critical in making the public transportation system a better experience for millions of people.
During the presentation portion of the event, we had 5 minutes to pitch our product in front of the other teams and judges. Some people seemed very relaxed and confident during their presentations, and I aspire to be better at this!
Here is a batch of rough UI mockups of some of the key screens.
This is a stab at the app's logo design, and more refined visual mockups of two screens. Much more work is needed in refining the UI for these screens.
In these two renderings, we aimed to show our concept for having digital signs at the subway entrance showing real-time train status information. The idea behind these digital signs is that they would save commuters from having to go all the way down into the subway platform, pay the fare, and then discover too late that their train is stuck in traffic or re-routed. This would save the commuters time and money, and give them a little bit more of a sense of control in choosing a different way to get to their destination.
Everyone we spoke to during our user interviews said they would love to know about train delays before going through the turnstiles, so we envisioned real-time digital signs indicating the trains' status at both the street and platform levels.
Here are a couple of screenshots from our team's PowerPoint presentation to the group, which outline our key research and usability findings, and list of next steps.
I really enjoyed watching all of the teams' pitches, and was super-impressed by everyone's innovative ideas for making New York a better, more connected city. I hope some of the more promising and feasible ideas will be made possible through financial support and entrepreneurship.
I'm grateful to the UX Lab and General Assembly for putting together such an interesting event for us to flex our user experience research, design, empathy, and teamwork muscles. A big thanks, also, to the event's partners: Urban-X, InVision, Civic Hall, and TEKsystems.
I look forward to the next Empathy Jam!
Code Buddy App - Hackathon Project
Code Buddy is an app concept I helped develop with my hackathon team, at the Women in Tech Demo Days Hackathon as a digital solution to help young girls become interested in coding and computers in a fun, game-like format. Check out a re-cap of the hackathon and my team's design process, below. Our team was selected as one of three finalists!
I was looking for ways to flex my UX/UI muscles, and made a last-minute decision to attend the Women in Tech Demo Days hackathon organized by AngelHack and sponsored by Capital One.
This was my first hackathon, and I didn't have a project developed or a team put together. I just registered and showed up at the Capital One Labs at 9 am, hoping to find other stragglers to join up with.
Here is an outline of the hackathon's challenge, benefitting the non-profit Girls Who Code:
Step 1: Help inspire more girls to learn coding by creating a solution (app or website) that enables girls to imagine themselves as computer scientists
Step 2: Demo your project in front of prominent industry leaders
Step 3: Walk away with a $10K General Assembly scholarship for your team plus the $15K for Girls Who Code (non-profit partner).
Most of the people at the hackathon were already teamed up, but a few of us without teams gravitated toward each other and decided to join forces. Each of us had a different idea for a project, so we decided to talk through all the ideas and vote on the best solution.
We also chatted with representatives from Capital One, AngelHack, and Girls Who Code, and got some insightful feedback that helped us narrow our product's focus a bit.
We didn't have a lot of time to do research, but learned quite a bit from the Girls Who Code website. According to their website:
"Tech jobs are among the fastest growing in the country, yet girls are being left behind. While interest in computer science ebbs over time, the biggest drop off happens between the ages of 13-17."
According to Girls Who Code, 66% of girls ages 6-12 are interested/enrolled in computing programs. That number drops to 32% for girls ages 13-17, and only 4% for college freshmen girls.
Based on this data, we decided to focus our efforts on a product that would appeal to girls around 12-17 years old, right about the time that they tend to lose interest in computing.
I put my empathy cap on, and thought about the typical teen girl and what are some of her motivations: friendships, fashion sense, fitting in at school, having cool gadgets, and figuring out who she is. She is a social being who likes playing games on a mobile phone or tablet. Most likely she would not be motivated to learn to code in isolation in front of a laptop/desktop away from friends who are doing fun things. She is busy with school, sports or extracurricular events, and hanging out with friends. Any app we developed would be competing for her attention.
My idea for this product was to create an interactive avatar that would teach girls the basics of computer programming in a visual way. I had originally envisioned it as a desktop web application, but we decided to design it for mobile devices first.
It was important to keep it simple and interactive, and I used some sticky notes to plot out the app's MVP. We had about two hours to put together our whole pitch and presentation.
Our goal was to make this tool fun, easy and appealing to girls. The onboarding experience would let the user customize her avatar and teach her about basic programming concepts (objects, properties, variables, functions, loops, etc.) along the way.
For example, the user would choose an avatar type (object), customize her skin, hair, and eyes (id property), customize her clothes and accessories (class property), and choose an activity for her avatar (function).
We would have to have some killer animation with the avatar for maximum appeal! The user would be able to control the avatar's actions (walk, dance, jump, lie down, eat, etc.), and see the corresponding code.
The lessons could build up over time to prompt the user to string together code for different combinations of actions. We also thought it would be great to hand out rewards such as new accessories and clothes for the avatar whenever the user feeds some code to the app.
For our pitch, I quickly grabbed some visual inspiration of teen clipart off the web to show the kind of visual choices that would be offered to the user to customize their avatar. For our own product, we would commission original illustrations of different body types, skin tones, hair and eye colors, outfits and accessories.
Here is a progression of the designs I made for the app's logo
My team mate Angel put together the PowerPoint presentation for our pitch.
We brainstormed a bit about next steps for the app, if it was going to be actually developed. In addition to expanding to Android devices, we thought it would be cool to forge some partnerships and be able to reward the app's users some free learning resources and tech prizes.
Our judges were Jessamine Bartley-Matthews and Jeff Stern (Girls Who Code), Leah Ginsberg (Women@Forbes), and Julie Elberfeld (Capital One). There were 14 teams competing for the top prize. Each team had 3 minutes to do their pitch, and 2 minutes to answer questions from the judges.
Here is my humble-brag moment. Most of other teams had worked on their product for a week or two already. We spent maybe 4 hours on refining our idea and developing our pitch. So we were pleasantly surprised when we were selected as one of the three finalists!
Here we are with the judges, and the other two finalist teams.
We didn't win the grand prize, but we had a great time and made some new friends. We are also going get a write-up on Forbes.com (our surprise prize!)
About the project As part of the tablet team, I was responsible for the design, production, and testing of print content adapted into 10-inch and 7-inch tablet devices (iPad, Kindle Fire, Nook). Our goal was to make the app fun and easy to read, and include extra "tablet-only" content.
My teammates and I designed interactive features such as object states, slideshows, scrolling areas, hot spots, video, and stop-motion animations. We also created templates and style guides for maximum efficiency and consistency among the team.
Each month, we had to take the print content and design it for 10-inch and 7-inch devices, which have different aspect ratios (and thus do not scale proportionally).
Here is an example of a 10-inch story (on top row) and the 7-inch version (bottom row). In the 10-inch design, we used a 2-column grid for the text, while in the 7-inch design we could only use a single column. It was a pretty inefficient way of working, so we were tasked with coming up with a One-Design Solution: a way to design the digital edition once for all device sizes.
We had to come up with a design that worked, and looked good, on both 7-inch and 10-inch devices. Our research told us that most of our digital readers were on 10-inch devices, which was helpful in prioritizing which size to start with.
We did some wireframes using different type sizes and page structures, and tested them on our editors.
We sketched out some key screens with the new navigation tabs, in order to flesh out the new design.
Part of the solution was to incorporate a group of navigation tabs at the bottom of the page, which would only show up on the 7-inch devices. We designed a variety of tab treatments and layouts, and tested them on our editors.
We tested lots of fonts sizes, page structures and tab designs. Our challenge was to design text-heavy layouts where the type looked good and easy to read on all tablet sizes. After many wireframe iterations, we eventually landed on a good compromise and created a whole suite of templates for many of the recurring magazine pages in order to speed up and streamline the process.
Based on our user testing, we came up with a One-Design solution that allowed us to design the digital edition one time for all device sizes. Here is the 7-inch version of a story from our June 2014 issue.
This is the 10-inch device version, which is the same as the 7-inch version, except you don't see the tabs at the bottom. The One-Design solution resulted in major cost savings for the company.
Parents Tablet Enhancements
At Meredith Corp., I worked with a small team of designers and editors to adapt print content into an interactive tablet edition for our digital subscribers. When I first started working on this project, I noticed several things that needed improvement (colors, symbols, navigation, artwork, typography), and worked with my team to make the app a better experience for our users.
Colors - too many pastels!
The first thing we noticed was that the tablet layouts were using CMYK colors that were lifted off the print layouts (when copying and pasting content). In the print version of the magazine, there were a lot of pastel-colored elements and type that did not read well on a digital device screen, so my teammate and I came up with a limited RGB color palette to use when translating print content for the tablets. We later added more colors as necessary, but decided to no longer try to match whatever was happening in the print version in order to get better readability.
Poor Navigation In terms of navigation, I thought the Table of Contents was too fussy and organized in a way that wasn't intuitive. A reader would have to tap three times to get to an article, and the magazine's articles were organized in contextual menus that changed depending on which section was being active. Too confusing, and bad user experience.
Buttons and elements I also noticed that a lot of the buttons and elements used pastel watercolors and whisper-thin, hand-drawn lines, which were hard to read. After doing a comparative analysis of a dozen other magazine apps, my teammate and I were able to convince our editors to avoid using these colors and elements, and go with mostly black typographic treatments.
We created a library of symbols, buttons, arrows, bullets and directional text to make it easy and intuitive for the reader to move around the pages and interact with the content.
Simplified page structure
In order to improve on the information architecture and navigation on the Contents and Age-by-Age Guide pages, we went back to the drawing board and sketched out simpler, more intuitive layouts. We wanted to make it easy for the reader to find the stories they wanted to read, or to simply browse all the content at a glance.
We also created a new page called Index, which would provide yet another way into the issue by highlighting the recipes, crafts, and videos in a gallery layout.
From the paper prototypes, we put together some wireframes with the new design for the front-of-book pages. We wanted to streamline the process of translating the print content into the digital edition as much as possible, with plug-and-play templates.
Here is an example of the redesigned Contents and Age-by-age guide, and Index pages based on the earlier prototypes. All of the articles are listed on each page, and the reader can see the whole issue at a glance. We stuck with black type, and eliminated the pastel watercolor design elements for better readability.
Another area that needed rethinking was the Playroom section. This was an 8-page roundup of the latest children's books, movies, music, video games, along with a quiz and monthly calendar. When landing on the opening page of the section, a stop-motion video would automatically start playing. This was charming the first couple of times you watched it, but quickly got old.
We found that the section was very memory-heavy because of the video and all the photos. Our team also felt that it needed a design refresh. So we put our thinking caps on...
...and came up with a simpler, flat design. We got rid of the video (which caused longer download times), and commissioned illustrator Lucy Vigrass to create a set of simple, yet bold illustrations that would work well with the editorial content.
New Section: Toolbox
Another navigational enhancement we did was to create a section called Toolbox at the back of the issue, to house all of the recipes and craft project instructions. We loved working with illustrator Lucy Vigrass on the Playroom section, so we asked her to create the cover page illustration for the Toolbox section as well.