Chantal

Ever since I started developing software, I’ve always been interested in designing interfaces — whether graphical user interfaces, APIs, or voice user interfaces. It’s all communication. Even the designers of shower fittings are communicating with the people who will use those showers (and maybe get annoyed because they started with the wrong temperature). Looking at interfaces from the end-user’s perspective and asking whether the operation is intuitive and coherent has often led me to ask colleagues, project managers, or clients about the actual purpose of the application. Sometimes, I even adjusted the interface or application based on their answers — when possible. I increasingly wanted to be involved earlier in decision-making so I wouldn’t have to implement interfaces that were confusing or unnecessarily complicated.

Through Lars — back when I was still at my previous company — I found out that blu was looking for someone in Requirements Engineering. blu was already a familiar and trusted place for me, so I felt confident that I wouldn’t be laughed at or dismissed for applying not just for what I already knew, but for a role I hadn’t officially held before. What really encouraged me was the very positive feedback from former clients when I told them I was moving toward requirements gathering and conceptual work. They thanked me for the strong conceptual support I had provided in past projects.

Finding the essence of reality that we’re trying to represent with software: as simple as possible, yet still accurate.

First, in understanding that “user interface” and “usability” are neither luxuries nor cosmetic extras. They are the skin of the applications we build — and that includes all system boundaries, like APIs, email delivery, or PDF generation. There’s no system without a system boundary. So if we don’t invest time and money in a usage concept, it doesn’t mean there won’t be a way to use the system — it just means we haven’t thought deeply about how that usage should look in every aspect (including error handling, validation, system boundaries, etc.). That inevitably leads to each developer implementing things the way they personally think is right.

Second, there’s a misconception that a usage concept is sufficiently described by a set of wireframes. Wireframes are the necessary framework, but the real reality check comes when you describe the relationships between displays and controls, and explore the interactions that should be possible based on those wireframes.

It’s easier to describe the types of tasks that come up:
– Calls with clients to
• discuss business processes and how software could support them
• review specific processes in the software and possibly adjust behavior
• identify bugs
– Writing emails to clients to clarify details
– Scribbling in Miro: from diagrams visualizing processes (in software or business) to rough wireframes, depending on the need
– Writing user stories in Confluence and thinking about how they could be implemented technically. That helps me define small work packages, which I then create Jira tickets for. I try not to give the team technical instructions, but my own experience as a developer helps when defining these packages
– If included in the project (ideally): coordination with UX/UI design
– Estimation and planning sessions with the team, where I explain what’s included in a work package and the business logic behind it
– Calls with developers or QA when there are questions
– Development — I still do that, and I enjoy it
– Code reviews
– Every second Wednesday at 11 a.m., we have our “UX team call,” where we look at applications currently being developed by someone on the team, or ones that stood out to us positively or negatively. If you’re interested, feel free to reach out to me.
– Regular calls, etc.

A client-side Product Owner with:
– A clear vision
– Insight
– Long-term interest

They don’t need to know what they want. They just need to explain how they currently handle a business process, and I can then suggest how the software might support them.

My first project as a Requirements Engineer: Liprotect (client: Linde) stands out positively. At the beginning, there were challenges — I didn’t know how to prepare tickets so the team could understand and estimate them, and I made decisions for the client that made them feel left out. But over time, things settled. The highlight for me was when the two Product Owners held an internal workshop with a small group of end users and presented us with the results: rough usage concepts in the form of photos of whiteboard sketches for a new area of the application. Johann (Stuke) and Lars turned that into a great UI concept, we implemented it, and the Product Owners were very happy with the result.

The meta-level: the respectful way we treat each other — especially with the leadership. The fact that you can talk to anyone, really (yes, I’ve experienced otherwise…).

The ability to empathize with others — to understand where their attention is in a given situation. That helps you design an application that meets them where they are. This isn’t just about mental awareness (what does the person know at that moment about data, software, etc.) but also physical realities like: is the light on, are they outside in the rain, are they wearing gloves or safety goggles? The focus isn’t on the software — it’s on the person using it.

That I’m allowed to make mistakes, receive open and constructive feedback — and then get the chance to try again and show that I’ve learned from it.