5 low-code enterprise application mistakes and how to fix them 

Low-code is powerful technology that enables development teams to build applications without complex coding. This includes the user experience (UX)—which often determines project success or failure. Ultimately, low-code should allow your organization to drive better business outcomes, allowing your teams to focus on deeper, more complex UX problems and the needs of your users.  

Many low-code solutions are burdened by what I see as a common mistake: prioritizing user interface (UI)-first app building. Often the app building process begins by the dragging of UI elements onto a blank canvas and then applying data or actions to them— thus embedding essential business logic into the presentation layer. When application building begins this way, the power of low code turns against your application. Ironically, by starting with the UI, you end up creating poor user experiences.  

To clarify, “UI” is technology—the pieces and parts of a user’s experience, while “UX” is the complete experience, most critically a user’s mental map of what they are doing in the tool, and how they can get their work done. Think of UX like a kitchen with everything stored behind cabinet doors (and think of those cabinets with ladles and mixing bowls as the “UI”). The only way you can efficiently use your kitchen is if you have a strong mental map of where all those things are located, and your kitchen is laid out in an efficient manner (that is your “UX”).

UI should be a tool for achieving ideal UX and ideal business outcomes, not an outcome unto itself, just as kitchens and kitchen utilities are to help one prepare food. But when you build application functionality via the UI, the UI (by default) is determined first and is therefore prioritized over core UX (the users’ mental map of what they are doing, and where on screens to go to succeed in their work). Core business outcomes should not be secondary to UI.

Let low-code developers and business architects focus on what they do best: model the business logic.

Pega’s low-code platform allows the delivery of high-quality effective user experiences faster by building with pre-configured assets designed specifically around our core intelligent automation and case management features. By utilizing a templated, complete UX system like Pega Constellation, businesspeople can take full advantage of low code to model logic, processes, and data.

Pega has been low-code for decades. We are the original low code enterprise tool and we’ve learned a lot in our journey. These observations reflect the reasoning of our own shift towards truly configurable “Center-Out” software.

Here are 5 reasons  why UI-first app building is bad for business: 

1) UI-first app building means your organization is backing into business logic. That’s backwards!    

As a UX professional and a long-time manager of UX designers, I often see inexperienced designers rush to “thinking with UI” — in other words, scrambling to craft the interface of an application before considering the core ways the application works. I mentor against this. Businesses processes, business logic and data are the core of any application, defining what users should be able to accomplish and why. Business process, business logic, business data and core UX should drive the UI, not the other way around. So, when your team uses low-code methods that begin with UI, you’re forcing the business processes to follow UI and you may be left with a broken application that won’t help users achieve their goals.  

Designing the app in the abstract (meaning outcomes, process, data, personas) will lead to clearer mental models for the people using the app. Clearer mental models = better UX = better outcomes.  

2) UI-first app building sidelines deeper UX problems.   

Anyone in the enterprise software space knows that it’s common for new projects to be entrenched for months, as people tend to gravitate toward less business-critical matters (for example deciding where buttons go on a screen).

British scholar Cyril Parkinson’s “Law of Triviality” states that people within an organization commonly give the most weight to the least pressing issues. I agree with Parkinson: People tend to spend more time on small decisions than they should, and less time on the important, bigger decisions. Parkinson was a scholar of management practices in the mid-20th century, but his words ring ever true in the world of 21st century software.  

Unfortunately, most low-code systems are fueling this behavior. Rather than looking at the big picture and carving out the UX and business needs, low-code developers— confronted with a blank canvas on which they develop the app— will start by focusing on smaller, UI-based concerns. Are the placements of buttons on a screen that important? Yes, certainly, but far more important are the core business and UX concerns: Who sees what data and when? And what should they do with that data? 

Low-code developers and designers can be tempted to overlook these vital decisions that have a much greater effect on how users interact with an application. This is why design systems have become mainstream in software: They prescribe the look and feel and general placement of elements, removing weeks or months of discussion from app design.    

However, to go beyond standard design system coverage of “how things look”, I believe a design system needs to also define “how things work”, and thus should be critically woven into the modeling of the application development platform. That is often not the case and is worthy of a deeper discussion.    

3) UI-first app building scatters critical business processes.  

When you don’t start with process and business logic, the critical data necessary for people to get their work done becomes scattered across screens, rather than organized in a holistic and consistent way. Critical application design decisions (what a user needs to see, when and what they need to do) are all pushed to the back in favor of the canvas-based, UI-first approach. The UI of the application is prioritized over its ability to help the user achieve end goals. What results is an experience that may be friendly to the app builder but is unfriendly to an end-user.  

4) UI-first app building forces you into a single experience for all users, regardless of context.  

Canvas-based UI-first app building presumes a single experience for all users—the app developer’s experience. As a leader in your organization, you must keep your users top of mind to create winning business strategies. But when you discount the varying contexts of different personas, as often happens with UI-first or poorly implemented low-code tooling, your application becomes sidled with the same experiences for different users.

In practice, this might mean that an end-customer and a contact center agent both see the same UI. The end-user could have an overly complex and confusing experience which will lead to errors or abandonment, while the contact center could have an inefficient and unproductive experience from looking at the same UI. While we might need the end-customer and the support agent to fill the same data into the same form, their contexts are different.  

5) UI-first app building has developers AND businesspeople tinkering with the UI.  

Low-code application-building tools give both businesspeople and developers the opportunity to mold a business application. That’s great! But while we want business architects to be directly involved in the design and build, we’d prefer them to model business logic which flows into experience layers, rather than attempt to build or modify the UI directly.