Out of the box 📦
Out of the box 📦
How to get the most of out plug-and-play technology
👋 Welcome to The Navigator. A newsletter about people, psychology and design for business leaders who want to make meaningful change. I’m Sarah Ronald, and I write this newsletter with the Nile team. If this email was forwarded to you, you can subscribe to receive it in your inbox every couple of weeks. You can also read and share this post in your browser.
Lately, I’ve been hearing from clients working in the financial services sector who’ve been disappointed by out-of-the-box technology. They’ve also had digital transformations not go to plan. These two issues are connected. Let me explain how.
It's tempting to seek out plug-and-play options, but as many business leaders quickly find out, out-of-the-box is never truly out of the box. Why? Because people are involved.
People are part of cultures and rituals in organisations; they have ways of working and team-specific language. They can often be the reason many transformations stall – or even fail. If this vital component – the users – gets overlooked, then adoption won’t be achieved.
How then, if you're a CEO making a change, or a CTO implementing new software to bring essential efficiencies to your business, can you ensure that you avoid this potential pitfall?
To help answer that, I’ve invited Callum Ritchie, who leads our UX/UI practice here at Nile, to share his views having worked across many platform-based transformation programmes. Here, he shares his thoughts on no-code platforms and some practical tips that we've learned from many implementations over the years.
My best wishes as you navigate your week,
–
How to get the most out of out-of-the-box
By Callum Ritchie
I’m not someone who rejects the new, or some purist who feels threatened by any kind of industry advancement.
In fact, I’ve seen first-hand how out-of-the-box platforms can act as outstanding accelerants for product teams. Teams can build fast, launch quickly, and iterate easily.
But in all the excitement of these new tools, some teams are beginning to make predictable and easily avoided mistakes.
First: what is low-code / no-code?
Using a relatively simple set of elements and components, you can build powerful systems and products often without writing a single line of code.
Before the rise of low-code / no-code, building and tailoring complex systems would require a full development and design team. But now you can get almost all the way with teams with little to no technical knowledge.
Platforms like Outsystems, ServiceNow, Pega or Mendix, allow developers (or ‘citizen developers’ as they are becoming known) to quickly construct systems like they’re building out of Lego: using pre-existing components and templates.
These platforms are here to stay. By 2025, Gartner predicts 70% of new applications will be built using low-code / no-code platforms. This is up from less than 25% in 2020.
For the purposes of this newsletter post, from now on I’ll simply refer to both low- and -no-code platforms as simply ‘no-code’.
The benefits
As you might imagine, no-code brings exciting advantages tied to the use of these platforms. Naturally, these include:
Increased speed and agility
Increased scope for innovation, with stakeholders closer to the build
Lower dependency on legacy IT functions
Overall, it’s a good thing. It’s opening things up. Commoditising the space a little, and helping teams focus on what matters: the solution, not the technology. And for the avoidance of doubt, I’m absolutely in favour of such platforms.
But I’ve seen some worrying patterns emerge.
With Nile, I’ve been involved in projects that have been no-code ‘rescue and recovery’ work. Some of our clients hit snags with their no-code platforms, and need help to navigate out of them.
On each of these projects, I saw similar challenges. And I have a hypothesis.
Teams often open up that beautiful no-code box and gasp. Suddenly creation is easy. It’s like playing with Lego. “We can build ANYTHING!” they whisper to each other.
And in their excitement, then they do. They build. Anything. No designers, little research, just rapid assembly.
It’s unsurprising, then, that the first thing they build isn’t usually the thing that the user wants or needs.
The issues
Here are some avoidable issues I’ve seen:
Incoherent and disjointed user journeys: Lack of proper planning and design can result in confusing and disconnected user experiences, leading to high drop-off rates and frustrated users.
Insufficient problem prioritisation and focus: Teams may spend excessive time solving incorrect or low-priority problems, diverting resources from more critical areas. This can lead to increased costs and technical debt in the long run.
Generic and low-value outcomes: Rushed development without careful consideration of user needs and context can result in generic, one-size-fits-all solutions that lack unique value and fail to attract users.
Scalability challenges: As user demands and system complexity increase, poorly planned solutions may struggle to scale and performance may be hindered.
Negative brand perception: Poorly designed solutions or solutions full of bugs can harm the brand image, erode trust, and negatively impact customer satisfaction. Users may perceive the organisation as unreliable or unprofessional.
Language and labelling aren’t provided out-of-the-box: Whilst many components and templates are available out of the box, clear and intuitive language and labelling are something your team has to provide. Often a solution can fall down as a result of poor signposting and copywriting.
Overlooking system integration points: Integrating with other systems or platforms is often crucial for a holistic solution. However, when hastily rolling out low/no-code solutions, product teams may overlook the necessary handover points.
Reinventing the wheel: Instead of leveraging existing solutions and best practices offered by the low/no-code technology, teams sometimes reinvent the entire solution from scratch. This leads to wasted time, effort, and resources, as well as missed opportunities to benefit from established patterns and functionality.
These issues are all avoidable.
One reason is that traditional development typically has robust design requirements, which can be overlooked in no-code projects. This is because there are fewer hurdles between an idea and a product in no-code development. Teams can "go with their gut" more often, without having to test their assumptions.
As a result, some key steps are being discarded. This can lead to products that are built quickly but are not what users need. They may have poor user experience or not actually do the thing the user needs them to do.
How can you avoid these issues?
The answer is simple: strengthen the role of research and design within your no-code projects. This means involving designers and researchers early in the process – and giving them time to do their work. It also means making sure that the design process is collaborative so that everyone involved has a chance to contribute.
Regardless of the change method or skillsets, there should be team members aligned to and responsible for working one sprint ahead. Doing so means you can explore and validate plans with users in ways that allow them to contribute.
Put simply, by including users in the planning process, you can better understand their needs and ensure that the changes are beneficial to them and, in turn, will help you deliver on your business’s strategic goals.
That's what design is really good at: understanding context, making sense of people, and embedding it in new technology so that the technology better serves them.
Increasingly, businesses are serving a very broad customer base. Inclusivity won't happen by accident. It will happen by understanding people and aligning their needs, rituals, and behaviours with the out-of-the-box technology.
As long as tech serves the business, people need to be included in the creation process. Design methods identify new and often previously unknown ways to add value from the technology and subsequent data. That’s how you use it seamlessly – almost straight out of the box, you could say.
Five guidelines for working with no-code
Remember, "simple" doesn't mean "easy." It takes time and effort to do things right. But if you're willing to invest in research and design, you'll be more likely to create successful no-code projects.
To help, I’ve created five simple guidelines that I bring to every no-code project team I join:
Ensure a service designer skillset is on the team to help you think about the solution holistically.
Validate the problem being solved, and the target journey(s) before focusing on the visual interface.
Think about how your brand can help elevate and differentiate the experience.
Be consistent with your other systems.
Closely manage custom UI configuration to support scalability and consistency.
These help to remind teams that just because development has changed, the need for solid design is as urgent as ever.
There’s a lot more to say about these five rules - read my post on Five guidelines for working with no-code platforms where I go into more detail about what each of these rules means.
Nile News
This week, we're at the DBI Summit, which is being hosted in Scotland for the first time. DBI is a consulting network we co-founded in 2013 that brings best-of-breed consultancies and independent specialists together to solve key strategic and operational challenges for businesses.
Dag and I attended Panmure House (the last residence of Adam Smith), for a lecture by Glory M Liu. She'd flown in from America to share her research and book, Adam Smith’s America, on Smith’s hold on American economics.
Originally published in 1776, Edinburgh Adam Smith’s The Wealth of Nations has influenced many leading figures over the years and continues to do so. Smith was about asking the big questions of the time, with a view toward creating a balanced and fair society.
I wonder then, what he would make of the emerging significance of Artificial Intelligence. Asked this very question, Glory suggested he might ask, who is the technology benefitting and who is missing out? How might it perpetuate existing inequalities, rectify others or create new ones? Smith would likely also ask who has the power to make the policy that governs AI, who is making the law? And are they making it to ultimately benefit themselves just like Merchants did back in the 1700s?
Lots of food for thought!Struggling to control your attention? Read Nir Eyal’s Indistractable: How to Control Your Attention and Choose Your Life. The brilliant recommendation comes from Paul Pester, given to us at a recent Nile Changemaker Breakfast
About Nile
Nile is a Strategic Design team that helps deliver human-centred change in highly regulated industries. Our methods engage employees and customers with new technology and ways of working. Our outcomes help save money and improve business performance.
If you think we can help your teams, reply directly to this email (they come straight to my inbox), or reach out to someone specific via our website.
Thanks for reading! 🚀