Iteration Nation
Part 1: Don’t Freak Out
Iterating on digital products is a fact of life,but updating your existing app doesn’t have to be a fraught process.
We spoke with our Executive Producer Joana Lehman about how often apps should be updated, prioritizing needs, setting expectations about a budget, and (brace yourself) the fact that users sometimes say one thing and do another.
Small Planet: What’s the first thing product managers say when they walk in with an existing app they want to update?
Joana Lehman: It depends. Often it’s as simple as: “We have this app and we want to make it better, but we don’t have the bandwidth. Can you help us?”
Or, “We made a thing, we offshored it, we don’t have an in-house team, and now we hate it. And we’re in a rush! Can you please redo it?”
But a very common ask is “We really want to go cross-platform now and we don’t have the resources for that.” Often that means they’ve got an existing iOS product and now they need an Android team. This happens a lot, for one reason or another it can be a challenge to find solid Android people, so it’s nice when we can offer experienced developers.
SP: All apps are different, but what’s the general rule of thumb regarding how often an app should be updated?
JL: It totally depends. Certainly no less than every six to eight weeks. Apps like Facebook and Pinterest update every week or so. But something like our Spot On app, which we did with the Digital Innovation Lab at Planned Parenthood, has updates roughly once a quarter, and that seems to be fine.
When you establish a steady drumbeat of updates, you have an opportunity to gather user feedback, interpret analytics, and establish a roadmap for improving and optimizing your app. That’s critical lead time for developers and designers.
SP: Is it a challenge setting expectations about a realistic budget?
JL: Fortunately most of the clients we’ve worked with have a pretty good idea. Smart digital teams have been doing this for a while, so they know what’s up. Also, if they did something offshore and it didn’t turn out great, it’s a bit of a reality check.
Everybody wants the most for their money, as they should. But folks quickly get real about having everything and the kitchen sink for $40,000. If you want to iterate on what you have, actually put best practices from the UX perspective into it, add design that actually fits your brand, and make the app actually work because version one is super buggy … well, like anything, it takes a bit of time and money.
SP: Do you ever give advice on the best way to budget?
JL: No, because everybody’s finance department is a little different. I will say that effective budgeting tends to be time-based.
Establish a fixed fee, agree on what we’re going to make, and figure out between now and that point what you’ll see in the builds. Total clarity helps everybody.
SP: So clients’ eyes are typically bigger than their stomachs when it comes to what they want.
JL: Yes, and that’s normal and okay. We help them get down to what their actual need is. We help them prioritize, starting with questions like “What do you really need to launch with first?”
Given that that it’s a product that already exists in the world, you’ll be able to iterate on it forever, so apps are rarely “one and done.” So don’t think of them that way. You can have the kitchen sink, we just can’t build all of it, all at once, in six months, at an MVP budget. “Let’s start with this and see how it goes.”
User test it, see what people think, how it’s working out, see what it does for whatever their business goals are. Are they meeting their KPIs, all that stuff, and then iterate from there.
A couple of years ago we worked on an app that started with a login screen, which is a big blocker for a lot of users. So, it just wasn’t very well-adopted. The company came to us and we reconfigured it, practically re-wrote it from scratch.
The company made that initial investment and knew that there was something there. But they also knew it hadn’t really worked out, and it was worth spending more money to get the success they were looking for.
SP: In any given update it seems like app owners often have a core problem they are trying to solve.
JL: Yes, which leads to a different kind of user-testing. They really want users to perform two or three specific actions, but those actions can often work against the main problem.
App users will tell you that they want something, but in reality their actions will be different. Prepare for this shocking fact: People don’t always do what they say, and the same thing goes for Discovery processes and what clients are saying.
So, we define that overarching, specific problem during our Discovery process. That becomes the lens we’re going to put all of your goals and KPIs and actions and features through. Can we solve that problem? If so, everything else falls into place.
Sometimes, we figure out there’s a different user problem than we all thought we were solving — something else that needs to happen that just hasn’t been verbalized. So, we’ll get at that and say, Instead of A, maybe B is what we need to solve.” And we take it from there.
In Part 2 we talk about the Discovery process, testing as a customer service opportunity, and the best way to keep up team morale. Read now.
Joana Lehman is an Executive Producer at Small Planet, where she helps teams create award-winning mobile products for clients like Disney, NPD Group, and Planned Parenthood.
Her work has earned the Communication Arts Magazine Award of Excellence and the Fast Company Innovation By Design Award, been featured on the App Store and Google Play, and been downloaded millions of times.
Joana has guest lectured at the School of Visual Arts and taught at Parsons The New School for Design. She received her undergraduate degree from New York University and holds an MFA in Design and Technology from Parsons The New School for Design.
