GUI and HMI Software Development with slashwhy

slashwhy develops graphical user interfaces for devices running embedded software.

slashwhy is your partner for GUI and HMI software development

  • We develop graphical user interfaces (GUIs) for devices running embedded software, from concept to technical implementation on your hardware. Our work ranges from simple configuration interfaces to complex control panels, depending on what your product needs.

  • A graphical user interface (GUI) is any screen-based software interface; a human-machine interface (HMI) can also include buttons, rotary controls, or indicator lights. We clarify this distinction at the start of every project, because it directly shapes which framework and how much effort are realistic for your application.

  • Whether the interface becomes a decisive factor for your product depends on how regularly people interact with it, for example in household appliances or machine panels. For systems that operate autonomously, like in pure control technology, it plays a minor role.

  • Why graphical user interfaces are essential: if a device is hard to operate, it becomes less useful to the people using it, and support effort goes up. In a manufacturing environment, an interface that's hard to use can even bring entire production lines to a halt.

  • Graphical user interfaces are part of our embedded software portfolio and complement services such as firmware development or IoT and cloud integration. For the design side, we also draw on our dedicated UX & UI team; our deepest experience here is with human-machine interfaces that present large amounts of complex information clearly.

Interested? Then this page has everything you need to know about slashwhy as your partner for developing graphical user interfaces and human-machine interfaces.

Your starting point

Typical project situations in HMI and GUI development

With existing interfaces, we often see the same pattern: instead of a carefully designed user interface, what grows over the years is an engineering interface that works from a developer's point of view but isn't built around the operators, either in how it guides them or in how it presents information. This shows up especially when machines or systems have grown across several device generations and each new feature was simply bolted on without reorganizing the menu structure.

Other companies come to us with a new hardware platform: a new display, a different resolution, or a move from physical buttons to touch fundamentally changes what the software has to do. And others are just starting a completely new project, where the control system, sensors, or system connectivity are already defined, but there's still no interface for operators to interact with the system.

In all of these situations, the quality of the implementation decides how well the product works in everyday use and how good it feels to use.

Outdated user interfaces

Your interface has grown over the years, and each new feature was simply bolted on. The result: a menu structure that makes sense from a developer's point of view but slows operators down in everyday use and makes mistakes more likely. Depending on the project, we assess the existing solution together with the people who use it, identify the biggest weak points in the user guidance, and develop a new interface that fits how it's actually used and what those users need.

A new device without an operating concept

The control system, sensors, and system connectivity for your new device are defined, but there's still no interface for operating it. Without early concept work, you risk changes to the hardware or data logic later on, and those cost time and budget. We design and test the interface in parallel with hardware development, so both sides fit together from the start and commissioning goes faster.

New hardware, old software

Your next device generation comes with a different display: smaller, monochrome, or with different touch functionality. Porting the existing interface one-to-one no longer works and leads to cluttered or unusable screens. We tailor information density and interaction logic specifically to the limits of the new hardware, instead of just shrinking the old solution.

Unclear data logic behind the interface

Your interface needs to show application data, or data from a PLC or the cloud, but it's not yet clear which of it has to be visible in real time and which is historical or calculated. Without that clarity, you end up with interfaces that show either too much or the wrong things. We work these questions out together with our embedded teams and design the interface around the actual data logic running behind it.

slashwhy is your partner for graphical user interface development

  • Before we design anything, we work out which information and functions the interface really needs. We prioritize content around the tasks operators actually have to get done, instead of putting every available system function on the screen without thinking. The result is a structure that stays easy to follow even for complex systems.

  • For the actual visual design, we work closely with our UX & UI design team. Together, we build prototypes, test them with real operators, and adjust interaction flows before we finalize a single screen. This cuts down on iteration loops later in development.

  • We implement the designed interface on your target hardware, using frameworks like Qt or TouchGFX. From the start, we factor in the processing power, memory, and display that are actually available. The result is an interface that runs smoothly not just in the design tool but on the real device too.

  • If your existing interface has turned into an engineering interface or runs on an outdated framework, we handle the modernization. We assess which parts of the existing solution can stay and which need to be rethought. That way, we avoid a full rebuild where a targeted overhaul is enough.

  • Your interface rarely stands on its own; most of the time it has to work together with a PLC, with sensors, or with cloud connectivity. We handle this integration and decide together with you what appears in real time and what comes from historical or calculated data. For the cloud side, we draw on our experience from IoT and cloud integration.

  • On resource-constrained hardware especially, optimization is what decides whether an interface feels responsive or sluggish. We specifically analyze rendering, memory usage, and response times, and fix bottlenecks before they show up in the field.

  • Finally, we turn the interface into a documented system of components, rules, and states. This makes sure your product can keep evolving consistently across several device or machine generations, even when other teams pick it up later.

Our tech stack for GUI and HMI software development

  • GUI frameworks: Qt/QML, TouchGFX

  • Languages: C++, QML, Rust

  • Hardware and displays: touch and non-touch panels; a range of resolution classes, from small monochrome displays to high-resolution color displays

  • IDEs and toolchains: Qt Creator, TouchGFX Designer

  • Debugging and tracing: Qt's own profiling and inspection tools for analyzing rendering and memory usage

  • HAL integration: connecting to existing driver and hardware abstraction layers, working with our firmware team

dr-joachim-wilharm-slashwhy

For a long time, a good user interface on embedded devices was considered a conflict. In our cross-functional teams, however, UX designers and embedded developers work together toward achieving this goal. This eliminates inefficiencies caused by incomplete or confusing UI specifications.

dr-joachim-wilharm-slashwhy

Dr. Joachim Wilharm

Managing Director at slashwhy

Your basis for deciding

The role of the user interface in the overall system

How an interface should be designed depends heavily on the role it plays in the overall system. We distinguish three basic types: control, monitoring, and configuration. Each role has its own requirements for information density, response time, and fault tolerance, and many devices combine several of these roles in a single interface.

Control: when every action has to take effect immediately

With control interfaces, operators trigger an action in the system directly, for example starting a process or changing a parameter. Here, what matters most is response time: if feedback is delayed, users are left unsure whether their input got through. That's why we design control elements so that every action gets immediate, unambiguous feedback.

Monitoring: when the overview matters more than input

Monitoring interfaces show the state of a system without expecting any direct action. Here, the focus is on information density: how many data points you can show at once without operators losing track. We prioritize values by how relevant they actually are to the task; deliberately separate real-time data, historical values, and calculated quantities; and use the right visualizations or formats.

Configuration: when mistakes only show up later

Configuration interfaces define system settings that stay in effect over a longer period, for example parameters for a manufacturing process. Here, what matters most is fault tolerance: a setting applied incorrectly may not surface until much later. That's why we build in confirmation steps and plausibility checks before a configuration actually takes effect in the system logic.

FAQ | Frequently asked questions about GUI and HMI software development

  • In principle, yes, but first we check whether the design is compatible with the limits of your target hardware, such as display size, color depth, or available processing power. If the design doesn't fit the hardware, we're upfront about it, instead of building it unchanged and compromising on performance later. That way, your good design idea holds up against the technical reality.

  • No, we handle that in-house. For the design, our embedded team works closely with our own UX & UI design team, so you have one point of contact instead of having to coordinate two separate partners. That saves you coordination overhead and prevents friction between design and technical implementation.

  • That depends a lot on the scope: a simple configuration interface takes far less effort than a full HMI with multiple user roles and system integration. The biggest cost drivers are the complexity of the information architecture, the target hardware, and whether we modernize an existing interface or build a new one from scratch. After an initial conversation, we can give you a solid estimate for your specific project.

  • There's no one-size-fits-all answer to that, because it depends a lot on the scope of the system roles, the target hardware, and whether we modernize an existing solution or design a new one from scratch. Smaller configuration interfaces are much quicker to build than complex HMIs with multiple user groups. We can give you a realistic timeline once we've clarified the requirements in step 1 of our project process.

  • In many cases, yes. First, we assess which parts of your existing interface are still functionally sound and which really need to be rethought. That way, we avoid a full rebuild where a targeted overhaul is enough, and you keep more control over budget and risk.

oliver-kortekamp

Intuitive operation through a modern UI matters a lot to us. Our customers shouldn't have to wrestle with the technology, but should have fun with the products and enjoy using them.

oliver-kortekamp

Oliver Kortekamp

Team Leader & PO at Oase

dr-melanie-schuh-wuh

We always feel that slashwhy takes ownership of the product. Everyone involved fully identifies with it. It's different with other partners.

dr-melanie-schuh-wuh

Dr. Melanie Schuh

Product Management at W&H

friedrich-laube-miele

In slashwhy, we have a partner who doesn't just deliver code, but supports the whole process from concept to implementation, who identifies with the product and actively improves it.

friedrich-laube-miele

Friedrich Laube

Director Digital Products & Services Smart Home at Miele

markus-rose-phoenix-contact

The agile mindset of everyone on the slashwhy project team is impressive and, in the best sense, contagious. We work with slashwhy as equals in agile project teams, and together we reach our goals faster.

markus-rose-phoenix-contact

Markus Rose

Director CHARX control Division Charging Infrastructure at Phoenix Contact

axel-schroder

The big benefit of the solution we developed with slashwhy is that we can keep developing our production products in parallel with the new development projects.

axel-schroder

Axel Schröder

Director Advanced Engineering at CLAAS E-Systems

tobias-lange

We can save a completed commissioning in the app and, especially on large construction projects, reuse that template again and again to set up identical gates. That's a clear advantage and a major benefit of the app.

tobias-lange

Tobias Lange

Project Manager at Hörmann

Your hardware limits

We develop user interfaces for any hardware

Graphical user interfaces for embedded systems rarely come together under ideal conditions. Small displays, limited processing power, harsh operating environments, or physical rather than digital controls set limits from the start that an interface has to work within.

Small display sizes

A 4-inch display forces you to prioritize, because not everything fits on the screen at once. From many projects with small industrial displays, and from what we've learned in user research, we know which information operators actually need to keep an eye on. Based on that experience, we decide for each view what really needs to be visible, instead of cramming everything in at once.

Monochrome displays

Without color, you can't signal importance through color coding. That takes a lot of common UI patterns off the table. We've worked on several projects with monochrome displays and developed a sure sense of how hierarchy works through size, position, and contrast, so that status and priority still read clearly.

Physical controls

A handful of buttons or knobs means not every function can be directly accessible at the same time; something always has to take priority. From HMI projects with physical controls, we know which functions operators need instantly in everyday use. Building on that, we decide what's directly accessible and what stays reachable through a second level.

Harsh operating conditions

Fine controls become unreliable with gloves on or under vibration, and in practice that quickly shows up as operating mistakes. We know these operating conditions from projects in industrial settings, so we specifically enlarge touch targets and design input detection to be more robust than an office setting would require.

Limited color vision

Color coding alone, like red/green, doesn't reliably reach every operator. It's an accessibility consideration that we actively factor into every HMI project. That's why we always pair status colors with a shape or text, so the information comes through reliably even without color perception.

Limited processing power

Too many animations or too much data at once noticeably slow down resource-constrained hardware. And it often only becomes noticeable once the system is already running in the field. Drawing on our experience in performance optimization for embedded hardware, we plan for the resource budget and data volume from the start, instead of having to scale them back after the fact.

Nice to know

Success factor: when dev and design teams work together

Developing a graphical user interface for embedded devices takes two skills that rarely come together in one team: an understanding of hardware limits, and an understanding of how people actually use an interface. Cover only the technical side, and you get an engineering interface that works from a developer's point of view but falls apart in everyday use. Cover only the design side, and you get designs that impress but can't be built within the available processing power or display size. That's why, at slashwhy, the embedded team and the UX & UI design team work in the same project from the start, instead of developing design and technology separately and only bringing them together at the end.

Our approach

How developing your GUI with slashwhy could work

Every GUI project comes with a different starting point: sometimes a rough concept is already in place; sometimes we start from scratch; in other cases, we get to modernize existing interfaces. The basic process stays much the same, though: from first clarifying the requirements, through concept and design, to technical implementation on your target hardware. The following six steps show how we work and where our embedded team and our UX & UI design team work together.

1 | Understanding the problem and user research

Before we design an interface, we understand the problem: who operates the device, under what conditions, and with what goal. Where possible, we run user research right at the operators' actual workplace, to see how things really are, not how they're described. This groundwork decides whether an interface will really fit how it's used later on.

2 | Analyzing hardware and requirements

We clarify the technical constraints: which hardware is fixed, which display will be used, and how much processing power is available. These factors determine which framework makes sense and where the design limits lie. The sooner these questions are settled, the fewer adjustments we need to make later.

3 | Defining the architecture

From the requirements, we develop an initial structure: which content needs to be visible, and which actions need to be directly accessible. At this point, we deliberately bring our UX & UI design team into the project early, ideally before the framework decision is final. This is what sets us apart from other partners in the field, where design and development only come together after the technical architecture decision, by which point the design options have already narrowed.

4 | Design and prototyping

Based on the concept, we create the visual design, including first prototypes that we test with real operators. That surfaces points of confusion or unclear operating flows before we finalize a single screen. In this phase, design and development work closely together, instead of handing off the results only at the end.

5 | Implementation on the target hardware

We implement the designed interface on your hardware, using Qt or TouchGFX, depending on the requirements from step 1. As we go, we continuously check whether the interface stays performant under real-world conditions, not just at the end but in parallel with implementation. That way, problems with processing power or memory surface early, while they can still be fixed with reasonable effort.

6 | Handover, documentation, and next steps

Finally, we turn the interface into a documented system of components, rules, and states, one that your team, or we together with you, can keep evolving. For deeper user testing and usability evaluations, we draw on our UX testing experts. That keeps the interface consistent and maintainable across several product generations.

Working with us

Four reasons to choose slashwhy as your GUI development partner

We build software by people, for people. And all these people have very different needs. Users want to get their tasks done efficiently; our customers want to create real value. And us? We want to build software that solves real challenges, makes everyday work simpler, and is fun to use.

Experience with complex interfaces

For us, user-focused development means this: we first understand who operates the interface, under what conditions, and with what goal. Only then do we build a structure that proves itself in everyday use. This experience comes from numerous projects with control panels in industrial settings, from simple configuration interfaces to full HMIs.

Understanding hardware limits

From the start, we treat display size, processing power, and harsh operating conditions as design parameters, not as a problem to solve at the end of development. That saves you from interfaces that impress in the design tool but stutter or become unusable on the real hardware.

German development partner

Our teams are based in Osnabrück, Hamburg, Bielefeld, and Kiel, work in your time zone, and speak your language. Unlike with nearshore providers, you skip the coordination overhead of working across multiple time zones and language barriers, and questions get answered in minutes, not days.

One partner from concept to implementation

Our embedded team and our UX & UI design team work together in the same project, not one after another in separate silos. That saves you from coordinating between two separate partners for design and technical implementation, and makes sure your design ideas hold up against the hardware reality.

Global players and hidden champions

At slashwhy, you're in good company

The companies that benefit from graphical user interfaces

Graphical user interfaces become relevant as soon as people have to interact with a device regularly or under time pressure. With household appliances, the interface decides whether users see a device as modern or find it clunky, even when the underlying technology is mature. In agriculture, a different challenge comes up: a control unit for a fertilizer spreader might only be used two or three times a year, in season, but then it has to work right away, without having to relearn it.

In mechanical and plant engineering, control panels often take on several roles at once: control, monitoring, and configuration on the same interface, often for different user groups such as operators or maintenance. These panels rarely run on powerful industrial PCs; instead, they work with limited memory and restricted graphics performance, which shapes the design from the start. In building technology and connected consumer products too, interfaces are increasingly becoming the visible part of a system that exchanges data in the background via a PLC, sensors, or the cloud. We develop interfaces that fit each specific use situation, instead of applying a one-size-fits-all solution across different fields of use.

FAQ | Frequently asked questions about GUI and HMI software development

  • A graphical user interface (GUI) is any screen-based software interface, no matter where it's used. A human-machine interface (HMI) refers specifically to the interface between people and a machine and, besides a GUI, can also include buttons, rotary controls, or indicator lights. SCADA (supervisory control and data acquisition) goes a step further: it refers to a higher-level system for monitoring and controlling multiple systems or processes, often across sites, where an HMI usually represents just one part of it.

  • That depends on your target hardware. TouchGFX is heavily optimized for STM32 microcontrollers and delivers smooth animations there, even on mid-range hardware. LVGL is open source, platform-independent, and especially well suited to resource-constrained systems with changing languages or dynamic content. Qt comes with extensive functionality, but needs more powerful hardware than the other two options. We choose the right framework based on your specific hardware limits and requirements, not on a one-size-fits-all recommendation.

  • Off-the-shelf solutions are faster to deploy and enough when your requirements are standard, like visualizing machine data or displaying alarms. Custom development pays off as soon as you want to set yourself apart through distinctive operating concepts or a look of your own, or when your requirements go beyond what a standard platform covers. In practice, we often see hybrids: an off-the-shelf solution as the base, extended with custom-built parts for the things that really should, or need to, set you apart.

  • The most common cause is too many animations, or too many data points updating at once, on hardware with limited memory and processing power. Poorly chosen refresh rates, or an interface that was tested on a PC first instead of on the target hardware, can cause the same effect too. That's why we check performance during implementation, on the real target hardware, not just shortly before delivery.

  • GUI and HMI describe the type of interface, while UX/UI design is the discipline that shapes the content and structure of those interfaces. So a GUI or an HMI can be well designed or poorly designed; UX/UI design is the work that decides which way that goes. These terms often get mixed up because they overlap, but they describe different levels: the what and the how.

Let's exchange ideas

Do you already have a specific project idea and want to find out whether slashwhy is the right embedded partner for your GUI software development? Or are you just starting out on your journey and looking for the ideal starting point? Either way, our team of experts would love to hear from you and is here for a no-obligation consultation.

dr-joachim-wilharm-slashwhy
  • Dr. Joachim Wilharm
  • Managing Director

Haven't found what you're looking for?

slashwhy as your partner for graphical user interface development

For embedded devices, graphical user interfaces decide whether the technology gets accepted in everyday use or turns into a source of problems. At slashwhy, we develop user interfaces for devices running embedded software, from simple configuration interfaces to complex human-machine interfaces (HMIs) for industrial use. Our GUI development runs from the first concept, through UI design and prototyping, to technical implementation on your target hardware, using frameworks like Qt or TouchGFX.

A well-designed interface reduces operating mistakes, shortens onboarding for new staff, and lowers support effort over a device's entire service life. In a manufacturing environment, on the other hand, an interface that's hard to use can bring entire production lines to a halt, a risk we factor in from the concept stage on. To do that, we pair our embedded experts' technical grasp of hardware limits, such as display size, processing power, or harsh operating conditions, with the design expertise of our UX & UI experts.

As part of our embedded software portfolio, GUI development complements services like firmware development, embedded Linux, real-time applications, and IoT and cloud integration. For connecting to existing systems, we draw on our experience with PLCs, sensors, and cloud integration; for user testing, on our UX & UI design and usability testing team. Our expertise in user interface development benefits customers in AgriTech, consumer electronics, HealthTech, CleanTech, building technology, and mechanical engineering, from hidden champions to companies like Miele, CLAAS, and Phoenix Contact.

With locations in Osnabrück, Hamburg, Bielefeld, and Kiel, we develop your graphical user interface in your time zone and without language barriers, with direct access to our embedded and UX expertise under one roof.