Balancing Quality and Time

When I started NoctaCam, I wanted to build a great product rather than cut corners and launch quickly. I asked myself, “What makes for a good user experience?” or “What bar of quality would I like in a camera app if I were the user?” I was inspired by Apple, and I wanted to get the details right, even if it takes time. Quality is more important than time, I thought.

But this led to slow progress. It took two quarters to launch the first feature, and we went three quarters before launching any more features, until last fortnight [1]. When I looked back, it seemed that the effort I put into polishing what I launched couldn’t grab attention like I had expected it to. People didn’t seem impressed by the UX. Evidently, I’d gotten some details right, but not the ones that these people were looking for.

In an ideal world, you’d implement the gamechangers and showstoppers, but not the distractions.

With the benefit of this framework, somethings we implemented were kind of distractions. We realised that we shouldn’t set such a high bar, which most apps regularly don’t meet, either. For example, Twitterrific would crash every time I tried to attach a photo. I realised only after months that I’d accidentally used the parental controls to restrict its photo permission. It should have informed me, rather than crashing. There is always room for improvement.

The real problem is that we don’t know ahead of time which tasks are distractions. Earlier, I took a conservative approach, taking care of these just in case users mind. Now, I’ve switched to a more aggressive approach. After all, if something is important, I’ll hear about it, either via an app store review, social media, in-app feedback, or some other way.

When I started off, being an engineer, I was too code-focused and too little product-focused. For example, I’d review the code of both engineers in the team before committing, continuing my habit from Google. Or they’d commit to a branch, I’d review, and they’d then merge it into master. I realised that that was too obsessive, and told the engineers to commit directly to master without waiting for a review. The review can happen later, but they make quick progress, such as by building on top of that in a further commit. Great code in an incomplete product doesn’t help. Product quality — quality of the app as judged by users — is no less important than code quality. I’d rather have a great product with bad code than great code that doesn’t serve users’ needs. I decided to strike a balance. A non-technical founder wouldn’t have made this mistake in the first place.

Earlier, I was quality-focused, saying “This is the bar, and we’ll launch when we meet it, whenever that happens to be”. Time wasn’t a factor in the planning, and that was, in retrospect, a completely wrong decision. To fix this, we’ve now decided to be primarily time-focused, launching a new feature every week, if possible. We’ll make sure that every feature we launch works, and produces as good or better photo quality than any other app. While not making you choose settings that the app could do itself. We’ll do limited visual design. For example, a long-running operation should have a progress bar, but we may implement a linear progress bar instead of the circular one that we all agree is ideal, or just show the progress as text, like “45%”, if that’s faster. The focus of the UX is mostly on the functional side. Users should know what’s going on, like: is a long exposure in progress? They should be able to stop a long-running operation.

For example, we’ll have limited error handling, and the app may not work optimally in some edge cases, like getting a call during a long exposure. We may not have optimal photo quality, just as good or better than any other app. Instead, we’ll launch and continue to make enhancements, rather than blocking the launch. Performance and battery consumption may not be optimal. Instead of testing thoroughly on all iPhones, we’ll do so only on the latest iPhone, and do limited testing on older phones.

After this new strategy has been in place, we already launched three new features: a long exposure mode, a zoom, and a black and white mode. All these produce as good or better results than any other app we tested.

Now that we’ve launched, we’re continuing to enhance these features. We’ve already optimised long exposure to run in half the time as before, and zoom to have even better quality. These enhancements will launch soon.

We’ll find out what users want and quickly enhance the features. Quality is a process, not an event: You don’t get great quality by imagining a list of things users want, and diligently working down that list. Instead, you get great quality by launching quickly, listening to users, finding out what’s missing, and fixing it.

[1] To be sure, there were other reasons, like taking time away from coding to research, the overhead of hiring new engineers and waiting for them to get up to speed, and so on. But my quality-first approach was part of it.

Related posts:

Despite the bad news that is pervasive, parents should focus on creating happiness and joy within their families.

Any new industry cops its share of critics. Influencer marketing is no different. However, the constant question of ROI is easier to answer than you’d expect. If you’re trying to jam influencer…

Meta announced today that all Facebook and Instagram users in the United States will be able to connect their wallets and share their NFTs. Facebook and Instagram users can connect their wallets such…