Calvin Bowen

Zoteria

An award-winning app helping LGBTQ+ communities report hate crime safely and find verified support.

AKQA Leap (with Galop & Stonewall)2022

Zoteria Find Support directory
Zoteria service detail page
Zoteria design system
Zoteria app screen

Zoteria, initially Soteria, gave LGBTQ+ communities a safer place to do two things: report hate crime confidentially, and find verified support when they needed it. Built in partnership with Galop and Stonewall, the longer-term goal was bigger than the app itself — an accurate national picture of anti-LGBTQ+ hate crime that could inform legislation.

I joined through AKQA Leap as one of three designers, each leading a separate feature in parallel. I led Find Support, and at the end of the project I led the work to formalise our rough, divergent components into Zoteria's design system.

Two Lenses for Finding Help

Find Support is the directory connecting users with verified advocacy groups across the UK — sixty services at launch, varying enormously in size, focus, and visibility. The first instinct was a flat list. I ruled it out quickly: a flat list rewards services people already know, and a meaningful portion of the directory was small, regional, or community-specific. Six outcome-led categories solved most of the problem — browse by what you need, not by who you've heard of.

But Galop and Stonewall thought about support along two complementary axes — who it serves and what it provides — and users don't all reach for the same one first. A second layer of community labels surfaced services through that other lens. The card-sort sessions kept landing in the same place: two lenses served more mental models than either lens alone.

Find Support directory with category and community navigation

Designing for the Worst Moment

Before designing the service detail page, I tore down how other catalog-style products handled theirs — Meetup, LinkedIn, the App Store — annotating each screen with a simple loop: what I noticed, what we should and shouldn't borrow, and what I wished I understood about why a team made a particular call. A service's detail page is the moment in the app where someone might be at their most fragile, and the design had to work for someone reading it in a crisis, not just someone browsing on a good day. The teardown kept pointing at the same detail: a logo does real work, so I treated it as non-negotiable. Not every partner had a polished brand — some were tiny phonelines run on a shoestring — but I pushed for each one to align on something. In a fragile moment a familiar logo is an anchor; outside those moments, it broke the wall-of-text effect and made the directory scannable.

Competitive teardown board — annotated screens from catalog-style apps with notice / should / shouldn't / wonder sticky notes

Design for the worst moment, not the average one.

The same teardown shaped the rest of the page. A modular template — primary and secondary descriptions, a map, an office-hours timetable, contact details — meant a service that only needs a phone number that works at 2am gets a clean page that says exactly that, and a service that needs the full picture gets the full picture. Same template, different shapes, no bespoke engineering each time a new partner came on.

Modular service detail page

Tuning for Confidence and Safety

Three feature streams running in parallel each grew their own rough components, and by the end of the build there was no shared system holding them together. The app was technically consistent but had no formal foundation — and for a product that needs to feel like a calm, trustworthy place to do something hard, an ad-hoc system is a real risk. I led the work to formalise it: standardising the scattered components and design tokens from all three streams into a single design system, tuned to communicate confidence and safety.

The result was bigger than consistency: a product that read as safer and more confident, consistent enough to feel like one thing rather than three, and a design system new designers could pick up and move quickly with.

Design system alignment across the three feature streams

When the Data Outlives the Product

Zoteria won BIMA Gold for Charity & Social Enterprise — that's the framed moment. The honest read is more interesting. The app has since shut down, and users who land on it are directed to Galop. But the underlying goal was never just the app; it was the dataset — an accurate national picture of anti-LGBTQ+ hate crime in the UK that could inform policy.

Hate encounters logged
688
Outside major queer cities
60%
Trans share of support requests
45%
Top reported motivation
Sexual orientation

That part worked. In 2024 the Vodafone Foundation published Hate Happens, an independent report by Dr Kevin Guyan analysing the encounters Zoteria collected — the kind of policy artefact the project was designed to support in the first place. The product was the vehicle; the dataset was the destination. Design that contributes to something durable after the artefact is gone is the work I'm most proud of on this one.

---
title: Zoteria
client: AKQA Leap (with Galop & Stonewall)
year: 2022
role: Designer — led the Find Support feature and formalised the design system; one of three product designers
recognition: BIMA Gold — Charity & Social Enterprise
---

# Zoteria

> An award-winning app helping LGBTQ+ communities report hate crime safely and find verified support.

Zoteria, initially Soteria, gave LGBTQ+ communities a safer place to do two things: report hate crime confidentially, and find verified support when they needed it. Built in partnership with [Galop](https://galop.org.uk) and [Stonewall](https://www.stonewall.org.uk), the longer-term goal was bigger than the app itself — an accurate national picture of anti-LGBTQ+ hate crime that could inform legislation.

I joined through [AKQA Leap](https://www.akqa.com/leap/) as one of three designers, each leading a separate feature in parallel. I led Find Support, and at the end of the project I led the work to formalise our rough, divergent components into Zoteria's design system.

<Chapter title="Two Lenses for Finding Help">

Find Support is the directory connecting users with verified advocacy groups across the UK — sixty services at launch, varying enormously in size, focus, and visibility. The first instinct was a flat list. I ruled it out quickly: a flat list rewards services people already know, and a meaningful portion of the directory was small, regional, or community-specific. Six outcome-led categories solved most of the problem — browse by what you need, not by who you've heard of.

But Galop and Stonewall thought about support along two complementary axes — *who it serves* and *what it provides* — and users don't all reach for the same one first. A second layer of community labels surfaced services through that other lens. The card-sort sessions kept landing in the same place: two lenses served more mental models than either lens alone.

<Figure src="/work/zoteria/zoteria_lenses.webp" alt="Find Support directory with category and community navigation" />

</Chapter>

<Chapter title="Designing for the Worst Moment">

Before designing the service detail page, I tore down how other catalog-style products handled theirs — Meetup, LinkedIn, the App Store — annotating each screen with a simple loop: what I noticed, what we should and shouldn't borrow, and what I wished I understood about why a team made a particular call. A service's detail page is the moment in the app where someone might be at their most fragile, and the design had to work for someone reading it in a crisis, not just someone browsing on a good day. The teardown kept pointing at the same detail: a logo does real work, so I treated it as non-negotiable. Not every partner had a polished brand — some were tiny phonelines run on a shoestring — but I pushed for each one to align on *something*. In a fragile moment a familiar logo is an anchor; outside those moments, it broke the wall-of-text effect and made the directory scannable.

<Figure src="/work/zoteria/Zoteria_teardown.png" alt="Competitive teardown board — annotated screens from catalog-style apps with notice / should / shouldn't / wonder sticky notes" />

<PullQuote>
  Design for the worst moment, not the average one.
</PullQuote>

The same teardown shaped the rest of the page. A modular template — primary and secondary descriptions, a map, an office-hours timetable, contact details — meant a service that only needs a phone number that works at 2am gets a clean page that says exactly that, and a service that needs the full picture gets the full picture. Same template, different shapes, no bespoke engineering each time a new partner came on.

<Figure src="/work/zoteria/zoteria_details_page.webp" alt="Modular service detail page" />

</Chapter>

<Chapter title="Tuning for Confidence and Safety">

Three feature streams running in parallel each grew their own rough components, and by the end of the build there was no shared system holding them together. The app was technically consistent but had no formal foundation — and for a product that needs to feel like a calm, trustworthy place to do something hard, an ad-hoc system is a real risk. I led the work to formalise it: standardising the scattered components and design tokens from all three streams into a single design system, tuned to communicate confidence and safety.

The result was bigger than consistency: a product that read as safer and more confident, consistent enough to feel like one thing rather than three, and a design system new designers could pick up and move quickly with.

<Figure src="/work/zoteria/placeholder_design_system.webp" alt="Design system alignment across the three feature streams" />

</Chapter>

<Chapter title="When the Data Outlives the Product">

Zoteria won BIMA Gold for Charity & Social Enterprise — that's the framed moment. The honest read is more interesting. The app has since shut down, and users who land on it are directed to Galop. But the underlying goal was never just the app; it was the dataset — an accurate national picture of anti-LGBTQ+ hate crime in the UK that could inform policy.

<OutcomeStats items={[
  { label: "Hate encounters logged", value: "688" },
  { label: "Outside major queer cities", value: "60%" },
  { label: "Trans share of support requests", value: "45%" },
  { label: "Top reported motivation", value: "Sexual orientation" }
]} />

That part worked. In 2024 the [Vodafone Foundation](https://www.vodafonefoundation.org) published [*Hate Happens*](https://www.stonewall.org.uk/uploads/files/Zoteria_Report_240926.pdf), an independent report by Dr Kevin Guyan analysing the encounters Zoteria collected — the kind of policy artefact the project was designed to support in the first place. The product was the vehicle; the dataset was the destination. Design that contributes to something durable after the artefact is gone is the work I'm most proud of on this one.

</Chapter>

---

**Next:** [Assistants](/work/assistants)

[← Back to all work](/)