Spire Programs


Spire Programs

What if your health devices did more than stuff your data into a dashboard?



Showing users their health data in a dashboard isn't enough. Users are overwhelmed by their data and have difficulty making it actionable. They are tired of gimmicks like "10,000 steps". How can we make their data approachable and actionable? 



Make user data useful by interpreting it and providing actionable suggestions. Do this without gimmicks or spam—only ask for the user's attention when necessary.



I was the sole user experience designer on the project, working on all aspects of the project including product spec, user testing, iterations, final visual design, and engineering handoff. I worked closely with our VP of Product, Backend Engineering Team, and CEO to build and test prototypes.



VP of Product
Contract Visual Designer
Backend Engineering Team
iOS Engineering Team
Chief Science Officer


What I Learned

Designing Programs was the most freedom I’ve had for a project. We started with just about no concrete requirements beyond a high-level product vision.

I learned to set requirements for a product, keep things simple, test and iterate as many divergent ideas as possible, and how to create boundaries for ourselves when there were none.

Building early versions of programs in Python gave me more exposure to engineering thinking and constraints than ever before. Writing code myself taught me about what was technically feasible, how to communicate clear specifications, and what different features demanded from a technical perspective.


Background & Research

In our user research and app analytics, we’d observed the following trends in Spire user behavior:

  1. They launched the app several times a day to look at their health data.
  2. They were often unable to interpret this data to make it actionable.
  3. They didn’t know how they were doing over the long run. Were they less tense since they’d bought Spire? Were they sleeping better?

Further, our new hardware, the Health Tag, doesn't need to be put on or have its battery charged. You could totally forget about it during your day-to-day.  

What if the app could similarly be forgotten until absolutely necessary? Folks aren’t buying Spire because they want a new app to launch every day. They’re buying Spire to reduce stress, be more active, and sleep better. 

We set out to design a new app paradigm that would:

  1. Help a user achieve their health goals by interpret the user’s data for them.
  2. Allow the user to go long stretches without needing to open the app.

Early Prototypes

What would the simplest version of this paradigm look like?

We already have certain info: everything the Health Tag tracked, which includes sleep, activity, workouts, calm minutes, tense minutes, heart rate, and breath rate. 

All these data points is useless without the most important item: what are the user’s goals?

A most basic prototype would require:

  1. The ability for the user to declare their goals.
  2. A channel for the app to alert the user of their progress towards their goals.

Engineering & “The Insight Engine”

We’ve touched on our first consideration: what is the best experience for the user?

There was a second big consideration: what kind and depth of data-interpretation is actually possible, considering our engineering resources?

We quickly built a basic Python app that we internally dubbed the “Insight Engine”. It would be used to test what kind of “data magic” could be achieved. I have some programming background from Carnegie Mellon, so I wrote the first two Programs together with our Lead Backend Engineer and CEO.

The "Insight Engine" was a nifty tool that made user testing our Programs possible. We could quickly build basic programs that were capable of most of the Program functionality. If we received feedback that needed a fix, found a bug, or had a new feature to test, we could immediately implement these changes and see the results.



User testing uncovered a number of challenges at the intersection of engineering and user experience.

The first: it's easy to dream up a feature that "tells you what you need to know at the right time". But what are the exact rules for when a message is triggered? What constitutes health information that you "need to know"? 

Another challenge: over what time scale should we test this feature? A program could end after a week, a month, or it might continue perpetually until a user decides to manually complete it. We didn't have months to dedicate to testing but needed accurate results.

If we were a big team with lots of resources, these wouldn't necessarily be huge challenges. But as a small product and engineering team, we were constantly resource strapped and had to aggressively balance moving fast with thorough user testing.


Final Designs