In Progress
Elevation Church
Mobile App
A ground-up rebuild of how Elevation Church's community connects, engages, and grows. Designed natively for iOS and Android.
1
Lead designer
2
Native platforms
50k+
Downloads projected
THE CHALLENGE
The project began with one concrete anchor, a personalized recommendation engine, and an open mandate to define everything around it. That meant front-loading research before a single screen was drawn: mapping organizational behaviors, understanding existing user patterns, and building a product vision from the ground up.
Discovery-First Process
Six weeks of structured research before any screen work began. Interviews, synthesis, and frameworks shaped the product.
Feature Heavy Scope
Event discovery, group discovery, written content, personalized in-app recommendations, targeted notifications, and more. All net-new.
Primary Engagement Tool
The app is designed to be the central digital touchpoint for a multi-campus church community beyond Sunday.
DESIGN MOMENT #1
The open-ended brief made one thing clear: assumptions weren't going to carry this project. Before any screen work began, the team spent six weeks in dedicated research, interviewing 13 stakeholders across campus, online, and external perspectives to surface what new, growing, and lapsed users actually needed from a church app.
Those interviews were synthesized through affinity mapping into eight distinct theme clusters, each generating targeted How Might We statements. From there, three personas emerged, not as demographic archetypes, but as behavioral models grounded in real patterns from the research. Every downstream product decision traced back to this foundation.
DESIGN MOMENT #2
The project originally targeted Flutter for a single cross-platform codebase, which meant one design serving both iOS and Android. When the engineering team made a breakthrough enabling fully native builds for both platforms, the design approach shifted with it. That meant going deep on native platform conventions for iOS and Android separately, then carrying both forward in parallel as two distinct implementations of the same product vision.
DESIGN MOMENT #3
Two native codebases needed one design source of truth. The view spec template defined how that worked in practice. Token references were mandatory, inline views blocked the other platform from starting, and hardcoded values were treated as must-fix. Having a mutually agreed upon approach for bringing designs to life naturally created the standard that held the system together as the team scaled.
Excerpt from full document