Consider These 3 Things When Designing Business Software Products
I used to dream of designing aesthetic software products and experiences. Only a short while ago, nothing would have given me greater satisfaction than designing a software product and having an end-user tell me “wow, I just get this”.
But after working 2 years for an ERP software company, and seldom meeting with end users, I realised something critical:
Obsessing over aesthetics is a vain undertaking.
Did part of your soul just cry out in denial? Mine did when I came to this humbling conclusion. It hurts, but reality remains unchanged.
Design is about achieving other people’s goals, not yours.
Software Is Designed In An Ecosystem
Everyone in a technology company has a role to play in software design. In fact it’s not just people in technology companies that design products, but markets, partners and governments through their pressures and demands.
Consider ERP SaaS products — they reduce software support overhead, shift liability onto vendors and charge customers by subscription (often according to their number of user licenses, features provided, transactions made etc).
Although this allows vendors to bring in consistent revenue, vendors transitioning to SaaS products must invest more time in security, infrastructure, data privacy and general compliance. They also bare more legal and reputational risk than ever betore.
Tighter constraints on the vendor lead to features which are less flexible than on-premise solutions (often to the lament of staff), but secure nonetheless. The value added is not always for them — here the company purchasing the software is better protected.
You Can Train Staff To Use Software
Ensuring staff can be adequately trained in the product puts our effort into perspective. Sometimes stakeholders will champion your product and overlook its shortcomings; many will learn enough just to get by. Good change management can go a long way.
When new software is implemented, all companies go through some productivity losses, regardless of their size or who is guiding the change. The benefits won’t always be realised upfront.
Ultimately, we need to realise software exists to serve a purpose and is never really “done”. We must hold the tension between the needs of our business and the needs of our customers. Change is hard and resources are finite.
Understand The Difference Between Customer Wants And Needs
When gathering and analysing product requirements, discerning between what customers want and need is crucial. Customers will tell you why they think something is important, but you need to understand the impact. They also tend to describe solutions rather than requirements.
The product may do 80% of what they need, but 30% of what they want. Maybe your product covers what they need, but not the way they expected. Sometimes educating customers is enough to eliminate a requirement. In situations like this, the ability to empathise and test their reasoning can prevent over-prioritising of “nice to haves”.
If this is a crucial customer, this may also influence the final decision. You may decide to enhance the software to work as they want, but how does this impact the rest of your customer base? Maybe the money they pay you is worth it.
Even if you don’t decide how the issue is resolved (or agree with it), knowing why you’re designing things a certain way is important. Always act with humility regardless, you aren’t always the decision maker.
Conclusion
This is a snapshot of my learnings from 3 years working on business software in a variety of different roles. To summarise, my focus has changed from “delivering aesthetic products and experiences” to designing with a broader view of the many forces that design business software.
