WrapApp

What is WrapApp?

WrapApp is a web and mobile app that connects violence prevention professionals (VPPs) with the people they support after an experience of violence. It was built for a hospital-based violence intervention program, which offers intensive case management to people aged 10 and older. The goal is to make communication and support between a client and their VPP easier and stronger.

It has two sides. On web, VPPs and admins manage tasks, users, documents and resources. On mobile, clients stay in touch with their VPP and keep track of what they’re working on.

At a glance

• My role: Lead product designer on web and mobile. I worked directly with the client and the VPPs who would use the app, and with the development team.
• Scope: Task assignment, user creation, documents, dynamic resources, chat and badges.
• The twist: Most of it came from Atama, our white-label base. Three pieces were fully custom: dynamic resources, chat and badges. Chat is where the validation effort went.
• Outcome: A web and mobile app that gave the client what they needed to run their pilot.

Context

The client already ran a case management program. What they needed was a tool that would carry that work to a phone and a browser, so that VPPs and clients could stay connected between visits.

This was the first time I got to see Atama fully at work. We had just built a base with the features almost every product needs, and this project needed a lot of them: task management and user management with three types of users (clients, VPPs and admins). Most of the decisions about how those features should work were already made. They fit this project almost as they were.

What Atama covered

Atama covered most of the product before I started drawing:

• Task assignment

  VPPs assign tasks to clients and follow their progress.

• User management

  Creating and managing clients, VPPs and admins.

• Documents

  Atama's Resources module, with rich, Notion-style pages for the information clients need.

We didn’t copy and paste: each feature was adjusted to this client’s brand and needs. But we started from a working base, not from a blank file, and that’s what made it possible to spend our time where it mattered. If you want to know more about how that base works, there’s a full case on Atama.

What was custom

We built three pieces from scratch: dynamic resources, chat and badges.

Dynamic resources

VPPs can offer clients many kinds of help: job offers, courses, events, medical services, legal support and more. Atama has its own “resources”, but those are Notion-style documents. The name is the same only because the client chose it here, and the feature is different, so we built it from scratch.

To create a resource, an admin or a VPP first picks a category. Each category has its own fields: a job offer needs different information than an event. Categories can also be combined, and when they are, the resource shows the fields of each one. That’s what makes them dynamic: the form adapts to what the resource is.

Clients have a Resources section in their app where they can browse everything available. VPPs can also link resources to the tasks they assign, so a client who gets a task also gets the information they need to do it.

We built this together with the VPPs. The dynamic part came out of what we found in testing.

Chat

Atama didn’t include chat, so this was a fully custom module, and it needed validation. A chat between a VPP and a person who has been through violence isn’t just any chat: what’s said, who sees it and how it feels to use all matter more than usual.

Badges

Both VPPs and clients can send badges. They pick one from a bank, then give it a title and a description. Some badges have a fixed description, and others can be customized. Every badge that gets sent is tracked: when it was sent and who sent it. That way admins can also keep an eye on how the feature is being used.

Designing for people I couldn’t talk to

One thing made this project different. I spoke constantly with the VPPs and admins, the ones who would use the web and mobile app every day. But I never spoke with the clients, the people on mobile who had experienced violence. The client handled that contact themselves, because there are protocols around it, and rightly so.

So I designed for those users through the people who work with them every day. It isn’t the same as hearing from them directly, and I won’t pretend it is. But the VPPs knew the clients’ day-to-day reality well, and that’s what we could work with.

Working with developers

The part I enjoyed most was closing the gap between design and code. On this project I did more than hand over designs. I also turned the design requirements into development tasks, and I agreed on delivery times for the custom features together with the team. That meant the people building it and the person designing it were looking at the same list, which is a small thing that saves a lot of confusion later.

It was also a simple project to run, and I mean that as a good thing. All the requirements were agreed from the start.

Outcomes

The app gave the client what they needed to run their pilot, built in 2025 across web and mobile for three types of users.

We delivered web and mobile apps with task assignment, user creation, documents, dynamic resources, chat and badges.

What I took away

• A good base frees you to focus on what’s different. Most of this product was solved. Chat, resources and badges got the attention they deserved.
• Sometimes you can’t talk to the end user. When that happens, the people closest to them become your best source, and you have to be honest about what that can and can’t tell you.
• Testing with the people who will use it changes the product. The dynamic layer in resources came from what we found in testing with VPPs.
• Agreeing requirements early makes everything calmer. Nothing about this project was dramatic, and that was the point.