Key takeaways
- Websites have gone from being designed for desktops to mobiles, often clumsily and with reduced usability.
- While mobile-first design was a step in the right direction for web and apps, businesses should be aiming for more.
- An API-first approach will save money, increase agility and create new revenue streams for companies.
There’s nothing more annoying than searching a webpage on your phone for the tiny ‘website version’ link hidden in its depths. If the link doesn’t exist, you’re forced to find a computer to access the full website’s functionality. If it does, you’re relegated to a magnifying glass to read the miniaturised version of the site.
Not all companies designing experiences such as websites or apps have gotten a handle on mobile-first technology. The consumer world, however, has undeniably gone mobile and Google is moving to a mobile-first indexing system for its search engine in 2018¹. Experiences that aren’t mobile friendly will soon go the way of the dinosaurs.
Before business starts to reimagine its technology projects as mobile-first, however, there’s one other concept that should be considered: API-first design.
APIs, or application programming interfaces, are little chunks of code that do individual tasks and plug into all manner of websites and apps. Building from the API up is a method that all companies should investigate. In most cases, it costs relatively the same in the short term, nearly always costs less in the long term, and it enables an agile approach to tech development.
From web to mobile-first
Designing for the internet has come a long way since the first websites popped up on hosting providers GeoCities and Angelfire in the early to mid 90s. With the invention of the smartphone in the late 2000s, all that changed. Suddenly users began viewing on a much smaller space websites that were designed for a desktop experience. If the sites worked at all, they were still tiny and illegible.
Initially, developers followed a concept of graceful degradation to fix this: having the computer screen sized websites ‘degrade’ to the size of a mobile screen. Essentially, the website was configured to drop sections, or incompatible technology, to the smaller real estate.
Unfortunately, there was often nothing graceful about it. Many allegedly mobile-friendly sites were clumsy and their features limited. It was evident that they were an afterthought once the ‘main’ website was built.
Along came mobile-first theory.
First advocated by famed product designer Luke Wroblewski, mobile-first theory argued that designers and developers should follow a different approach. They should first design the mobile version of a site and then, by ‘progressive enhancement’, add functionality to the desktop version.
This would mean, Wroblewski argued, that businesses didn’t miss out on the growing mobile trend. They would be forced to focus and refine their design, eliminating extraneous or irrelevant parts, and would have access to some of the (then) mobile-only technologies such as GPS².
The next step in design evolution: API-first
Given that some websites are still not mobile-first or even mobile-friendly, it may seem strange to be advocating an entirely new design methodology. But an API-first approach has too many potential benefits for business to ignore.
Essentially, an API-first approach breaks down apps and websites into their coded parts: the APIs, which serve as the links between a user interface and its backend functionality. They are self-contained independent services that can be used repeatedly in any number of ways.
For instance, imagine a bank that wants to provide its customers with a way to send money to family overseas. To do that, they want a mobile or desktop app that’s easy to use and allows the customer to select the family member, input the dollar amount and ‘send’ with the press of a button.
The APIs that make this work are plentiful. One would be the address-book API, linking the user to the people they transact with. Another could be an exchange-rate API to convert one currency to another. An API could be needed to authenticate the customer, say by checking their PIN number matches the account. Then finally, one more API could move the actual money.
Six months later, the bank wants to develop a new experience. This time, they want to create an app for travellers to take money out of an ATM in another country. Instead of having to start from scratch, the bank can use (or ‘mashup’, as we would say) two of the APIs from the first project: the API to convert foreign currency and the one to authenticate the user. Already they’ve reduced their workload. This is why an API-first approach is so worthwhile.
Why an API-first approach should be used to create experiences
There are three main reasons why an API-first approach should be considered by business. Firstly, the cost. Developing a range of APIs for one project means not having to create them again for another or, if the project/app changes, having to throw out the entire code and start again.
In most cases, the cost of designing API-first is relatively the same as developing any other way. It’s in the future where the business will save money.
Second, this also adds agility. In a landscape where technology is disrupting both workforces and consumer behaviour, that’s important. A platform can easily and cost-effectively be changed if it is designed via APIs, removing or adding to the project as simply as switching its API building blocks. A desktop application or mobile-first design that’s ‘hard-coded’ would potentially need substantially more rework, if not starting over entirely, due to its inner dependencies.
Third, developing a catalogue of APIs is a potential revenue stream. Consider Google Maps. Its APIs cover many different things such as navigation, location, directions, distances, satellite imagery and street-view imagery³. For a fee, other developers can purchase these APIs to use in their own apps. For instance, a trucking company wanting to develop an app for their drivers to use for more efficient deliveries. Suddenly the built asset, which a company is creating anyway, also becomes a saleable product.
Building for longevity
In an age where consumers are demanding personalised and sophisticated experiences with the brands they interact with, companies can’t afford to fall down with badly designed websites, apps or other customer experiences.
At a bare minimum, projects must be mobile-first, particularly with upcoming changes to search algorithms. It could mean the difference between being seen or being buried.
For longevity’s sake though, business should be thinking about building their next project as API-first, mobile-second. This will enable the best of both worlds. The usability demanded by consumers who browse via mobile, with the competitive advantage of agility, revenue and cost-savings.
