Helping people save more toward their goals, automatically — a case study

UX Design & Prototyping for Twine’s Auto Savings Increase feature

Derek Bender
4 min readJul 2, 2019

Background

About Twine

The Twine iOS app helps simplify savings for people, allowing them to create an account with a spouse or partner for the purpose of achieving their shared financial goals.

User problems

Users loved to save money but didn’t always see enough progress. Also, getting into the habit of saving was a difficult sticking point for folks.

I know saving is important but getting into the habit of doing it is a major pain.

Hypothesis

If we prompt users to setup an automatic savings increase, we will help them save more money over time, allowing them to reach their goal faster. This will in turn result in higher engagement and user satisfaction as well as higher TNT (Twine Net Transfers) and AUM (assets under management) — our two guiding business metrics.

The team

As a contractor I came onboard to help with Twine’s project backlog. After I familiarized myself with the iOS app with a few smaller projects, I started to work on and lead the Auto Savings feature. I primarily worked alongside the Head of Product and Lead Researcher while working collaboratively with other stakeholders including the Engineering team. Copy was crafted with extensive help from the Creative Strategist.

Discovery

We kicked off the project with a team brainstorming session. This idea had been on the roadmap for awhile, so there were plenty of thoughts on how it should work. The basic idea was to have it be similar to a feature of most 401k plans in which the savings rate increases year-over-year but for our purposes it would increase with every deposit, usually monthly.

A key theme of our product strategy is to help users build good financial habits and make incremental, consistent progress on their financial goals.

We asked ourselves, how might we shield users from potential overdrafts in case they overestimate their ability to save at the rate the increases will eventually increase towards? We also wanted to maintain the balance of trying to help users maximize their savings while being sensitive to their individual budgets.

From here I started by process by sketching the key flow. The goal was to quickly put together a rough prototype which we could test with users. Working closely with the design researcher, we tested multiple prototypes with actual Twine users in structured user testing sessions.

Early prototype with text-based UI that had the 2 variables (increase & limit) on the same screen.

Dollar versus percentage

Each session brought feedback and validation but also prompted more questions, such as, how do people best understand their rate of increases: by dollar amount or percentage?

Through testing we found that folks with more in-depth knowledge of finance liked to increase by percentage, equating it to how increases work for their 401ks, but people with less experience preferred a dollar amount, which was transparent and straightforward. Since we wanted to cater to both groups, we choose the lowest common denominator: dollar amount increase.

Early mockups showing dollar v. percentage increase. We choose dollar amount increases since all users understood how it worked and there wasn’t ambiguity as was with percentage increases.

Functionality

After working through multiple versions, we landed on a direction and user flow that was clear and concise. From here I worked on honing the visual design and interactions.

Using a lightning bolt icon for each Auto Increase touchpoint helped to brand the feature, keying the users into what goals the increases were being applied to and serving as an entry point to edit or turn off the feature.

A few of the UI elements incorporating the ‘bolt’ icon for use in branding Auto Increases.

I spent most of my time with the graph — making it functional while maintaining its simplicity and clarity. The graph allows the user to see how adjusting the increase and limit variables affect their savings over time and how fast they can accomplish their goals.

Trade-offs

I initially designed the graph to animate as the user moved the sliders, giving them real-time feedback. After careful thought and feedback from the engineers, concessions were made for the sake of time and the graph would be static, refreshing with each adjustment by the user. But we agreed in future versions it would animate as originally intended.

Reflection

As my time at Twine was winding down I finalized designs and turned over assets to Engineering.

As of now, there’s no data to turn to see if we’ve increased our metrics but we’ve had folks who participated in user testing contact us to ask when it’ll be released — a very positive sign.

I was fortunate to work with so many amazing folks during my time at Twine and I’d like to thank them for their work and positive impact on this project. Thanks!

--

--

Derek Bender

Product designer. Previously @Instacart, @Handshake, @Uber & @Pinterest. Let's go somewhere.