Groups

Project brief

Groups Recover Together supports anyone affected by opioid use disorder. Its care model treats members as human beings first, and I think that’s both courageous and thoughtful: we all deserve care, connection and understanding. Members combine group therapy, in person or virtual, with medication that relieves cravings and withdrawal, so they can set goals and rebuild their lives.

I worked on it through thoughtbot, which supplied most of the tech team, starting with a product design sprint and staying on afterward.

A designer came out of that sprint with me. She set the visual language, and I carried it into the design system I was coding in Tailwind. Groups had a site with colors, typefaces, and some marketing copy, and very few guidelines, so we both worked from what was there. Over time, the design work on the project narrowed to me.

It was the first React Native feature work I had ever done, and the first design system I had built for mobile: two applications, two runtimes, one person holding the system. The system wasn’t craftsmanship. It was arithmetic: the only way that arrangement ships anything is if a decision made once holds everywhere.

The work itself was consolidation. A set of tools assembled quickly during the pandemic had to become one platform, for a service moving to fully remote care, integrating with the electronic health record the organization already ran on. Most of the early judgment was deciding which parts of that to build, which to buy, and which to leave exactly where they were.

A phone number isn’t a person

We were building during the pandemic, when groups couldn’t meet in person. Getting to therapy meant a text or an email, a Zoom link, and sending in test results from home, all handled live and with little guidance, because nobody had planned for any of it. Talking to members taught us that their lives were already full and complicated, and the app needed to get out of the way so they could focus on their Care Plans and their recovery.

Staff trained on the software while we built it, which kept the client’s team reachable for feedback week after week. We interviewed members during the first sprint. It took a lot of empathy, grace, and respect, and we designed almost nothing on this project without someone who used it in the room.

The finding that rewrote the architecture was about phones. Some members didn’t have a device of their own. Some had brought a partner into the program after seeing it work for them, and some of those couples shared both a device and the number attached to it. An authentication model that treats a phone number as an identity works fine until it silently excludes the people the service exists for.

So identity moved to usernames, with a migration path off phone sign-in, a recovery flow, and biometrics designed on the assumption that the device is shared. The same assumption runs through the invitation specs: an invitation that can’t arrive (the number unreachable, or a landline) is an ordinary case with a retry path, not an error state to be logged and forgotten.

Where the platform stops

Staff research set the other boundary: the existing electronic health record.

We covered the part the care team needed day to day, kept the record itself authoritative, and named the edge where the two met. Somebody adding a member still finished the job in the medical record.

That was a decision, not a gap. A system of record you must not replace and shouldn’t duplicate is one you integrate with deliberately and then stop at: a second surface editing the same patient data isn’t a convenience. It’s two sources of truth waiting to disagree. Deciding what not to build kept each patient’s record in one place. None of that shows in the interface.

The sprint set the shape: essential features defined, the integration mapped, then a pilot with real members whose feedback drove the iterations. Interviews sorted what was essential to recovery from what merely stood in the way, and settled the three the product would be organized around: progress tracking, community, and needs and interventions.

One system, two runtimes

A single Pattern Library ran across the clinician’s console and the member’s phone. One shared Tailwind configuration ran across web and React Native, so a color or spacing step carried the same name in both places, with an abstraction layer for things that don’t map between them.

Those differences aren’t cosmetic. In HTML, text can run free in a container; in React Native, every string has to live inside a Text component. A shared system either absorbs that kind of difference or leaks it, and a leak means two implementations drifting from the same intent.

Care Plans were specified as Member and Admin pairs in every version: two sides of one feature designed together, not one first and the other later. That’s the habit the whole system runs on: a feature isn’t the screen the patient sees; it’s the screen the patient sees and the screen the clinician sees, and they’re one decision.

Outcome

The platform launched in beta in October 2021 as web, iOS, and Android apps. In January 2022 we handed it over to an in-house team, and by that June it had reached every member. The handover meant the design system had to be usable by people who had never met us: the real test of whether the naming and pairs were doing their job, and why we had been strict about both.

Self-scheduling, outreach, forms, payment, treatment planning, and group therapy all moved onto one platform, integrated with the electronic health record Groups already used. The same system carried a web portal for care teams and both mobile apps.

Groups went on to more than double its membership over the period it expanded into remote-first treatment: a shift the platform was built to support, alongside a great deal of work that had nothing to do with software. Thirty percent of those members live in a county where Groups has no physical office.

The outcome I’m proudest of is that we shipped mobile software shaped directly by the people who used it, and built to help them. The aim was to help members rebuild their lives with positive habits and a community of peers who could help them through difficult times. That mission stuck with me, and I still think about it. Working in health technology is a privileged position to be in, and I don’t think I’ll forget how important that felt.

What I’d change

We did a lot of research, and it was episodic: it arrived at milestones, in campaigns, when a phase called for it. I’d run standing interviews every two weeks with a fixed group instead, so that insight arrives continuously rather than being commissioned.

I’d also tell the next person to keep investing in the design system and let it evolve with the product. When a new feature comes along, step back and look at how the pieces work together. That keeps the visual language cohesive, and it shows the next person how much today’s foundations and components can already build.

And there’s a question I never had access to, which I’ve come to think is the real one. An organization like this sits between government grants, regulation, and its own financing, and the design problem underneath it all is how you ethically scale something like this: how to grow enough to support as many people as need help, without exploiting a single one of them.

The project opens with a finding about one person’s phone and ends on a question about an entire business. It’s the same instinct at two scales, and I only got to act on the first one.