Healthy Church

Overview

HC is a large non-profit in Southern California with over 20,000 people coming and going each week (just through its main campus) through its many services and community outreaches. To manage the church HC employs hundreds of people ranging from pastors to designers. Modern management software didn’t meet needs for addressing member’s personalities and to give the staff the ability to quickly respond to new members and existing member obligations.

problem statement

People come to this church for the community, but often times, do not receive the communications to make them feel involved in the church. Church becomes a once a week activity, rather than a community of people doing life together, and serving the cities they live in.

The church’s communication slips through the cracks, not on purpose, but it happens due to the sheer size of new members, existing members, and new events. Software through suite of apps filled in the gaps. Bringing the corresponding events and groups to the right members, while giving a view to the pastoral staff to serve their members, resulting in small church personality for a large organization across the world.

Users & Audience

A church has many audiences, across many backgrounds, languages, and cultures. The uniting factor is a shared passion to serve the community. Here are a few of the audiences and users that I got to serve.

Volunteers from church body who do data entry, typically retired people who are passionate about reaching their community
Technology forward pastoral staff that want to add a more personal touch to their ministry members
Event staff and childcare staff for church service and church events
Lead pastors
Attending church members of Orange County

roles and responsibilities

Roles

User interface designer for small groups mobile application
User experience designer for management suite of apps
Lead designer for workflows/ task management, in-app suggestions/ inspiration, mobile navigation for tertiary patterns, small group standalone application, events, child-checkin

Responsibilities

UX review of feature requirements documentation
Presentation to stakeholders of design work with explanation and reasoning for solutions
Improve upon design process and help train other designers by example and review
Work with analysts (product managers) to create user centered requirements

Scope & Constraints

“Scope of work was first within the internal design team for a small group app, then onto another team for the management suite of apps.”

Designing for a React native component library.

Working within the constraints of an established design library.
Following feature requirements for each iteration of the design.
Feature to feature dependencies on design and complex critical thinking to make sure features all worked together.

Process

Designer paired with analyst per each feature. Analyst drafts a set of requirements and “ability-to’s” for the feature working with stakeholders. The first part of the process was to collaborate and add empathy for the user into the moldable document.
Next I would think about architecture and UX of the feature. Was the key user a volunteer or on staff? Did they have experience using older versions of the software, or were they brand new? Once I knew who the user was, I would create a quick persona in my notes and use that to measure my thoughts.
The structure of the requirements doc listed the users involved , then a list of ability-to’s with detailed information per each.
I would ask questions ranging from:
- Considerations to other features dependencies
- Desired valuable flows for the user
- Discoveries for new components needed for the feature
- Refactors for other user interactions
- Logic questions of how a user would process information groupings
Decomp of my findings turned into tasks, time estimates, all into Asana.
Setup of initial user flows with the design library and the general navigation. Then we would review as a team and validate the assumptions with the stakeholder.
Then I create quick prototypes through sketch to test. In addition, if the interaction was more advanced, I created a principle prototype.
Initial flows and screens would then move into a review with my UX director, Analyst, and CTO using the user needs in the requirements doc as reference to make sure our iteration was in scope.
By this time there was an established flow and wireframes started with clickable prototypes to hash out ideas for new components and existing pieces from the library.
After design review rounds I packaged up my files with a version number for the file per each version in the review process. .
Handoff meeting would be called with the developers to ask questions and review context, any changes would be made to the design, and then the feature was considered shipped.
Developers progress would be design reviewed before QA, saving time because the designer has a deep understanding of the new iteration.
Bugs were reported for feature and then marked off as done by the developer.
Once QA was done the feature would be released to users to test. Review of feature would be captured by the analyst and relayed to the design team and the process would reset.

Each photo references a part of the process already stated.

Ref. 1-3

Ref 1-3

Ref. 3

Ref. 5-7

Ref. 7-9

Ref. 7-10

Due to requested privacy of this project the finished product cannot be shown, but only spoken to.

Outcomes & Results

I left some incredible feature work behind due to the incredible support and UX grooming from my Directors. The “Workflow” feature was my favorite achievement.

It solved:

People slipping through the cracks when first interested in the church
Gave a way for staff to make personal touch points into people’s lives in a real way. Remember this isn’t your normal organization, staff deeply care about the person and are quite literally offering their time.
Tasks had been released for months with positive user feedback, no major design/flow updates, and heart felt in person reactions.
It was a success and the data entry team (mostly older volunteers who were eager to learn, but used to past systems) was now using another feature of the maturing HC suite.

Presently there are so many terms for a designer: Product, UI, UX, Experience, Visual, Interaction, Graphic, Branding, Identity, etc…. The strongest lesson learned at HC was who I truly was as a designer.

The titles may change, but my foundation was always the same (even as a child making collages). Always thinking about the end result, how the choices made would reflect that result. The separation of the practices for design vs. art.

HC confirmed this in me, and then taught me to speak to my ideas clearly.

HC taught me to speak for UX and question everything that doesn’t bring value until understanding can be easily stated. Now I can give deeper detail to the product decisions and ideas that I contribute.

Read More Case Studies

MODERNIZATION OF CLAIMS EXPERIENCE

Established design culture, process, and innovation of experience and ecosystem of a claim’s lifecycle for plans and employees of BCBS

Read Case Study
SUSTAINABILITY PLATFORM FOR MERCHANTS

Sustainability platform connecting merchants and suppliers with Walmart’s organizational sustainability goals and guidelines for their partners.

Read Case Study
HUMAN TOUCH TO PROVISIONING

Creating an organized and human centered tool for company assets and processing power for experiments.

Read Case Study
REMOVING THE MYSTERY BEHIND ASSET INSPECTION & CAPITOL PLANNING.

Leading the design for the AREview desktop application for managing bridges and in the field mobile application for inspecting bridge assets across the USA.

Read Case Study
CREATING A FRIENDLY & TRUSTWORTHY EXPERIENCE WITH DEBT COLLECTION

Using UX to change behavior and emotions towards debt collection and management. Innovational concepts on approach and interfaces for empathetic users on both sides of a debt life cycle.

Read Case Study