Family Proud.

Care is exhausting. The app shouldn't be.

Family Proud is a cross-platform app that helps caregivers organize and vocalize care for someone undergoing hardship. Managing care for a person in crisis is time-consuming, emotionally draining, and overwhelming — and the business had a real objective riding on solving it: drive sales of care items by making the experience worth coming back to. My goal as the designer was to make administering care joyful rather than painful.

I was the sole, lead designer, working alongside the CEO, a dev lead, and a business management lead over a six-month engagement. We agreed on a measurable bar up front: every core task should hit a CSAT ranking of 8 or higher, with a pass rate above 80%. That gave me a scoreboard to design against instead of a matter of taste.

Understanding the problem.

Before I designed anything, I needed to understand the pains people were actually living through in their care journey. I ran five contextual inquiries to gather demographic data, goals, and where it hurt most. I compiled the qualitative data in a spreadsheet, compared it across people, and looked for where the same emotion surfaced again and again. Three trends reframed the whole project — and each one overturned an assumption the business had walked in with.

• Caretakers have their hands full — and need help, too. The initial assumption was that caretakers were the primary audience. Digging deeper, I found that close family and friends were the most engaged in providing assistance. The people who needed the most help were the ones doing the helping.
• Privacy is key. Another assumption was that people should seek help from their communities at large. In reality, primary caretakers wanted to keep care inside their "inner circle" — "I wouldn't want anyone to be able to look up my daughter."
• Those in need don't know what they need — and are often too afraid to ask. Out of a sense of pride, many caretakers and survivors didn't know what to ask for, and felt a quiet shame in asking at all.

Personas & journeys.

Once those trends were solid, I compiled personas — the key actors in the care story — so the team stayed clear on exactly who we were solving for and why. I paired each with a journey map of what the typical care process looks like in the real world, which made the gaps in the existing, painful process impossible to ignore.

Information architecture.

I grouped the key problems surfaced in those early conversations and ran a competitive analysis of what existing products already offered. From that, I built the information architecture — structured around the realities the research had revealed, like keeping care private to an inner circle by default rather than broadcasting it.

Lo-fi & brainstorming.

I ran several whiteboard sessions with business leaders and developers to keep three things true at once: we were solving the users' problems, addressing the key business need of selling care products, and building something feasible for a small dev team on a tight timeline. Wireframes let us quickly suss out internal problems with my hypothesized flows before they got expensive.

Visual design.

For type I went with Futura and Futura Book — a professional-yet-friendly balance that fit the mood of the app. The color palette came out of a mood-board session: the tone we kept landing on was "bright" and "calm," so I built an orange/navy complementary scheme out of the idea of a sunset over the ocean, which evoked exactly that feeling. From there I created components and tested and adjusted each one for contrast and accessibility.

Hi-fidelity & usability testing.

Next the veneer went on: I built the prototype, then confirmed and tested it. We defined 8 core tasks a user had to be able to complete to use the app successfully and hit the business objectives. I ran those flows through 2 rounds of testing across 7 users, watching pass/fail rates and capturing qualitative data. Testing did exactly what it's supposed to — it embarrassed a few of my assumptions early.

• 6 of 7 failed to navigate. A sharp reminder of why icon-only navigation doesn't work — 6 of 7 users couldn't knowingly get to "My Circles" or "Resources." Adding labels fixed it.
• 5 of 7 confused "Home" and "Profile." The two pages looked too alike. Adding differentiation and clearer signals of which page you were on eliminated the problem in round two.
• 3 of 7 leaned heavily on external scheduling tools. So I added integrations to the final design, letting people stay in the tools they already live in.

What I'd do differently.

• Test earlier, at lower fidelity. Lower-fidelity testing would have reached the high-level conclusions sooner. I was constrained here because stakeholders wanted to present a polished product to users.
• Keep researching and iterating after launch. This was a handoff at the end of design. In an ideal world I'd have stayed on to capture successful task completions, time on page, impressions, and other live signals.
• Tighten the scope of personas. With too many personas in play, the experience gets muddled for the key users in focus. Pushing harder to limit personas would have produced a more focused design.