The Importance of Balance in Software
Right now, there’s a lot of excitement about the potential of integrating AI in software. At Smudge we believe that designing and developing software is a delicate balance between the commercial goals of your business, the needs of the end user, and the possibilities (and constraints) technology presents.
Because everyone's so hyped about AI, design conversations are in danger of swinging overtly towards technology alone. But, if you want your projects to succeed, it’s vital to remember that business needs and human needs are just as important as the tech. Technology isn’t a silver bullet or the answer to all your organisational problems.
A great example of this was when ATMs first appeared. They were built to make cash easily accessible outside of bricks and mortar banks, and they certainly achieved this, but inadvertently created another problem. The machines were programmed to dispense the cash first, and then eject the bank card second. Human nature was to take the cash and walk away, task complete. This frequently resulted in cards being left behind, meaning lost cards, inconvenience to the customer and additional costs for the banks to replace cards. It took a while for the machines to adjusted to better align with human behaviour, by ejecting the card first and then the cash.
Balance beats compromise
At Smudge, we try and sit at the intersection of design, business consultancy and software engineering. In every project we strive to balance business needs, human needs, and tech.
People often call balancing these three things “compromise.” At Smudge, our take is this is less about compromise, more about understanding the intent of your project and the value your business wants to create, so you can make wise decisions in service of those goals.
Our balanced approach helps you to derisk your software investment. This article explores some ways you can bring balance back to your software projects by ensuring you consider both your user and business needs. We examine the risk when you don’t consider your users’, how to use testing early to ensure a successful outcome, and the wisdom of starting small.
You'll struggle to achieve balance if you don't value your users
When we’re looking to design software solutions, sometimes there can be too much tension balancing user needs with commercial imperatives. If user needs and business needs are too fundamentally different, we can struggle to get a project to work.
We’ve seen major software projects fail because user experience wasn’t at the heart of the project and key stakeholders resisted user testing and ignored user feedback.
If your users’ needs and preferences and your commercial imperatives for a project are at odds, you may struggle to bridge that gap. Ultimately the success of a software solution comes down to how well it’s adopted by your frontline users.
Strong visions can skew balance
We see two common approaches to software development.
- Projects driven by a singular vision – usually that of a business owner or senior leader.
- Projects driven by research and user insight.
Frequently people come to Smudge with a particular idea for a software tool. They’re very clear on what they want to build. They think if they make their tool, people will adopt it. But they haven’t done user research. Assuming you know how your users will think, feel, or behave is unwise if you want your software project to succeed.
Compare that one-sided approach to the more balanced way Smudge works with long-term partners. We often suggest ideas to the businesses we work with. But proposing an idea doesn't mean it will be implemented. First we investigate if the idea has merit. Will users embrace this new feature? Does it align with our partner’s strategic focus for improvement? How much will it cost? What return can our partner expect? We do user research and make a business case before we build anything new.
Test early in your project to make sure your balance is right
Research is vital to understand your user and business needs. But sometimes what people say and what they do are two different things. A critical step is to test your software idea with your users to check you’ve got the balance right between business needs, human needs, and the tech. This is an area where AI brings real benefits to the software development process, making software prototypes far more affordable and accessible.
Some businesses still see early-stage testing that fails as throwing budget away. But if you don’t test, you risk far more money. Smudge has been brought in several times to retrieve multi hundred-thousand-dollar software projects that failed to achieve adoption because they weren’t tested enough early on.
Tim Pitcaithly, who leads our strategic advisory and prototyping team recently wrote an article with tips for planning your software investment. Tim asks, if you're not happy to spend $20,000 to test an idea, knowing that it might fail, why would you be happy to spend half a million dollars, and still risk failure? Minimise risk by starting small and test early.
Start small. You can’t judge balance yourself
You won't really know whether you’ve achieved a balance between user experience, business goals, and technology until people are actually using your tool.
You may think you’ve made something pretty good. But you won't know you’ve succeeded until you've got your tool into the hands of your users. That’s because (most of the time) you're not the audience using the tool. And by the time you’ve been working on a tool for a while, you’ve lost your ability to be objective.
This is where building your Minimum Viable Product, or MVP, comes in. The goal of an MVP is to validate your idea by getting something simple into your users’ hands as fast as possible. Starting small is not revolutionary. It’s worth remembering that many of the most popular and successful digital products of our time started out tiny. Facebook was born in a dorm room. Apple, Google and Amazon were founded in garages. We admire the oak tree, forgetting it was once an acorn. It’s the same with software innovation.
Three questions to bring back balance
When creating a new software tool, we ask ourselves these questions:
- Does the solution demonstrate empathy for the people who will use it? Will they enjoy using it? Will they understand how to use it? Does the new solution deliver on the intention to improve on the existing solution or will it solve the problem for the user?
- Is the solution commercially viable? Does it deliver on both the short- and long-term needs of your business? Does the solution accurately reflect the strategic intentions of your organisation?
- What's the role of new technology in your software? Is your tool compatible with your existing technology landscape and support the technology roadmap of your organisation? How will you make your tool manageable to maintain?
If you’d like help balancing your business needs, user needs, and the ever-expanding opportunities of the tech landscape – while working within the constraints of your existing tech ecosystem, we’re here to help. Let’s talk, or contact Tim.