This is an exciting time for designers. Now we can rapidly design feature-rich websites and apps without writing code thanks to low-code software. However, as with any technology, we need to learn how to use it effectively in order to get the most value from it.
In my previous post I explored how the low-code revolution is changing product design. Loomery has been using low-code tools since our formation, including Adalo, Shopify, and Webflow, so we've learned a lot in the process. Here are a few ways to handle 6 common pain points when designing for low-code.
We have learned a lot along the way and want to share our experience so far. Here are six potential pain points and how to overcome them when designing for low-code.
Pain-point: Rushing into using the wrong tool
It can be alluring to dive into a low-code tool straight away and get your hands dirty, especially if results can be seen almost instantly. Yet, if you jump in too soon and choose the wrong tool, you could find yourself regretting it later.
Pain reliever: Do your research with the team first
Determine the best platform for your ongoing needs with the team before you commit. Get clear on what functionality is absolutely critical to meet customer’s requirements first, then whittle down your options. And if you find it overwhelming to choose from the hundreds of low-code options, consider consulting with experts to get a second opinion. I can assure you that taking the time to do your research upfront will save you unnecessary costs down the line.
Pain-point: Your designs don’t translate in the context of the platform
In general, low-code tools are easy to customise, either using the platform alone or with some extra development around the edges. Nevertheless, developing prototypes and pixel-perfect designs before exploring them inside the software is a risk because these designs might need to be revised once they meet the realities of the platform and you may find yourself doubling up on work.
Pain reliever: Design prototypes in the tool from day one
Low-code tools are uniquely well-suited to rapid prototyping and you can quickly derisk the project by working collaboratively within the tool to build a rough working prototype using low-fidelity designs. This is a great way to get a feel for the potential user experience, whilst uncovering functional limitations of the tool. What’s more, by doing so, you will have a working prototype to test with customers very early and this can be iterated on until launch. By testing early, you learn which design challenges require more attention, allowing you to perfect the details where they matter most.
Paint-point: You hit up against limitations of the tool you’re using
Overall, low-code tools enable designers to create imaginative and exciting products, especially when looking at more advanced tools like Webflow. However there will be times when you encounter the platform’s limitations. For example, Shopify doesn’t let you use their homepage templates on other pages throughout the site and until recently Adalo hasn’t supported apps with custom fonts.
Pain reliever: Focus on the essence of the solution and engage with the community
Often the things that we’re worried are missing from the product are low-down on a customer’s list of needs. Focus on how your product delivers against customers’ main ‘jobs-to-be-done’, rather than specific implementation details. Find hacks that help you achieve your design ambitions, you’ll be surprised by what can be achieved with some creative effort. Additionally, platform creators are listening to their communities, so engage with their feedback forums and feature request mechanisms.
Pain Point: Too many cooks spoil the broth
Due to the perceived accessibility of low-code, there is a risk that too many team members want to jump in and get hands-on with the tool. This is great but it could cause problems by creating a lot of unstructured noise and conflicting edits that slow down the development process, resulting in an unclear product. This often happens when there is a lack of clarity in responsibilities within and beyond a product team.
Pain-reliever: Get clear on team roles and launch early
The easiest way to resolve this challenge is to start the project with a conversation about roles and responsibilities. Decide who will have access to the data, systems and layouts behind the final product and who will have edit rights. Keep this number in the low single figures. If you do want a larger group to be involved in prototyping, create multiple environments that don’t impact the live product.
Secondly, as soon as you have created a viable product and are clear on what you’re looking to learn, go ahead and launch. Early launch allows you to gain data-driven insights into your customers, based on real world behaviour, reducing bias decision making, helping you focus on the areas where you can deliver the most value.
Paint-point: You focus too much on the short term and forget to think big
When designing and shipping products quickly, it’s easy to forget to make time for the team to come together to apply big picture thinking to customer and business problems. In the absence of this innovation time, the company may be missing out on opportunities to do things differently and better by looking beyond what's directly in front of them.
Pain reliever: Fall in love with the problem, not today’s solution
Get clear what problems you’re trying to solve for customers and the business, then obsess over them, not the solution that’s out in the world today. Making this distinction will help keep clear the difference between what you’re shipping right now and the bigger picture for the product.
Take time to do this early and often, continuously sharpening your understanding of the problem. This will inform both your short term decisions and your long term vision.
Pain point: You’re sacrificing quality for speed
Often the temptation with low-code is to rush to get a product out, however, as with any software, it must be handled carefully, and quality should never be sacrificed for quantity. Customers evaluate digital products based on their experiences with them, both positive and negative, so any product that misrepresents the brand or does not perform desirably will be detrimental over time.
Pain reliever: Carefully balance speed with quality
A high quality product is the goal of any project, so devote time to it, get your team involved, and appoint a chief quality officer in the team to be responsible for pushing back if the balance tips. Also, conduct regular user testing and customer feedback sessions to ensure customer satisfaction, provide customer feedback mechanisms wherever possible and track the data carefully.
It’s clear that while low-code makes it possible to move faster than ever, all the core principles of great product design still apply. Working with these tools we can spend more time focusing on customer experience, by launching early, gathering real customer feedback and iterating right away.
To thrive as product designers in this new reality we need to be part of the process of choosing and stress-testing the tools we utilise. We should be careful not to get attached to any particular solution and limit our thinking, but to always be creative in pushing the tools to their limits. Furthermore we must be active in the process of creating with the tools, remembering that even though we can move fast we should always pause and ensure we are continually creating high quality products.
Now that you’ve read my tips and tricks from working on the front-line of low-code design, I’m interested to know your opinions - what tips would you add to this list for brilliant results with low-code design!? Feel free to get in touch firstname.lastname@example.org or tweet us @LoomeryTeam.