I think Apple has done a lot more for design in computing than people think. I know, that’s a crazy statement isn’t it? There’s an on-going fascination with their hardware design and obsessive attention to detail, but Apple has done more for the industry than design beautiful hardware and amazingly intuitive software. Apple has focused maniacally on the users. And that attention to detail has made a big impact on how they approach complexity. One proof point of their success?
Children, grandparents, business professionals and high-end software engineers all love the Mac. That’s one crazy community.
The reason? I believe it’s because they engage with different users at different levels – at the right level for them to be amazingly productive. So here are a few design principles I see in how Apple approaches software and operating system design that I think everyone can benefit from.
1. Build on a rock-solid foundation
Though many people don’t know this, Mac OS X is actually based on UNIX; a tried and tested operating system that has worked for enterprise IT for decades. A bit crazy really. That super cool modern user experience sits on top of one of the oldest operating systems. Why? Because it just works… always.
But more than that they put in place a foundation of strong configurability, API access, security and enterprise readiness. This left their design team lots of time and lots of budget to focus on user experience and design, but without sacrificing quality. Result? It’s super easy to use for a novice, but developers love it because it works the way they need and expect.
When I look at many agile development platforms I see this mistake made again and again – agile meaning “quick and dirty”, not designed to last, but built for change. Despite making people super productive with “no code” or “low code”, the platform MUST have a solid foundation that will pass the test with your CIO and enterprise architects.
Agility without a solid foundation is just plain wobbly.
Anyone can produce applications quickly – it’s the “how” that really counts.
2. If it’s straight-forward to understand, make it straight-forward to do
And the inverse of that, if the concepts are complicated, then it’s OK if it’s more complicated to achieve. Though they do get an undue amount of abuse, you can see the difference in how Microsoft approached Windows. You can do WAY more using point-and-click tooling on Windows than you can on Mac OS X. There are dialogs for pretty much every and any setting. But therein lies the problem. Though you can simply tick a box or select from a list of menu options, the amount of understanding you need in order to simply know which box to tick or option to select is huge. The fact that it’s in a dialog is actually a distraction at best. It needs a qualified professional to act. But qualified professionals don’t need to wade through hundreds of point and click dialogs when they can simply enter in a simple command using a terminal window. Remember, they do this kind of stuff all the time!
The impact of this decision? Point and click configuration options on a Mac are simple and clean. Users feel comfortable with the concepts being presented to them. Need to do something complicated? You’ll need to enter commands into a terminal – but chances are – you’re a developer or sys admin and that’s your preferred approach. With Windows? The business user has no idea what they’re clicking and developers have no idea where to find anything. Both are in foreign territory!
This is a huge omission in many agile platforms. They forget that it doesn’t matter if something can be “point-and-clicked” if conceptually it’s way too complicated to understand.
No matter how many UX designers you throw at it, you’re never going to make polymorphism simple for business users.
So when you’re looking at an agile platform, make sure they understand this. The reality is that productivity is about engaging with the right users to do the right things. Allowing users with the right knowledge to act in a way that is familiar to how they work. It’s not about “one size fits all”.
3. Finally, don’t walk users off a cliff
Making things simple should not mean compromise. When you look at Apple software and Mac OS X, you can see they’ve paid a huge amount of attention focusing on the features that the majority wants. However, and this is super important, they have not limited the software or their operating system to ONLY support the simple things.
For example, I can set permissions on folders simply by ticking a box. But, I can do the same using the command line. And using the command line I can set much more granular permissions to extend the permissions I set using the tick box approach.
Though this may seem obvious, it surprisingly isn’t for much software. For many platforms, you can build stuff quickly using tooling, but when the tooling fails, you need to re-do all the work you did, but now in code.
That’s what Salesforce calls the “declarative cliff”. It’s the point where you can’t manage the complexity through declarative (or point-and-click) tooling and must resort to code. But rather than simply coding around the work you did using the point and click tooling, you must re-do all of that work in code. The result being that you lose the ability to configure everything simply.
You have, effectively, walked off a cliff. Simplicity and agility are gone.
For quite some time, vendors have berated code. For example, vendors such as Pega Systems or Appian have talked about “no code” development. But the reality is that this is a silly idea!
For all the reasons above. Because sometimes the best way to manage complexity is to use code! It’s the right way to engage with users to get the job done. Sometimes, you need a developer to ensure the project is successful and code is the absolutely best tool for the job. But, critically, your platform must not be “no code” or “all code” – it should be able to manage the transition from stuff you can do quickly and easily with “no code”, but also extend seamlessly into situations that require code without needing to throw anything away. In other words, we’re seeing the rise of “low code” platforms 🙂 Everyone maintains agility – the users that point and click, and the developers that code. It’s easy to say, surprisingly difficult to achieve!
So why does this interest me so much? Well, I’m all about enabling customers to get more from technology. About making technology more accessible, more powerful and more engaging.
That’s meant I want to see software development “democratized” so business people can build software – not just use it. Or put another way:
If we can truly bring the business into the beating heart of software, to drive the value, the meaning, and the purpose, amazing things will happen. If you then allow developers to radiate out from that beating core by extending, enhancing and crafting, truly stunning things can happen.
Games do truly get changed.