Making good software isn’t hard. But in the race to generate more revenue, businesses sometimes lose sight of what’s important. In fact, sticking to a few basic rules can help you grow your bottom line.
In this three-part series, I explain how the golden rules of software development will help you create software people love so your business thrives. I already covered the hardest rule (Know Your User) in part one. Here in part two, we’ll explore the importance of creating a seamless experience, both in terms of consistency and functionality.
Rule No. 2: Provide Consistency
Businesses don’t have one digital presence anymore — they have many. They interact with customers over email, social media, their websites and live chat, just to name a few.
But too often, it feels like the left hand isn’t communicating with the right. Your bank emails to say you’re preapproved for a new credit card based on your spending level. But when you click the link, you’re asked for your name, address and social — information you’ve given your bank countless times. Instead of the site pulling up the data from some central location, you have to enter it all again. You’re the customer, but you feel like you’re doing the work.
Or you call your internet company, provide your details and describe your problem to the automated system. After 20 minutes of being put on hold, you finally talk to a representative — only to have them ask you again for your account number and the nature of your problem. If you’re unlucky enough to get passed to another service tier, you go through the process yet again, Groundhog Day-style.
Why can’t your service provider pass a few pieces of data from department to department? The answer is depressingly simple. You feel like you’re dealing with six different organizations because you basically are. Large enterprises are organized into silos that don’t talk to each other, and as a result, they can’t act with a single voice.
Under the hood, each of these customer touchpoints relies on different systems that are run out of separate organizations with their own P&Ls, tech teams and management. From their customers’ point of view, however, it’s just one company that can’t get its act together.
Delivering a consistent customer experience across channels (an omnichannel approach) isn’t easy, which is why so many organizations fail at it.
Businesses need to start by establishing common visualization (such as branding and icons) and interaction standards (such as the order in which information is presented) across touchpoints. At the same time, customer choices must remain appropriate for the specific channel (for example, using the “hamburger” version of menu options in a mobile context, or common phrases in an automated voice system or a chatbot).
The trickier part is creating logic for those inevitable scenarios when there are multiple data sources serving up conflicting information. Maybe you signed up for your checking account with one email address, but set up your mortgage loan with the same bank using a different email address. Great omnichannel companies manage this by creating business rules to coordinate data, resolving duplicate information and optimizing business resources.
Providing seamless experiences is harder than it looks. But customers don’t care how hard it is. Your competitors are just a click away, so they’re not inclined to cut you any slack. The only solution is to do what it takes to give them the same service in every channel, on every device.
Rule No. 3: Make It Work
It should go without saying, but software has to, you know, function. In this era of moving fast and breaking things, this basic principle sometimes gets overlooked.
Last year, Chipotle celebrated National Avocado Day with a coupon code to add free guacamole to any order. The fast-casual Mexican food chain apparently didn’t anticipate the demand from avocado-crazed Americans, who swamped Chipotle’s web servers, making it impossible to redeem the offer and forcing Chipotle to extend the promotion and issue an apology committing “to making our digital options bigger and better in the future.”
Embarrassing, for sure. Luckily, these are the sorts of problems software engineers love to tackle since there are usually clear right answers.
Before you launch a new product or feature, consider this basic checklist:
• Push product performance to its limits. How fast can you execute a single transaction? Can your system handle not just normal daily volumes, but the kind of Black Friday or Prime Day peaks that might make or break your business?
• Rehearse, rehearse, rehearse. How much have you practiced the production release? Are you completely assured the rollout will work flawlessly? You can reach that confidence by automating the deployment process, making the release you’ve practiced as easy as pressing a button.
• Verify accessibility. Sure, your software works perfectly in all the most common browsers and devices, but have you considered the experience for a blind person using a screen reader? How about for someone navigating with a mouthstick instead of a mouse? Even if you don’t know the particular challenges a future user might face, applying the principles of accessible design can actually improve the logic, function and performance of your site for all users.
• Expect the unexpected. What happens when your user enters information in an unusual format? Will they get a hopelessly cryptic error message or a helpful, maybe even humorous instruction on how to try again?
• Document mistakes. Speaking of the unexpected, are you automatically tracking errors and building in better solutions over time? Anticipating what might happen after your software escapes the safety of your test lab is critical. You’ll need to design it to respond gracefully to what you didn’t anticipate and flag those errors for future improvements.
Next Up: Designing Software That is Both Secure And Delightful
Easy-to-use software is essential. However, even the most user-centric and high-performing product is worthless if it exposes customer or corporate data or its design doesn’t engage users. I’ll cover that in the next and final article in this series.