At AIMMS, we are working on WebUI: an application that lets app developers build applications themselves. A toolbox for creating new tools. That may sound abstract, but it has very concrete consequences for how we design. In a classic UX project, you usually design directly for the end user. With WebUI, however, we mainly design for the app developers. In turn, they create something for their own users. This layered setup brings challenges that we rarely encounter in this form in our work. In this article, we’ll walk you through three of those challenges.
Designing for two layers of users
The most fundamental difference compared to other projects is that with WebUI, we are designing for two layers of users. On one hand, we have the app developers, who are the direct users of WebUI. On the other hand, there are the end-users of the applications that these developers build.
Within AIMMS, this is reflected in two development teams. The WebUI team develops the platform, and another team uses that platform to build Supply Chain Navigator (SCN): a tool that helps businesses optimize their supply chains. This means the app developers working on SCN are both users and creators at the same time.
And therein lies the challenge. As a designer, you have almost no direct influence on the final user experience of the end-user. That experience is shaped by the app developer, who often doesn't have deep UX expertise. It's up to us to design WebUI in a way that is intuitive and guiding, without being overly restrictive.
In other words, we design tooling that provides direction while leaving room for freedom. It’s a platform that is not only functional for the creators, but indirectly helps the end-user too. That requires a completely different mindset.
Freedom vs. predictability
Because WebUI is used to build all kinds of different applications, the platform needs to be extremely generic. App developers want to create supply chain tools with it, but also dashboards, configurators, and everything in between. This means that as designers, we develop open-ended features: components that are flexible and can be used in many different ways.
On paper, that sounds great—anything is possible. In practice, it means every app developer applies a feature slightly differently. One might use a data grid as an interactive table, while another uses it as an input form. This doesn't just lead to a wide variety of setups; it also brings unexpected bugs, UX inconsistencies, and feature requests that sometimes contradict one another.
It's a fine balancing act. Too much freedom and you lose control over the user experience. Too many restrictions and you block the creators' creativity. We try to make conscious choices here: clear defaults, smart limitations, and visual frameworks that guide without dictating.
Designing WebUI, therefore, isn't about designing a finished product—it's about designing a system. A set of building blocks sturdy enough to rely on, yet flexible enough to leave room for interpretation.
How it differs from classic UX projects
In most projects, we design directly for the end-user. We talk to users, understand their context, and tailor the product to their specific needs. Features have a clear goal: one button, one task, one desired outcome.
With WebUI, things work fundamentally differently. We are not designing finished products, but a platform that others use to build products. The app developers are the users, but their output (the apps they build) determines how the end-users indirectly experience WebUI.
A great comparison: in a classic project, you design the chair. In this project, you design the hammer, the saw, and the manual, hoping the chair turns out sturdy and comfortable. As a UX designer, you think not just about ease of use, but also about potential misuse. About flexibility without confusion. About how many different people with different goals can still work successfully within the same system.
That is what makes WebUI unique among the projects we work on. The complexity doesn't come from its size or technology, but from its layered nature. And along with that, the indirect control over the end-user experience.
Designing in complexity
WebUI forces you to think differently. Not about a single user, but about multiple layers at once. Not about a finished product, but about a system that enables others to create their own products.
This requires choices you rarely have to make in other projects. When do you offer freedom, and when do you set boundaries? How do you design for use cases you can't even foresee yet? And how do you ensure that the end-user, who never actually sees your design, still has a great experience?
For us as UX designers, this makes WebUI one of the most complex, but also most rewarding projects to work on. It demands sharp choices, teamwork with different kinds of stakeholders, and the ability to let go of things you normally take for granted.
And that is exactly where Okapion's strength lies: designing within complexity, without ever losing sight of the (end) user.
Does your platform work for the creators too?
Are you working on a digital product that other people use to create or manage things themselves? And are you running into limits regarding usability, scalability, or structure? We’d love to help you bring clarity to your project, through UX design and strategy.
