…So where do we start?
This is actually kind of a tricky question. Here are a few options that might spring to mind:
- We could just sort of…start from the beginning. We could simply imagine the first thing a user will encounter — account creation? — and build out organically from there.
- We could start by architecting and building some of the underlying systems we know we’ll need in the app — networking, data persistence, etc — before working our way up to the app’s business logic and UI.
- We could hold off on writing code, and instead start by diving deep into developing plans and designs describing exactly what the app should do and how it’s all going to fit together.
- We could go full TDD and start by writing tests for the app’s core business logic! 🧐
- We could start by building a quick and ugly prototype of our basic app idea, allowing us to test it out early and evaluate what might or might not work.
There’s probably some sort of argument to be made in favour of each of these — some stronger than others! However, none of the above feel quite right to me. When starting something new, I have three priorities in mind:
- Validate. If there’s some reason this app idea isn’t going to pan out in the way I expect it to, I want to know as soon as possible. That means I want to spend most of my time initially exploring what’s essential about that idea and proving that it works, rather than on the supporting features I’ll eventually build around it.
- Avoid wasted effort. I’ve got other important work on the go, and I’m getting paid exactly $0/hr to noodle away on my indie project, so I personally don’t have much of an appetite for work that I’ll ultimately throw away. As much as possible, I want the work I do from the outset to be high-quality and potentially shippable. It also means I want to avoid over-engineering solutions to problems I may not yet fully understand in the context of this particular app.
- Build momentum. On day one, I want to be working on the stuff that really excites me. Keeping momentum up throughout an app development cycle is tough — I’m sure lots of us have folders full of half-baked, abandoned ideas we were once really jazzed about. By starting off doing work I know I love, I’ll feel creatively energized and make progress quickly. With any luck, this will lead me to new ideas I’m excited to explore and help keep the ball rolling in the future.
Guided by these priorities, I’ve taken a very particular approach to writing my first few hundred lines of code. While I don’t think there’s anything outlandish about it, it is a little bit at odds with some of the more typical approaches to building products I’ve taken with teams in the past. Regardless, it’s worked for me, and it might serve as a good starting point for you too. Let’s break it down into three parts.
Part 1: Identify your core interaction loop
If you google “core interaction loop”, you’ll see…nothing, really, because it turns out I may have accidentally made it up. Let’s talk about it anyways!
In game design [disclaimer: I am not actually a game designer and have no idea what I’m talking about], there’s this concept of a core gameplay loop: it basically describes the primary system or mechanic that players will interact with repeatedly, and that the rest of the game is built around. It’s a bit of a loosey-goosey term, but one way to understand it is as the thing that you really have to “get right” to keep people interested — if the core loop isn’t fun and engaging, no amount of world-building or tacked-on subsystems will make the game enjoyable.
When I say “core interaction loop,” I guess I’m just adapting this idea to the broader world of app development. Your core interaction loop is the fundamental thing that users will be coming into your app to do the majority of the time. It’s the basic, repetitive use case that props up the rest of the app, and that you know you need to really nail if you want your users to stick around.
As a dead-simple example, consider a weather app. Weather apps tend to have a handful of features outside of the core interaction loop: tracking multiple locations, sharing forecasts, advanced radar maps, etc. But unquestionably, the thing that any decent weather app has to get right is providing a simple answer to the question: “What’s the weather like today?”
Of course, not every app has such a clear and concise use case to zero in on. But, if you feel your app has a few candidates, consider which of them users will likely be performing most often, and which of them is closest to the heart of what you think makes your app unique and valuable. If you’re building a to-do list app, and you’ve invented some wacky, never-before-seen way to add new items to a list, consider that to be your core interaction loop.
Part 2: Identify what’s going to make it great
I’ve mentioned it before, but in case you missed it: there are a whole lot of apps on the App Store. Whatever your brilliant app idea is, how you execute it is going to play a huge role in whether you’re able to stand out from the crowd. And, nowhere is that execution going to be more impactful than within your core interaction loop.
So, what is it about your particular take on this interaction that’s going to make it a great experience for your users? Are there ways in which you want to allow your users to accomplish some task and get back to real life as quickly as possible? Do you have ideas on how to make a relatively complicated interaction surprisingly intuitive? Are you focused on crafting a delightful experience that makes your users smile? Figure out what your priorities are, and start thinking about ways you might design and implement your core interaction loop to reflect these priorities.
Part 3: Build it, and then polish it, and then tweak it and polish it some more
There’s this idea I hear bouncing around a lot that goes something like this: if the basic idea of your product is compelling and worth building, users will use it despite any flaws or broken pieces or ugliness. A similar approach sometimes comes out of “agile” development processes, especially in teams that tend to be more business-driven: “Let’s get to a basic MVP as quickly as possible, ship it, get feedback and iterate.” This suggests that maybe our goal from the outset should be to build the simplest possible version of our app, get it into people’s hands as soon as we can, and save the polish for later.
There’s definitely some wisdom in that kind of approach, and I’m not really willing to argue with it directly. However, I’ll say a couple things:
- Call me an artsy idealist, but I’m personally always a bit bummed about building and shipping minimum viable products that, by definition, are incomplete, include disappointing omissions and are just…kind of hard to love.
- Often, especially in smaller indie projects, what makes a product compelling and worth building actually isn’t the idea at all, but the impressive attention to detail, the personal touches, or the singular design. Rushing to build basic functionality might lead you to lose sight of the stuff that’s actually going to set you apart and attract users in the first place.
So, now that you’re finally ready to sit down and start creating your chef d’oeuvre, here’s my arguably unorthodox suggestion for what to do first: design and build the core interaction loop we’ve identified — that small but oh-so-crucial sliver of your app — and polish the cuss out of it. Build something that checks all the boxes you identified in part 2. Build something that looks and feels great, and that you’d be thrilled to release into the world tomorrow morning if the rest of the app magically appeared overnight. Build something you love! In my experience, the indie iOS community truly values the most thoughtful, polished and well-crafted apps; why not strive for just that from the get-go?
It’ll take time, and that’s okay. If you’re anything like me, you’ll be energized by diving headfirst into the heart of your app and seeing something special come to life early on. And crucially, by nature of this being a central piece of your app, you’ll come up with tons of peripheral ideas along the way as you gain clarity on how the rest of the app is going to fit into what you’re building.
There will be plenty of time to iterate and make changes later — what you build at this early stage almost definitely won’t ship exactly as-is. But with the care and effort you put into it right off the bat, much of what you build here should stick around over time and help define the structure and design of the rest of the app. In the meantime, what you’re building now acts as a high-fidelity prototype that should give you some real insight into how your basic idea feels to use, and help you decide whether you want to keep investing time and effort into it.
Note: something I’ve left open-ended here is the question of whether you should be building a complete vertical feature, i.e. whether, where applicable, you should be implementing networking or data persistence layers to support the core interaction loop you’re building. I’ll leave it open-ended for now — I think it depends somewhat on what exactly you’re building, and what you think is important or valuable about it — but I will say that in my particular case, I’ve stubbed out those lower-level layers, because they’re ultimately meant to be largely invisible to the user during the core interaction loop anyway. My suggestion: focus on user experience, and keep the scope of your implementation as narrow as you can.
So go make yourself a coffee, clean up your desk, put on some tunes and start building your dang thing. Get lost in it for a little while, have some fun, and build yourself a small but essential slice of app that’ll get you excited to build more. There’s no better feeling than seeing creative work you’re proud of come to life!
If you: a) think this article is full of great ideas, or b) think this article is full of terrible ideas, I’d love to hear from you! Find me on Twitter if you have any questions or thoughts 🐦