The x-factor in great product design

Imagine you’re in your favourite snacks aisle at the grocery store. You pick up a box of ‘Sam’s Seafood Snacks’ and have a look at the big vertical list of checkmarks on the front:

• ‘High in Omega 3!’
• ‘Great Seafood taste!’
• ‘Made of blue whale!’

The last one is suspect. Even if you didn’t mind eating whale, you can be pretty sure that Sam’s Seafood Snacks won’t be on offer for very long. At the very least, because they’ll run out of blue whales. Evidently, the snack’s creators weren’t thinking long-term.

Those of us who build products often make the same mistake as Sam: we too use ‘blue whale’.

In our heads-down, crunch-focussed industry, we often build apps by incorporating technical features from ecosystems we don’t control. And then we get unhappy with their short lifespan.

The world and OS around an app will always change, breaking how software works, or making it redundant. In a worse case scenario, an OS update breaks your app on all your customers’ devices. In a best-case scenario, an OS update suddenly gives your app new functionality and performance, with no effort on your behalf.

Designers like me are often very vertical-centric. This is because we work on a 2D representation of the app in front of us. A drawing of a static, beautiful thing. Abstracted away from the underlying technologies which are constantly changing, we see only this instance of time.

At the beginning of my career, I was blind to much of this. Over time, however, I’ve realised the importance of the forces that push and sustain a product over time.

Where it goes wrong

To further explain this, let’s imagine the lifespans of two products: a ‘vanity’ app made because someone said ‘we need a cool app!’ and a ‘sustainable’ app with real economic and technological forces driving it.

Both apps look great at 1.0. In fact, there are reasons why the vanity app might actually be more eye-catching:

• It’s using lots of (hard-to-maintain, custom) drawing code, because the designers and developers were incentivised to make  something ‘impressive’;
• It is heavily optimised to look good on slides and pitch decks — but not necessarily work well in the real world;
• All development is squeezed into the  1.0 release, burning-out the product team; and
• All features must be ‘in’ — bugs or no bugs!

In contrast, the sustainable app has fewer features targeted for 1.0, and some features even get removed before 1.0 because they don’t work. It is a beautiful app, but not at the expense of functionality. The development team is not burnt out, and the hard decisions to drop features have been made.

Once the vanity app launches, there’s a bug fix and a few more missing features are added. The development team is then moved on to another project because the app is ‘done’. But somewhere along the way, a system OS update breaks some features, so the app gets a fix release. But it happens again, and the app gets marked for end-of-life status.

In this imagined comparison, the sustainable app continues to put out releases year after year.

Did you know that Photoshop was created in 1988? And I bet somewhere in today’s app there is still 1988 code running. Which means there are 20-somethings alive today using software that is, in part, older than them. This is a real demonstration of sustainability.

Sailing with the wind

I’ve thought much about where this sustainability comes from. I see a set of strategies that make it possible to build apps and services that are pushed and sustained by energy and forces outside themselves.

I now understand that understanding and building with, rather than against, these forces make a vast difference in where an app or service will end up some years from now.

Building on a technological wave

Steve Jobs said: “We try to look for these technical vectors that have a future, and that are headed up, and, you know, different pieces of technology kind of go in cycles. They have their springs and summers and autumns, and then they, you know, go to the graveyard of technology. And, so we try to pick the things that are in their springs.”

While at Evernote I worked on Scannable: a document-scanning app. The app used machine vision on the GPU. It could find documents (skewed rectangles), choose when to capture, dynamically clean up, crop and rotate. We could tell if something was a magazine article or a mostly black and white document, for example. This let us crunch down images to uber-clean, tiny files for easy sharing and fast uploading to the cloud.

We were pushing the GPU, CPU and camera hardware hard. Why? Because we knew these three things were on a rocket trajectory. With each new iPhone hardware release, our app got remarkably better, with no effort from us. This is because each new iPhone has:

• Higher resolution cameras;
• Faster capture times, including indoor low-light (usual document-scanning place);
• Better in-camera stabilisation, a big deal for document capture; and
• More powerful GPU and CPU to handle on-the-fly image processing.

If I was to start working on Scannable today and had to think a couple of years ahead, I would count on the above continuing to improve and throw in:

• Improved ability to understand the content of images and audio;
• 3D imagery available at all times; and
• Improved awareness of activity and place and human focus.

Multiple markets

Back in the day, I was part of an independent Mac company called plasq. We were most well-known for a Mac shareware app called Comic Life which turned photos into comic books. It was a very successful shareware app, and we were approached by Apple to bundle it with new Macintosh computers. We were afraid bundling with new machines would kill external sales. Why? Because the people who buy new Macs were also the ones shelling out for new software.

In the end, we opted in. But despite our cause for concern, we didn’t see a reduction in sales of our shareware version. From memory, there was actually an increase in shareware sales. I’m guessing the increase was caused by people seeing the app on a friend’s computer and deciding they needed it for themselves.

A few years later, I saw something similar. Modelled somewhat after Evernote’s model, we were offering a premium version of  Skitch bundled with a premium version of the online experience. But sales were slow, and cash was running out.

So, we decided to put a premium-featured version on the App Store as a once-off purchase. Again, counter to our expectations, App Store sales were additive. We were selling in two independent markets.

I learnt there are often multiple, completely disconnected markets. If you can design and engineer your product to accommodate both, then sustainability is increased. My previous example, Scannable, leveraged the engine that Evernote used internally for document OCR. The document cleanup was used to improve character recognition, but the resulting cleaned-up document was never shared back to the user. When Scannable was released, there was now two ‘consumers’ for that core tech.

Reuse

Core technologies that are used when creating one product can power new products.

• Skype re-used (an earlier product) Kazaa’s peer-to-peer tech; and
• Unreal Engine, possibly the most popular game engine today, was first created for the Unreal game and later made available to the public.

These technologies might be re-used internally, or perhaps licensed externally. In both cases, the core technology suddenly has more ‘customers’ and more people testing and driving the technology to perform at its best.

Community

As explained in the opening chapters of Daniel Pink’s Drive, Wikipedia won out over Microsoft’s Encarta. Their community’s drive to contribute kept improving Wikipedia. Other examples of commercial software built on a community-driven foundation include:

• Safari on open-source Webkit;
• Linux and Mac OS on open-source Unix variants; and
• WordPress Hosting on top of the open-source WordPress software.

Expandability through building

Related to community is expandability through extensibility. My favourite desktop app at the moment is Bohemian Coding’s Sketch. The plugin community connected to it is simply phenomenal, and almost all are free. Each plugin adds new value to the app, with no effort from the app’s maker. And while much of Sketch’s core functionality has been copied by rival’s such as Figma, the plugins have not.

Expandability through in-app stores

Another kind of expandability is through an in-app purchase or integrated store.

There is a story about why the iPad didn’t launch with a bundled calculator app: Steve Jobs yanked the one they had developed at the last moment. Scott Forstall’s team had taken the existing Bruan-inspired design and stretched it out, but Steve didn’t like it. Of course, Steve had designed the original Mac calculator, so maybe he was particularly sensitive to calculators.

But something else had changed since the iPhone was launched: the App Store had launched. So part of me thinks the reason why the iPad still doesn’t have a calculator app isn’t wabi-sabi, and instead, is because a calculator is a great application to have on an iPad. Imagine a new iPad user looking for a calculator on their iPad, assuming one would be there. But they find nothing. With a gasp of wonderment, they’ll go to the App Store — after all, that is where one goes for apps — and find an assortment of wonderful and varied, free and paid, calculators. And while they are there, the user will be exposed to other apps, some of which will be paid apps, likely making Apple more money.

In the process, the user discovers one of the most powerful features of a modern device: new functionality with just a few taps.

Applying this approach to your own business

The takeaways are this: designing a product is not just about pixels or even the code in the 1.0. It’s also about the business model and understanding of where you fit on a technology or platform’s lifecycle. Some of the forces you can ‘sail’ include:

• Leveraging the work of a platform — using standard OS parts in order to build quickly and ‘inherent’ easy localisation and accessibility, and perhaps deep technology like Apple’s ARKit;
• Building on technology’s performance trajectory — for example, GPU power or Camera resolution;
• Building a community that will build product improvements for you — for example, the Sketch plugin community;
• Leveraging one technology in multiple places — for example, re-using engine technology in multiple apps or by licencing it out to third-parties;
• Finding multiple, often disconnected markets for your app — for example, inside and outside the App Store.

Being aware, and having your product team be aware, of these forces will ensure you produce a more sustainable product. And hopefully, one that feels more like sailing with the wind than against it.

This article was originally published on Medium. Read the original article.

NOW READ: “Just not very sexy”: Travel startup Rome2rio founder Bernie Tschirren explains how it’s SEO not social media that has fuelled gradual — but steady — growth

NOW READ: When Alexa went rogue: The importance of context design