I wrote about it while I wrote the first version of the app, right here on this blog. I wanted to write about writing an app; what better way than to write an app? Otherwise, articles are just hand-wavy. What people talk about when it comes to apps versus what I observe and experience when I’m writing one are so disjoint. Writing about how an app comes together was therapeutic.

I intended to put the app in the App Store but had no expectations when I started the project.

As I wrote the app, I used it as a user. It was then that I thought it might be successful. It was a thing that could work.

Doing this all on my own, I lost patience and just wanted to ship. I had the core of the app on my phone that was pinging around my head months earlier.

Perfect is the enemy of the good.

So I rushed out a website, took a week preparing the app store screenshots (they are finicky!), bashed out a quick pre-launch email sequence (with eight sign-ups).

And I shipped!

It went live in early December.

I also wanted the app out before New Year’s Day to catch all those who, resolute for, at most, a month to lose some weight, download any and all apps to give them an edge, including mine.

I started using it myself in earnest, found a bug with the iPhone 7 wide colour screen support causing a button click to be slow. Fixed it. Phew!

I’ll just let the downloads roll in and cash those cheques from Apple!

You already know how this story ends, though.

Even though my rational self had read so much about how hard it was to make money on the app store, I still had this exuberance. I was blind to the flaws of my app and ignored that nobody knows about it.

It was a personal success to get an app on the store. But that’s not enough to make it. On the internet, no one knows you’re a dog. And no one cares if your app doesn’t make it, either.

Except, maybe, your mom, er, my mom. One’s mom?

Only my mom bought it. (Thanks, Mom.)

I’ve had a few more purchases from strangers. I thank them too. (Thanks, strangers). I have a few other close family buy also. (Thanks, close family who aren’t my mom.)

I feel like this app is something worthwhile for others, based on twenty years experience working out, grinding out work out plans, dieting, weighing and measuring. There’s a market for this. The fitness biz is HUGE. I’ve used the app faithfully every week since shipping it. My body has changed, and the app is keeping me honest. I’d like to make this into a successful app that helps people change their bodies.

So what now?

I know the answer, and it doesn’t help that much. I need the following: marketing (so that people know about it); more product development (so there’s more value to whoever downloads it); and a solid business model (so I can continue to improve the app, and, maybe, live off making it).

See? Not helpful. Every $2 Medium writer could (and will) tell me that.

I have to specifically, methodically market and develop the app. I have to change the business model; paid upfront doesn’t work for the fitness category. Or maybe any category?

I’ve read a lot about marketing. I’d say I know too much theory. If you came to me with your marketing problems, I know I’d have something to say. But I’ve never actually put it into practice. The to-do list for marketing is a mile long, and it overwhelms me. But, I’m guessing (or rationalizing) that it’s one of those things that tends to get its momentum as long as you just start.

My marketing plans have been pinging around my brain for about six months now. It’s time to dump it out, make it tangible.

With product development, I’m intimately comfortable. I developed and have been using an app for eight months now. I know where it needs to go.

I have the least experience and comfort with the business model. The method of making money on an app is not where I can innovate. So, I’ll just copy what others do, I reckon.

So, with this post, I start the journey to Kapowski 2.0.

One of the most successful ways to make yourself lose weight is to make yourself accountable to someone else: a coach, trainer, loved one or a fellow fat loss participant. Similarly, I need some accountability to turn Kapowski into a viable business. Rather than pick someone specific, I’ll just choose you, Dear Reader.

And, of course, Mom.

Mom is always watching.

Welcome to prerelease. I don’t have much advice to give here: this is new territory for me. I know lots of theory, but I haven’t really applied it to any of my previous apps, or someone else did it. But, this time, I’m going to go through with it. This is learning in action!

There is a period where the app is ready but no one knows about it. I’ve been using it to record my progress; it’s really great. Now I have to start preparing for release.

Let’s go through everything we need to ship in the App Store:

• an app (duh);
• the app store description;
• screenshots for the app store description; and
• a pre-release website.

I’ve written about the app already, except for the code (it’s coming).

Next, the app store entry. This is a big form with a bunch of fields, most of which are pretty straightforward for Kapowski. The toughest one is the description itself. I know exactly why I wrote the app, but how do I get it down to something someone might read? (No one reads these.) Instead of agonizing, I just wrote something and put it up. My pitch will get better with practice. This is a version 1.0.

Here it is below:

You can never number-crunch your way to a satisfying relationship with your own body.

“Not everything than can be counted counts, and not everything that counts can be counted.” — Albert Einstein

Calorie counting, Fitbits, scale weight: they all stop working. They are unsustainable. I know this because I’ve tried them all. I either got all stressed and no fun because I was obsessing over these numbers; or I’d barely keep it up for a few days because it was too hard, too unnatural. Then I was stuck.

That’s why I decided to write My After.

My After is different.

My After is focused on showing you the results of your transformation. My After lets you easily take photos of yourself from different perspectives every week. Compare each week with the first week.

Get motivated to keep going.

Stay motivated throughout knowing that you have to “weigh-in” every week.

My After makes it easy to form a weekly habit of checking in with yourself. See at a glance if you are staying true to your goals.

No need for a diet plan or workout routine to get started. Start taking pictures every week. The rest will follow!

Features:

• take photos every week, compare with your “Before”
• optionally track scale weight and girth measurements
• integrates with Apple Health for body weight
• get reminders for your weekly “weigh-in”
• no account sign up
• securely stores your photos

Next is the app screenshots. These are more important than the description. Apple emphasizes these in the app store entry: this is the store front display. Care must be taken. Even though we, as app developers, don’t control this part ourselves, it’s just as critical as the FUX.

In a way, this is an even shorter pitch than the app description. What’s your app do? I have five screens to show you.

The production of these took about a week: Finding stock before/after photos, putting them in the app, taking screenshots. Get one thing wrong, start again. Gah! I didn’t quite know what I wanted so there was definitely some trial and error. But things came together and I’m quite happy with them. Dan Counsell has an article on screenshot styles that I found enlightening. I decided on a mix of 2 and 3.

I’d love to show them to you, but I just realized while writing this post that creating app screenshots is a post in itself. So, you’ll just have to wait. \<- Marketing!

Finally, the prerelease website: I did this too. Rather than go ground up and take just as long as the app took, I searched for a template, modified to my needs and shipped it. It was better than I could have done from scratch in the time I gave myself to do it. You’re going to see it soon.

The hardest part of prerelease is not rushing it. My patience is thin. I want this out there for people to use.

I’m pretty sure it was Wes Anderson, but who knows. He was on The Late Show with David Letterman in the late 90s, a quirky director of quirky movies. He said it was miracle any movie got made because just showing up near the end was so hard. It’s a slog, in other words. I know that feeling.

We’re close now.

Software development is rife with bike shedding.

Imagine developers in a room: they will agonize over spaces in a file or where the curly brace goes. Yet their app is drowning in over-engineered “frameworks” that no one understands.

Wait, it gets worse: if there is anyone non-technical in the room, the only thing the group can all reason about is user facing stuff: images, icons, colours, animations. This stuff matters, yes, but quite a bit less than anyone thinks.

So, who wants to do some bike-shedding on Kapowski’s App Icon?

For all my talk about bike-shedding and how trivial things take up time, I spent a lot of time agonizing over the app icon. Perhaps, it’s because there was no one to call me on the bike-shedding. Perhaps it’s because this is the first time I said to myself that I’m capable of doing the icon (all my other apps where done exclusively by me, except the icon). Whatever the reason, the icon got a lot of attention. I’m not sure what’s normal for designers to spend on an icon, but let’s say I spent a solid week on it, 40 hours.

I decided early on that I’d be the one to do the icon. I was expecting it to be some minimal thing to represent the before and after: Two rectangles adjacent, one filled in. I can do that and it’s de rigueur. Round the corners, add a colour. Boom. Done. I’m an icon maker!

But I can rarely leave anything alone. Who’s got two thumbs and takes things to extremes? This guy!

I started thinking through the problem Kapowski solves a little more thoroughly. It let’s anyone easily track progress while they’re changing their bodies. The thing about changing bodies is that, to make the transformation last, the process involves changing lives: you need to change your values, your habits, what you do, with whom you do it. And it’s not an overnight thing, it’s more of a gradual set of changes that compounds. Whoa, that’s serious. But, pull it off: seriously awesome. What else is awesome? Fuckin’ rainbows.

What if instead of a drab solid colour, the after was represented by a rainbow of colours?

I fired up Photoshop. I forgot that I hated Photoshop before I fired it up, but after struggling with the gradient tool and importing a sunburst from Illustrator and all kinds of shit, I fired up Sketch. I reproduced what I did in Photoshop in a half hour. Cool. I’mma stick with Sketch.

This was my first draft. It…was not what I pictured my mind. That’s a rainbow, sure, but it’s covered in mud. Who wants a muddy after rainbow? And that drab grey on the end doesn’t work the way I want

There were many more prototype rainbows. But I finally got to something I liked.

Gorgeous! But, it’s missing something, isn’t it?

I tried a few more things to make it bit more symbolic, or icon like or something. They all sucked.

What now?

While designing the icon, I was also searching for stock photos of silhouettes for buttons in Kapowski. I was looking for sterile poses of front, side and back, to represent the perspectives for which you would take photos. If you’ve been following Kapowski closely, you’ve seen the fruits of those searches. While searching for those images, a few interesting poses caught my eye; I couldn’t use them in the app, but would they work in the icon?

Hell yes, they will.

That’s a pretty sweet icon.

I suspect—without any specific evidence—that this app will be used by women more than men. I’m probably skewing it more by using a rainbow. But I’d be outright forcing the skew if I kept the icon like this. And I don’t want to limit the audience, despite this being the best representation of the idea in my opinion.

So, after more searching and some tweaking, we finally have Kapowski’s icon

Oh, right. Make it easy, and habit forming, to take photos and measurements to track progress during physique transformation.

It’s not a complicated premise. I assume most people are aware of before and after photos.

Ew. That last sentence made my programmer spider sense tingle. Let me be more precise: those interested in physique transformation (fat loss, muscle gain) have presumably browsed websites related to exercise and fat loss. One cannot go to those sites and not see a before and after photo comparison.

My hope is that some of those who are so motivated search the app store for the best app in the store that does that: Kapowski!

Let’s go through what they’ll be greeted with when the open the app for the first time.

The first screen, left most in the figure above, is a bog standard welcome screen. We describe what Kapowski does, motivates where it fits (this could be a tad more precise now that I write about it), and make the user take action right away with that big button at the bottom. (Could there be some foreshadowing in that text? Hmm.)

The second screen, the sex picker, is pretty straightforward: pick the sex with which you identify; the UI changes accordingly, only showing representations of that sex. This screen caused me no end of hand wringing.

Sex is a spectrum, or something? I honestly don’t understand it but I’m sensitive to the need for those that feel they are not either sex. The code is much simpler if I limit to just male and female. I don’t suspect Kapowski’s user base to be much more than tens of thousands; at that size, the potential user population that would require an ‘other’ option is too small for the engineering effort. Software needs to be inclusive to succeed, though. If Kapowski blows up, I’ll revisit this.

The next screen: mode selector, I call it. This is inspired from video games with an easy, normal and hard option: this has changed as I’ve aged to default, nightmare and nightmare plus darkness, or something similar. I originally had easy, normal, hard, but I prefer the terms I chose instead: Stress-free, default, obsessive.

There are those that punish themselves with fitness; they feel that it’s supposed to hurt to work well. I’m a recovering one of those. Sticking with easy, normal, hard was sending the wrong message, I thought. You want hard mode, keep it in the workouts. There is no virtue in taking tape measurements, or measuring scale weight as long as progress is apparent. Photos can show progress just as easily; not that photos themselves aren’t stressful. I’ve been take some of myself: yeesh!

Hence:

• Stress free which sets up Kapowski to only track photos from front, left, and right in the measurement screen. It also sets up a local push notification to remind you it’s weigh in day.
• Default which sets up Kapowski to track photos (same as Stress-free) and scale weight. It sets up a local push as well.
• Obsessive which adds waist and hips measurements to Default. “Obsessive” may be a bit on the nose, but it’s the only time we get a little preachy.

The next screen met with much vacillation on my part as well: we need permission to use notifications and integrate with Apple Heath. I have to ask sometime. There is evidence that telling users we’re going to prompt them with the permission dialog, as opposed to just showing those screens, is much more successful. That’s all this screen does. It’s the only skippable screen. I vacillated on the inclusion of Apple Health, for…reasons. I decided to just go ahead and include it.

Finally, we have the first weigh-in screen, in three versions depending on the selected mode, depicted below. There are slight differences between it and the standard weigh in screen: a prompt to make your before pics right now and the units selector. The units selector is because I’m Canadian and sensitive to units as only Canadians can be.

Tap Done on the weigh-in screen and you’re kicked into the app proper where we count down to the next weigh-in. You must complete the FUX or keep doing the FUX until you do. Restart the app and you start where you left off. And almost no code to do so. Thanks, Apple!

Writing this blog post forced me to reconsider whether I’m doing enough. Time will tell. Onboarding is one spot in an app where analytics makes sense. I’ll make a note right now to follow up in a few months. As I said about the FUX last time, there’s a tension involved between giving users what they need to know to get started and being exhaustive. I still think I’ve struck a nice balance here.

We’ll know shortly. The release is coming. Stay tuned.

I’ve also found that as that hand-drawn sketch gets better, goes digital and gets closer and closer to what everyone thinks will be the final look for the app, normals have a tough time distinguishing between that mockup and the final app. Ditto for “prototyping apps” like Invision.

The screen is the app to them. That screen is also the network and the server, or servers on the other end of those network calls.

Making the actual app look like that mockup, whereever it came from, is the app developer’s job.

I’ve found, however, that going right to the pretty version causes a lot of confusion.

“Oh wow, this looks great! It’ll be ready next week then?” the client asks.

“Um, no,” you say, exasperated. “We’re months away from shipping.”

Then everyone is resentful on both sides.

Creating a pixel perfect screen in code to look exactly like the mockup is pretty easy to do…if everything is fake. In other words, if we only concern ourselves with cosmetics, most seasoned iOS developers can have it working on iPhone and iPad within a half hour, no matter how crazy the screen is. But start adding or removing copy based on some logic, image loading based on logic, data fetching across a network: you know, the useful part of an app, takes a lot longer than anyone realizes, even the developers.

So, here’s the thing: don’t show them the pretty screen until the end. Make the UI reflect the state of things in all the code. Show tab bars without images on the very first demo. Have hard-coded pictures of Matthew McConaughey in there. As more features become functional, spruce up the UI.

It may seem disingenuous, but it’s really the only way to reflect the progress in an app to someone who is not technical.

I’ve always known this. Or rather, I can’t remember a time when I didn’t know this, but that must not be true. I haven’t always been a software developer.

Turns out—and this is true of most of the advice I’ve spewed in this series—Joel Spolsky said it first. And better. What I’ve just explained is the Iceberg Secret.

That’s why, if you troubled yourself to look at the Zeplin screens, you’d see purple blob people instead of actual people. This rule is so ingrained, even my mockups have to look the part of doing just enough.

This is often the case for enterprise software: they want to vet you right away to see if you’re a good candidate to go after. It could mean martini lunches and golf trips for the sales guys, while the developers work extra hard back at the office getting that TPS report cover letter generator feature working. Sigh, you can probably tell which group I was in.

Conversely, I’m sure you’ve been asked to just enter just your email address. Then follow-up emails start showing up with subjects like, Dear Neonballs, how is your software going or Hey studmuffin86, having trouble getting started?. These are amusing in their clumsiness: you’re likely not going to use that software either.

These are analogous to the First User Experience (FUX) of an app.

If the onboarding is long and convoluted, people will just stop halfway through; conversely, slam a login/signup screen in their faces first thing, they won’t sign up.

I’ve noticed the latter in many health and fitness apps. I find it presumptuous on the app maker, but I don’t have their numbers. I usually just close the app right away. Good thing Kapowski has no accounts to speak of—well, for this version \.

So what makes a good FUX?

A good maxim for any good user experience is: don’t waste the user’s time. Those fancy loading screens? Spend the time perfecting caching on the server and client instead, so you don’t need a fancy loading screen. Also, just use a spinner. No one cares about your loading screen.

Netflix has a great user experience: Pick the profile. Tap once more, you’re watching a show. They realize no one gives a shit about Netflix, the brand; people want to watch their show. Netflix doesn’t waste my time.

Every website that’s all parallax and stock photos? Where it’s not obvious what’s a link? Pretty, but wasting time.

Within your app, don’t waste their time with anything that doesn’t serve the purpose of using the app. Keep animation short and subtle, don’t use too much colour in the chrome. Make it fast and obvious.

Remember my analogy last time about a big splash versus ripples in the water?

The first time is wildly different than every other time a user opens your app.

The first time, they don’t know what’s going on; it’s all new.

A good FUX is slower paced than the app, but not too slow; it’s prettier than the app, but not too pretty. A good FUX informs but doesn’t drone on. And, also, it doesn’t waste the user’s time. What’s truly important to know or configure in your app? That goes in the onboarding flow. For everything else, pick sensible defaults.

Apps require a pithy phrase to describe their value. It’s always good to return to that when in doubt.

We’ll go through the Kapowski FUX next time.

You jump feet first. Within a second, you’re in the water; the serene surface broken by froth of your entry, ripples in the surface emanating from where you entered the water. You did it: the first jump of the day.

Great. But why doesn’t anyone think about the poor water?

Imagine you are a lake. It’s a pleasantly warm day so far, but even if it gets really hot, you’re a lake; it’s ok. There’s no breeze. All of a sudden you’re surface is wrecked with a big splash by some doofus in board shorts and a bad haircut. Right in your good water! You love that water. Now it’s all over the place. What a mess.

The very first time you open an app, you’re the water. What would make that less traumatic?

Any software project that you’ve been working on for months becomes a part of you. It becomes hard to imagine your life without that project. Near the project’s end, there’s nothing you don’t know about it. You are intimately familiar with every detail, every interaction, every concept underlying that project. Everything makes sense to you.

Then you ship it or show your friends a beta version. Chances are you are met with blank stares. OK, maybe if you’re building Facebook, but for dogs or Uber, but for bakers, they might be able to grasp it. Otherwise, there’s a disconnect from your familiar use—the ripples in the lake—to their very first use—the giant splash. If you just throw them right in, the experience might just turn them off your app completely.

Reducing that disconnect is the difference between high user churn and a successful app.

This is typically called onboarding, but I recently saw the acronym FUX (First User Experience) to describe the same concept. I like this name much better. Juvenile, perhaps, but will you ever forget the concept, or its importance, if it’s called FUX?

The underlying principle to the FUX is: get them most familiar with the app with minimum friction.

They’ve heard of the benefits of the app from somewhere: you’re marketing efforts, your app description, a friend; something somewhere has compelled them to install your app. This is a hot lead, folks. The FUX should keep them hot. We don’t want to dent their enthusiasm.

The FUX let’s them know: there’s a splash coming but everything’s fine.

Rather, I’ve started being a pathological user and realizing my integration is woefully inadequate. What’s a pathological user, you ask? A dickhead, basically.

By being a dickhead, you uncover all sorts of problems in your app that should be fixed. Good QA people are, yes, dickheads. If you’re not totally annoyed with your QA almost always, they’re not good QA.

Almost everyone thinks about just the Happy Path within a feature. The happy path, if you haven’t heard the term, is when the user instantly grasps what they must do and use a feature exactly as the design intended. This almost never happens. If you only account for the happy path in your design, you discover all the other terrible, error-riddled paths when actual users use your app.

Integrating parts of iOS into your app have the potential to really hamstring the experience. Apple requires getting permission from the user for apps to use parts of the system. This is best for users. As a user, I want developers to jump through hoops to do something, to consider the ramifications of their decision to work with that particular part of the system.

For shits and giggles, go into Settings -> Privacy -> Camera and deselect Instagram or Facebook or something popular. I’ll use Instagram as an example since I just did this with Instagram, while writing this sentence. You just suddenly revoked Camera access to an app that’s all about Photos. Open the app. They handle it okay: my audio got all screwed up and I just see a black square when I launch the camera. But I didn’t crash and the other tabs worked just fine.

This may be intentional on Instagram’s part; I suspect it is: there’s no way they haven’t tested this part of their app.

Anyway, try it in less popular apps and with other services, you might not get very far in that app with that stuff turned off.

You can get into all sorts of shenanigans by tapping “Don’t Allow”.

You can wish they didn’t tap “Don’t Allow”, but some will; I even recommend you tap Don’t Allow with push notifications in almost all apps—except Kapowski, of course.

You have to handle the Disallow case in your app. Not crashing is the bare minimum.

For some features, like Push Notifications, the app should function exactly the same with or without permission. Push notifications are a good way to get timely information or have a shortcut into a part of the app that’s relevant at the time. Disallowing push should have very little impact on the user.

But other services require hassling the user a little more. Kapowski is a mobile app because of taking photos with the built-in camera. This app needs permission to use the camera to do its job. The user can deny access. What then?

First, don’t assume they’re a dickhead. They may have tapped “Don’t Allow” by mistake, or perhaps they are wary users because they’ve been burned before; there’s a reason Apple introduced asking for permission for the camera. They need a way to recover from tapping “Don’t Allow”.

Apple doesn’t make this easy for app developers to do for a user; the user has to do it on their own. The most an app developer can do is prompt them with an alert to open Settings and give permission. This is what Kapowski does now for the Camera and the Health app. And, I just realized while writing this post, I need to do the same with Photos for the advanced setting of adding photos to the camera roll.

So it goes.

I’m coming to a sad realization that there’s more work to do. Cancel or allow?

Every app seems to want to push something to you.

The Apple App Review Guidelines state, section 4.5.4 (emphasis mine):

Push Notifications must not be required for the app to function, and should not be used for advertising, promotions, or direct marketing purposes or to send sensitive personal or confidential information

What is a push notification from the Facebook app but an advertisement telling you you’re not on Facebook right now? That is why you get them if you allow notifications from Facebook. You likely don’t care that Aunt Mildred likes the same cat-falls-off-the-roof video you do. But Facebook wants you to care, wants you to open the app from that notification, spend five minutes looking posts that include ads so Facebook makes money. The push notification is about them, not about you.

Your human brain is wired to notice notifications and act upon them. Companies know this.

My personal use of notifications has dropped dramatically since I made the conscious choice to disallow them unless I could obviously benefit from that particular app giving me notifications. I think I only have two or three apps with push turned on, out of 10-12 that I use regularly. Writing this post is making me consider turning it off for one of them. (As I was writing this, I did an audit of apps that could notify me: it was much higher than three. I turned a few off but kept most on. I had forgot most of them because I don’t get push notifications regularly from those apps. When I’m flying, Air Canada can push to me, for example.)

It is tremendously freeing to not get notified. I can’t quite pay attention like I was able to before I had a mobile device, but it’s way better without push notifications. I’m sure it would be even better without Twitter and Instagram, but people without vices are boring.

If you’d like to start to live distraction free, I suggest just turning the sound off notifications. There are other tips on timewellspent.io.

I don’t want this to be a polemic against push notifications; they are useful in various contexts. I want Messages notifications, for example. But they are an insidious time suck when not useful, benefiting the app, not the user. We only have so many hours in our life. I am wary of them; we should all be.

And now the rub: should I have them in Kapowski?

Kapowski would have two, maximum, local user notifications. One, to remind you of your upcoming weigh-in; the second, to tell you it’s weigh-in day. Both are optional, of course.

Let’s go through the whole premise of Kapowski again (always useful when in doubt about a feature). Kapowski makes it easy to track progress during a physique transformation by ingraining a habit of measuring yourself once a week and keeping the measurements all in one place. The pressure of a photo shoot in your underwear every week might just make you put the fork down early and exercise just a bit more. (That’s what I’m hoping it does for me.)

The point of Kapowski is to form the habit. The ideal use of Kapowksi is once a week. Take picture; compare from the before photo; close ’til the next week.

Notifications are a good way to nudge people to form a habit. If you’re not used to weekly weigh-ins, then a notification is a modest little reminder.

I have to check if the app can clear notifications on the user’s behalf (I’m pretty sure this is the case).

Then we will have everything I’d like in a notification as a user: an ethereal reminder mid-week: “If you’re not allergic you should eat more broccoli.” Huh? What is this? Oh, yeah! I have a weigh-in on Saturday.

Then, on the day: “You should weigh in today. Why not now?”

I don’t think that’s too pushy.

There is a point in a project when there are no more questions to ask. Everything major has been dealt with at least, but perhaps solved entirely. The rest of the work is following those decisions to their end, filling in the necessary details to embed those decisions in the code.

We are at that point with Kapowski.

It is overwhelming right before I realized I had reached that point: all the details that still need to be worked on are swimming in my head and I flit quickly among the different threads of user interface, code, icon design, pre-launch website, etc.

It’s at this point, where, for real, you need to write shit down. Not just on a piece of paper, like an old-school to-do list. I’m talking about an issue database, a bug tracker, Trello, Basecamp: software with which you can manipulate that list.

This is also the point where you can truly pick your ship date and rely on it. I’m not going to announce anything in this blog post. I’ve already slipped once.

You can pick the date because the creative part is largely over. Copy still needs to be written, imagery created, but the spots in the app UI where those will go are known. The purpose (the what) of the app is now fully realized; the method in which it fulfills that purpose (the how) is known.

The process to get the how fully realized is straightforward; straighforward—mind you—not easy. There will still be hiccups, but from this point on, there should be no ground-shaking fundamental changes, where all assumptions are upended. Any epiphanies from this point must wait until Version 2.

And it is a process as well. I use process here as in a formal process because really everything is a process. I’m a product team of one and even I need a process. We’ll come back to process later.

On to the update:

Take a look at the Zeplin Scene and you may notice, if you’ve been there before, that Settings got a big overhaul. I figured out what Reminders will be (we’ll come back to that); I added the obligatory Feedback and About rows as well; and we added an Advanced section for settings.

I had the notion of the obsessive measurer wanting to weigh in daily. I want to let them if it makes them feel good (some people might need it for a while). But I don’t want to distract what I think will be the majority of people with an extra button on the home screen if they don’t need it. So, that explains the first toggle, Weigh In Anytime. I’m not quite sold on that capitalization, but that’s easy to fix.

The second (so far) advanced setting is enabling saving the photos taken in Kapowski in the Camera Roll. Not sure if that will be on by default.

The Weigh In screen got a bit of a refresh. I was not happy with the layout of those measurement rows. I’m still not that keen on them, but hey, we gotta ship. And I’m not sure what else to do. You’ll notice three versions; they correspond to the three modes I introduce in the FUX, which is not in Sketch/Zeplin yet. Did I mention I love the term FUX? We’ll talk more about that soon.

Finally, the Home screen got a slight make over as well. There was a problem with my initial just enough design: if I get users to take pictures from more than one perspective, how do I show them all on the home screen for them to easily compare. I had a few draft ideas that honestly—in retrospect—sucked. Then it hit me: little images in the corner. Duh! Obviously awesome. Click the little image to change the perspective in the big image. Cycle endlessly through them.

Another change that isn’t reflected in the visuals: see that All button? It’s gone. Again, the app requires a way to see all weigh ins. The just enough design did it poorly. Instead, the weigh-ins between before and after are “under” the before and you can scroll back in time to the first after photo. I want to do more to manage the weigh-ins—so much more.

But any further revelations must wait until Version 2.