Stéphanie Walter

UX Research and Accessible Product Designer

Portrait photo of Stéphanie Walter looking straight at the camera..

Tell us a little bit about yourself

I’m a UX researcher, specialising in inclusive design and enterprise UX. That means I specialise in making things accessible – or at least designing them in an accessible way – so that developers can continue building them in an accessible way as well.

“Enterprise UX” means I mostly build tools, products and services that employees use on a daily basis. At the moment I work for a finance institution: they lend money and we need people to be able to lend the money. So we have a lot of tools in order to do that. I’ve worked in the automotive industry, for a crane monitoring system, Luxembourg customs and truck transport.

I am a consultant, so there’s a company who pays me – I’m their employee – and they have a contract with the client: the client pays my company who pays me. That’s the fun part of being a consultant.

So I’m not employed for that part at least. I have a small side company to sell stickers and things on my shop, but it’s super small and not my main activity.

What are the first questions you ask at the beginning of every project?

I used to have a joke with a friend of mine where we were designing swag for a conference. When we asked them what kind of swag they wanted, they told us, “you have carte blanche”. In French, that means you have a blank page to do whatever you want. Really that meant they were not able to define what they wanted.

So what I need when I start is a high level definition of the project. If a client or team is not able to define this project in four very simple ways, then I already know it’s going to be a mess.

We designed this “La Carte Blanche” which is a card that people can fill in. It says “my project is…” and the client or the people I work with fill that in so I know what type of project it is:

Next is “my users are…” – who is your target audience? Again, I used to work in web agencies and I had people say “my users are anyone from eight to 70”. No, you’re not a puzzle company! You have a specific target audience and I need to know who it is. So who are my users?

And today it’s the same. I work for a finance institution where there are a lot of departments: am I working for this one, this one or all of them? Is this going to be used by the assistants? Is this going to be used by directors? Who are my users? Who is the target audience?

Sometimes, it was clearer when I was working in a web agency, but then there are other questions. Where are the users located? Do we need to offer the site in multiple languages? What’s the impact going to be on recruiting people for research?

My most important ask is: can you explain this in one sentence? What do my users need? What is my project, my feature, my tool allowing them to do? Why? What problem are we solving?

If the project owner, the client, the person I’m working with is not able to summarise the problem we’re trying to solve, I’m very worried because it means that it’s going to go in every direction. We’ll pivot 100 times and it’s going to be a mess.

I didn’t invent anything with “carte blanche”, I just adapted the marketing five ways: what, who, where, why, when. If someone cannot tell me what the project/feature is, who the users are, what problem they are trying to solve and when they need it, I already know that it’s gonna be a very messy project.

How do you estimate time on a project/feature?

I’m bad at estimating time. When I get the rare honour and the privilege of someone asking me to estimate my time, I usually check previous similar projects and add 30–40%. Unfortunately, I don’t often get asked.

It’s more common that a project has to be online by a certain deadline. If there isn’t enough time we start negotiating, then it’s the old school thing of you can have it fast, but it won’t be quality.

For instance, user research: that might need two weeks to have a level of quality. And I cannot get higher quality than that. Is this good enough? Or can we negotiate an extra week or something?

It’s often more that people are pushing a deadline because they’ve remembered that they need to involve the designer after they already made decide a lot of decisions. So then it’s more about negotiation and compromise: if the time is fixed, then we’ll probably compromise on quality.

When a project starts, what are the first things you do?

I ask if there’s business documentation, because often we’re not building features out of nowhere. The stuff we get asked to design is usually written in this amazing document, a Business Requirement Document (BRD), which is about 900 pages long! So I usually ask for the BRD: I hate reading them, but I have to, because I have to understand.

It answers questions like “why are we going to build that?” and “what do they want in there?” I work a lot with analysts who might do process mapping: the BRD gives us the requirements and then there’s a business process behind those requirements.

I also want to take a look at the business process to understand. Why do we build it like that? And why do we need that? I need to understand why people in the institution have asked for feature – I can challenge it of course, but I need to understand why.

What does your moodboarding process look like? Where do you source inspiration?

We do that a lot with new features. We try to find inspiration. The problem is the stuff that we develop and design is so niche that there’s very little inspiration out there. Usually when we’re looking for moodboard or inspiration with my colleagues, we will collect design patterns or specific elements.

For example, we need to build a workflow management tool that has lots of elements, including a timeline at the top. We’ll look for inspiration around how we might design a timeline. We might be drawing things on paper, we might be drawing things directly in Figma, we might be looking at different tools and things that have a timeline. So it’s more around specific UI patterns than full pages.

Our pages are so related to the business, it’s kind of hard to find inspiration that is 100% relevant to what we do.

What’s your favourite part of the design process? Why?

I like user research because I feel like a little detective. I’m like, “okay, I have this problem to solve” and then I will go and talk to the people.

We do discovery sessions where we need to understand the problem space. To do that, we ask people to tell us how they work. You discover the most weird and amazing things – there’s so much ‘shadow IT’ in banking!

Things like, “I have this Excel sheet that my husband built me years ago”. I’m thinking, “does your husband work at the bank? No. Okay. I’ll pretend I didn’t hear that!”.

A lot of research is asking people to explain how they work so we can understand how to improve and build better solutions. This part is usually super interesting because I have so many screenshots of Excel sheets: people will do anything in an Excel sheet! It’s so fun to discover all of those things.

I also like going back to users when we’ve worked on a solution to their problem. We usually build a prototype: not super advanced, a couple of screens where they can click, click, click and play around with it. It’s super interesting to watch people actually interact with stuff. And that often reveals things are obviously wrong – and that’s really humbling.

Are there any parts of your process that go against received wisdom? Or common steps that you skip? Why?

UX bootcamps often teach people about personas. And the way they’re often taught is like an archetype: this user’s name is Karen, she enjoys longs walk in the beach. This narrow vision of personas doesn’t work for us.

I had a mentoring session with someone who was taught UX at a bootcamp. She was struggling because she was trying so hard to make personas fit into our process. Instead of personas, she needed user roles because she was working on an enterprise product as well.

For us, we don’t care if it’s Karen who likes the beach and chocolate, it’s more about their role within the organisation. And the thing is, even the role can change.

Often we think about the role as the corporate role: is it an assistant, a director or something? But sometimes the role is linked to whatever you’re currently working on. So we end up having something that is not a persona, but roles at a very high, generic level. And a role might be shared by multiple people within the organisation.

We also work around tasks. There are a lot of methods from marketing that UX people use that might be okay in B2C. For instance, I used personas for an e-commerce website a couple of years ago and that worked nicely.

But in enterprise UX, these methods usually aren’t that useful. It’s the same with heat maps: I had a candidate who couldn’t stop talking about heat maps during an interview. I asked them, “What would you do with a heat map? We cannot implement those tools for privacy reasons: we’re not supposed to know where people click within financial interfaces”.

Observation is super important for us because we’re building tools that people use on a daily basis. I once worked on a tool to help people find cars in a gigantic dealership. Cars were parked after being washed, then the parking space number was put on the key. But then a colleague might move the car or it gets rented, then people would spend two hours trying to find the damn car. If a car was being rented at noon, the workers knew they had to start finding the car at 9am!

But this was only revealed to us by going to the dealership and observing people at work.

This is also why it’s kind of fun because you cannot really have a strict design process. What methods do you use? It depends on the context.

Is there anything else you suspect is unique/unusual about your practice?

I don’t know if it’s specific to Luxembourg or to Enterprise UX, but we work a lot with business analysts. I’d never worked with a business analyst before I arrived here working in enterprise.

It’s kind of tricky sometimes because until I arrive on a project, the business analyst is the person speaking to the users. But they are gathering business requirements, not pain points and things like that. Sometimes there’s a tension because people think “why do you need to talk to users when the business analyst has already done that?”

But they’re asking different questions. If a user says, “I need an export to Excel button”, the business analyst asks “which columns do you need to export?”. But I’d be asking “why do you need an export an Excel button?”

If you’re collaborating with anyone (copywriters, illustrators, developers, etc): when do you bring them in?

We have a project manager on all the projects, so often we have a product owner for the features/products and a business owner. That’s the stuff that we got from agile methodology.

The project manager is the one making sure that everything goes okay in terms of timelines. We’ll involve backend developers quite early because they can start preparing APIs, web services and things like that when we have an idea of the direction. Frontend developers usually get involved once we understand the problem and propose a UI solution.

Often I will show them the proposed solution before the Jira tickets are even written, just to make sure it’s technically feasible.

We’ll often have an analysis phase where the UX people and business analysts will try to understand what we need to build. How do we build it?

Business analysts will gather the high level business requirements, and I will bring solutions, prepare some mockups and we will test them. The business analysts will write the Jira ticket, unless it’s about UI or a technical ticket where I have to explain how a component works.

What’s been the most impactful change you’ve made to your process? Where did you hear about that?

I’ve noticed a lot of stakeholders have started using UX language. They’ll say “we need to build personas” or “I want you to do A-B testing” or “we need to do co-design workshops”.

I’ve started to ask them to give me the definition of what they mean.

I’ve been in situations where I thought, “this person knows what they want, we can communicate”. I went and did the A-B testing they asked for, and when I delivered it, say “why did it take so long?” or “that isn’t what I wanted”.

It turns out their understanding of A-B testing was building two designs and asking which one they prefer: in other words, a preference test, not an A-B test.

So now, when someone uses a UX term, I no longer take for granted that they understand what it is they’re asking for. I’ve been seeing this more and more with AI tools: people look like they know about UX because they asked their chatbot, but no, absolutely not.

When someone asks for me this, I’ll say “in my vocabulary, this is what that means I’m going to do” and ask them to confirm. If not, we can have a conversation so we end up on the same page.

What bits of the process are non-negotiables for you?

Getting access to users. You don’t know what you don’t know, especially in enterprise. You’re building things so that people can work with it on a daily basis.

You can build a finance tool for one bank, but that wouldn’t work at another bank because their processes and guidelines will not be the same. They will have the same legal framework, but the way they calculate loan percentages or their quality checks will differ, for instance.

We need to understand how people work and how the business works, otherwise we cannot do our job in those environments.

How do you organise design files?

For the UX research files, we have a folder per research session. Usually it has the approximate date (like March 2026) and in there we’ll have a research plan and a folder for all the artifacts that we need.

We’ll also have a folder for the raw data, like transcripts, and a lot of folders for analysis. If anyone asks us about previous research, we can bring the analysis, the raw data or whatever they need – we have it all stored somewhere.

Then for the design, we usually have a crappy Figma file with the prototype that is used for the testing and an actual design file for the developers. The prototype is usually a one-shot – we use the prototype once and we don’t touch it after that. So once we do the analysis, we’ll build a new file if we need to change things because we don’t want to touch the original version.

We also tag the Figma file. Is it a work in progress for the design? Was it validated? Is it ready for development?

When we’re developing features, there will be things that evolve. We’ve had cases where something was already in development and we were asked to change a couple of things, including labels and layouts. We made the mistake of changing the Figma file, but then had the tester coming to us saying “it says this in the labels, but in the story, it says something else”.

Whenever we have this situation, we create a separate mockup for the iteration and tag the Jira ticket just to make sure that everything is clear.

What does design hand-off look like for you?

Because we talked to the developer before, the Jira ticket is pre-validated by them. So unless they have an unexpected technical issue and we have to change a couple of things in the design, it should be fine.

Usually, we have a business analyst who writes a Jira ticket and we attach the Figma link and that’s mostly it. For components, we document a bit more.

Because we mostly don’t design whole pages, we’re designing small little pieces that go together. We work a lot around workflow and processes – sometimes you have a full page that is always the same, but the content of the page will change based on the user’s situation. That means any full page mockups are more like full flows based on different acceptance criteria or user paths.

How did you land your current gig?

Before this, I was consulting for another company. I was working internally on a project designing a lot of tools, and I was also working on this automotive industry project of the company.

At some point, this financial institution requested a designer and I was sent there two days a week. I actually enjoyed working on site. A couple of months later, a friend asked if I wanted to come and do the same in his bank. It’s very cliche – I live in Luxembourg and I swear there’s other stuff than banks…I swear!

I left the company to work for the bank with my friend. That bank got bought and two days later my manager was told he had to fire all of the design consultants. At that point I got placed at another company, and then this finance client came back to me, offering me a full-time position. I’ve been here ever since.

What elements of the process create speed bumps or challenges? How do you get out of these ruts?

Arriving on a new project feature with a new team and having to build trust and justify every single pixel on your screen. I think it’s the same if you’re a freelancer and you have a new client.

It’s kind of sad because once you’ve been working for a client for a couple of years and you know they have multiple teams, you at least hope that if you get job from another team they have heard of you and they would trust you. But no, you still need to spend a lot of time justifying every single design decision and it takes a lot of time.

I feel like “Please trust me, I don’t have time to explain to you why the button is here”. So that’s kind of the annoying part, but I think it’s a life as a designer: people trust developers, but for some reason designers have to prove that they know what they’re doing.

How do you make decisions?

We are very data-driven. Often we try to understand what is the business value, what is the user value, what is the cost in terms of development and what is the cost in terms of design?

It’s not strict, but we have a framework to make decisions. Often it kind of fits within the framework, but if it’s 50-50, you take a leap of faith and you understand also that nothing is fixed.

Favourite tool, resource or course?

I really like Miro because I can have this gigantic canvas and I can use it for so many different things. It’s like a visual thinking tool where I can do information architecture, brainstorming – lots of things.

Where can people find out more about you, keep up-to-date with what you’re doing or give you money?

Newsletter

Sign up to receive five interesting links every Thursday.