ser interface designers love a fresh start. We love to remake, redo, and re-imagine. As a young designer I thought the best solution to any design problem was a complete redesign — just dump the whole thing and start over. Even now, I get a little giddy thinking about that.

Over the years the Bible App has had lots of updates but very few actual redesigns.

In some cases, a major redesign may be the answer, but more often than not, it’s an emotional response to getting bored with the way it looks. We imagine that if we just rearranged all these pixels into a beautiful new layout, our traffic would automatically increase, our conversions would multiply, and the people of earth would unite in peace.

Let’s face it, as designers we love each pixel so much more than anyone else. They’re our babies. We love them. We’d leave the ninety-nine to go after the one pixel.

To get over my redesign addiction, I had to wrestle with the “why”. Why did I want to completely overhaul the design of our website or the app? I realized my “why” was painfully clear. I cared more about the way that design made me look to peers than the way it actually looked to users. It’s natural to want to be respected as a leader in your craft, but it’s wiser to be an advocate of the user.

At YouVersion, my exceptionally-scientific research (Ha!) has taught me that half of our users don’t like change, and the other are indifferent about look-and-feel updates. I used to question their taste and sophistication, but now I’ve come to understand that a person’s experience in the app is a matter of routine.

For daily users, their time in the app is automatic, habitual. People don’t think about the interface. They just do exactly what the interface trains them to do. Some do it when they wake up, some do it on their lunch break, and some do it before falling asleep. They have an ongoing habit of spending time in God’s Word, and it’s not about the app at all. It’s about their time with God, being impressed with His work, not ours.

Of course, that’s not to say that sometimes introducing a new interface can’t, over time, retrain them to engage with a feature more frequently. One example is when we updated from an off-screen menu accessed by a three-line “hamburger” icon to the native bottom tab bar that we have today. After we made this change, users could now see the word “Plans” without having to tap that vague icon, and as a result we saw a substantial jump in the number of Plans that users started and completed. We assumed users would know that this hamburger icon would reveal an important top-level menu, but we were so wrong. I was living in my designer bubble. You might think this isn’t a big change, but to this day, this is still the biggest single UI update of an existing feature that we’ve done in a single release.

Even though we don’t make complete overhauls to the Bible app, we are constantly making these kinds of small, careful, considered improvements. Over the course of a five year span, we probably have redesigned the entire app, but we didn’t try to do it all at once.

Here are some things we’ve learned about this process here at YouVersion.

1. Ship Early and Often

During our Plans with Friends project, we designed at least a dozen extra features and enhancements that we left on the cutting room floor. They were great ideas, but we had to decide that we would rather ship when it was useful, not when it was done.

We accept the tension of getting it perfect versus getting it shipped.

If we wait to ship when it’s flawless, then we’ve waited too long. The longer we wait to ship, the more team morale suffers. No matter how long we work on it, we will always be able to come up with additional improvements to make or bugs to fix, so we decide early on in the project, to kill our darlings and commit to a minimum viable product (MVP).

2. Look for Momentum

Once we release a minimum viable product, we check the stats and monitor feedback from all the channels (app reviews, support tickets, social media, etc.) Recently, we’ve even started running A-B tests so that we’ll continue learning from our users.

If we start seeing a swell of momentum, we usually decide to go straight into a follow-up release of a feature.

For example, after we launched Streaks, we saw energy mounting all around it, so we immediately began working on a subsequent release that included offline functionality, a feature we had initially cut from the MVP.

We’re currently in the final stages of a new project that allows us to see our photo library through the lens of Scripture, bringing awareness to how God’s already moving in our life. Where did this idea come from? It’s a response to the increasing popularity and momentum we’re seeing with social media shares of our Bible verse images.

People love sharing artistically designed verse images, and for many, sharing verse images is one of the more missional, evangelistic actions that can be taken from within our app.

Where is the momentum that you need to get behind? Answering that question may guide you to a major idea like a new app, or it may help you see where you should focus your attention for the next minor update.

3. Use Native UI Components

As much as possible, we stick to Google’s Material Design components on Android and follow Apple’s Human Interface guidelines on iOS. Not only does this increase the speed of our development, but it also means that when Google or Apple decides to update their UI libraries (like the navigation bar across the top or their tab bar across the bottom), then our app will get the same new style with minor effort (or maybe no effort at all). Plus, we’ll get that trendy look that we want.

One exception was when we changed to a bottom tab bar on Android when it was not part of Google’s Material Design library. We did this for the same reason I mentioned above, about how the native tab bar increased in Plans engagement. We anticipated that Google would add a bottom tab bar to their official specs, and that gut feeling paid off, because they eventually did. That was a really good feeling!

Custom-built UI components might feel exciting and fresh in the short term, but when Apple or Google decides to update their UI libraries, then in comparison, our app will start looking dated sooner rather than later.

Not Just a Problem for Designers

This mindset isn’t unique to designers. In talking about this idea with a few software engineers on our team, they also admitted to being tempted to rewrite a codebase instead of making incremental updates.

With engineering, this is a case-by-case decision for us. Sometimes an app or website does need an under-the-hood overhaul. A couple of years ago, our senior Android engineer who always found himself buried in technical debt decided to rewrite our app from Java to Kotlin. In that case it proved to be a smart overhaul and allowed him to hand off the entire development to junior developers. On the other hand, for our iOS app, we decided not to do a one-time overhaul from Objective-C to Swift. Instead, we’re gradually updating different sections of our app to Swift as we get to it. This decision has allowed our iOS app to take the lead on adding features. Both apps are among the highest rated apps in Apple App Store and Google Play Store.

One of our Digerati axioms reminds us that “latest doesn’t mean greatest.” When new programming languages and frameworks are introduced, or we inherit a codebase from someone else who doesn’t code like us, it’s tempting to rewrite the whole shebang, but we need to count the cost and approach each situation with wisdom and research.

There’s a reason early adoption is called the bleeding edge.

One Last Appeal

This will reveal my age, but I still remember an article that one of my favorite designers Cameron Moll (currently a design manager at Facebook) once wrote called Good Designers Redesign, Great Designers Realign. This was a pre iPhone app era quote, but it still holds true today. He said,

“The desire to redesign is aesthetic-driven, while the desire to realign is purpose-driven.” — Cameron Moll

As a final disclaimer, there could be a valid reason for a full overhaul of our app. We have to ask the tough “why” questions: Why do we need to redesign? It’s possible that our current design could be really hurting our brand. Maybe our design is ultimately confusing and frustrating. Tread lightly with those excuses though. It’s possible some small tweaks could fix those issues. Consider the cost of the overhaul: the actual cost for the development time as well as the cognitive cost to users who have to relearn how to use and navigate your app.

Redesign for the right reasons, not just to make something creative or different. That’s what our portfolio sites are for 😉.