Five guidelines for working with no-code platforms

Building on my previous post about the relationship between low- and no-code systems and design, I’ve pulled together five key guidelines to help keep design front and centre.

Basically these are the five key things which I’m continually talking to teams about when working with low- or no-code platforms:

1. Engage service designers from the start to help you think about the solution holistically.
2. Validate the problem you’re solving, and the target journey(s) before focusing on the visual interface.
3. Think about how your brand can help elevate and differentiate the experience. 
4. Be consistent with your other systems.
5. Closely manage custom UI configuration to support scalability and consistency.

Applying these principles makes sure that:

• User task success increases, while task completion times, error rates, and support requests decrease. All thanks to validated and cohesive user journeys.
• Brand perception and adoption increases, thanks to a higher quality and differentiated offering, consistent with your other systems.
• Development time, cost, and technical debt decreases due to design efficiencies and higher quality research and discovery activities. 
• Teams make better decisions around technology, and reduce the rework required by working with prototypes before committing to a build.

It’s not rocket science. But something happens when teams get their hands on a DIY platform; process and common sense can go out the window. This is my attempt to inject a little bit back in!

Read on for more detail…

Engage service designers from the start

Involving designers throughout discovery maximises the quality of your proposition and user experience.

You should think of design holistically – where designers play an integral role in the  discovery phase to help define the problem we’re solving and what might solve it. From there, design helps rapidly prototype and test possible solutions before any development is started. 

This allows us to optimise not only front-stage touchpoints, but also back-stage actions that support (but are not visible to) the user.

Involving designers early helps you know your users and brings clarity that will help you avoid technical debt and rework later.

From our experience, introducing designers too late in the process leads to significant technical debt, and a weakened end product. The impact design can have is greatly reduced the later it is brought in – this is often referred to as the ‘lipstick on a pig’ model. In some scenarios, when building a system using a no-code platform, it can be easy to jump straight in due to the fast and comparatively easy nature of no-code tools. Whilst tempting, try to resist this urge and rather leverage design research to test your assumptions. Ensure you really understand your users, their challenges and their desired outcomes before diving in. Having a quick thing is not better than having the right thing.

Design research will enable more confident technology and vendor decisions.

Spending a little extra time upfront ensures you have a clear vision to work towards and keeps you focussed on providing real value by solving the right problems. It also ensures you make the right vendor or platform decisions that will support your vision going forward.  

I’ve experienced vendor lock-in issues on a number of programs, and mine aren’t isolated examples –  

In a recent example, we were brought in to support the design of a Minimum Viable Product (MVP) solution after the technology had been chosen and the key journeys were already built (to a poor standard owing to the lack of design support). 

When introducing proper discovery and qualitative research at this late stage, it soon became clear that the chosen technology, in its current configuration, would not only struggle to support the best-in-class target state, but also cast doubt on the platform’s ability to support a valuable MVP. 

Knowing this up front, and with a better understanding of end users, it would have allowed for higher quality requirements, and more technological certainty when selecting the platform to build upon.

Validate the target journey before focusing on the visual interface

Focus on validating conceptual journeys with users.

Most of our clients working with no-code products are trying to build something particularly bespoke or complex for their users, and do it at pace.

But now that building the product has become much quicker and easier, I see teams choosing to plough forward without thinking deeply about the user journey, or validating it beforehand. 

With prescriptive, out-of-the-box user flows, we have seen first-hand that it can be tempting to omit qualitative design research from the process and simply validate your concepts in focus groups or demos.

This is perhaps due to an assumption that out-of-the-box flows are ready to be delivered as they have been tried and tested. But, it is important to remember that your users are unique, as is the problem you are trying to solve for them. 

Prescriptive workflows offer a great starting point and speed up the development process. However, proper design research and user testing always needs to be included. Design for humans first, not technology.

Engage end users regularly, and make sure whoever designs the research and facilitation is trained in discovery techniques.

Design is more than how something looks. It’s about what is needed and how it works. Without this understanding it can be tempting to exclude designers from discussions when there isn’t an obvious visual element. 

Most designers have experience in research, facilitation and discovery techniques. So any designer worth their salt will add huge amounts of value in these conversations and make sure the end experience is user centric. 

In this context, ‘design’ should not only be concerned with the application of your visual identity and user interface, but also the intangible ‘feel’ of your user experience. 

So remember – design does not always have to include a visual element.

Pre-designed component libraries don’t reduce the need for a designer: they elevate the role.

Visual design still plays an important role and many no-code configurable solutions provide a range of templates and components to help you get started.

Using these available components – plus your own design system (which should inform your other systems) – we’ve previously created platform-specific versions of master component libraries to allow designers to realise high fidelity concepts.

But these components and templates are only ingredients. It’s like having a fully stocked kitchen. Almost anyone could bodge together a basic cake, but it takes skill and experience to create something which someone else might actually want to eat!

In the same way, careful consideration needs to be taken when piecing components together into cohesive user journeys and interfaces. A designer can help you do this in the best possible way. 

Looking at the component libraries and guidance offered by many platforms, it can be tempting to think that a dedicated design role is no longer required. But a component library does not replace a designer. It elevates their role.’

Leverage the brand to differentiate experience

Be wary of experience homogeneity.

Using certain no-code platforms can lead to an end product that may look and feel very similar to that of a competitor. 

If two systems are solving the same problem in the same way through two interfaces that also look similar to each other, it may be hard for customers to differentiate between the two.

Think about brand in everything you do.

Experience homogeneity isn’t always a bad thing. Sometimes it makes things usable and familiar. In such cases, your brand needs to provide the memorable differentiation. 

This goes far beyond the sole use of visual brand components such as logos and colours. Your brand personality traits can be reflected in your tone of voice, content, information architecture and navigation.So while you may be using similar UI components and workflows, you can still come across as authentic and unique. If your users can hear your brand voice coming through loud and clear, the experience they get will feel different as a result.

Harness the speed and agility of no-code platforms by experimenting continuously.

Although there can be some limitations faced when using no-code solutions, they come with significant advantages to help you get ahead of the competition. 

They present the opportunity to continuously experiment and innovate within constraints in a cheaper and faster way than ever before. 

Additionally, individuals from other business areas (i.e. non-developers or non-IT personnel) can now contribute to this process.

Whilst this is positive, the right processes still need to be put in place to ensure single-person silos don’t form, and lower quality/conflicting solutions do not end up being released.

Be consistent with other systems

Bring your product in line with your ecosystem.

As I’ve already talked about, no-code systems can end up looking fairly similar to other systems built with the same platform. Whilst some do this better than others, it can be difficult to get the level of control required to deliver your ideal solution – especially from a UI standpoint.

Discrepancies across a suite of products or systems can make it unnecessarily uncomfortable for users to move between them. 

If users are used to interacting with a particular feature (e.g. a date-picker) on System A, it can be frustrating for them if they have to re-learn how to do this differently when using System B. 

This shouldn’t be less important for enterprise or internal systems v.s consumer systems. When these small inconsistencies are viewed collectively they can have a detrimental impact on how users perceive you.

Be mindful of the handover points between different systems.

The handover between systems is also something that is easily missed.

For example, you might have one team working on the ‘main’ product, and a second team looking at – say – the help & support ticketing system for the main product.

The process and user experience of moving between the main product and the support product may not have been assigned to a team. It could easily fall by the wayside. 

Supporting these handover points between your systems is vital to your overall user experience, and something which a design lead should have remit to assign focus to.

Closely manage custom UI configuration

Keep custom UI component configuration to a minimum.

You may be tempted to configure the appearance of the UI components on an individual basis. In my experience, keeping custom configuration to a minimum helps to limit inconsistencies and scalability issues.

Most solutions will have out-of-the-box components available to you. By all means update these at foundational level to include your brand colours, iconography and typeface. 

But remember this: every custom component configuration decreases the benefits of using a no-code solution in the first place.

Updates to components should be communicated and shared across teams.

It is vitally important to ensure that everyone has access to, and is using, the same, latest version of a component or asset (e.g. icons or logos). 

Designers have a role to play by ensuring that design libraries (e.g. Figma) are kept up to date, and component usage guidelines are made available to developers. Direct communication between designers and developers at this stage is key.

Establish a shared process for updating and sharing updates to components, and for design sign-off.

Design sign-off is an important step when using no-code solutions. In many cases, it may not be possible for a developer to realise your designs exactly as you had intended, so working together with the developers to arrive at a suitable solution is recommended. Mock-ups are your friend here as they will reduce ambiguity and enrich your user stories. Although, not everything requires a mock-up and you want to avoid mocking up screens for changes that can be informed by documentation, or something that has been done elsewhere (leveraging consistency), or for simple things like small wording changes.

If this is a topic that interests you, please get in touch with myself or the Nile team.

Sign up to our newsletter, The Navigator, to be notified or similar content, or meet ups.