Welcome to UX Research Geeks, the podcast delving into UX research. In this fifth episode, we talk with Stéphanie, a skilled UX researcher and designer from Luxembourg. With over 12 years of experience, she specializes in enterprise UX and mobile design, offering insights, teachings, and articles on design, UX, and accessibility.
00:05:00 – Building Trust by Making Work Easier
00:12:12 – Identifying Users and Gathering Feedback
00:21:25 – Open Communication
00:36:47 – Enjoying the UX Journey with Humility
00:41:48 – Connect with Stephanie for UX Insights and Updates
About our guest Stéphanie Walter
Stéphanie is a UX Researcher & Product Designer with a decade of experience across diverse industries like banking, automotive, healthcare, and more. Her expertise spans UX research, product design, and mobile strategy, aiming to create user-centered and accessible products and services. As a conference speaker and educator, she shares her insights on topics such as UX design, accessibility, inclusive design, and mobile performance. Connect with Stéphanie on LinkedIn or explore her website now.
[00:00:00] Tina Ličková:
This is the fifth episode of UX Research Geeks. Where we spoke to Stephanie, who is a UX researcher and designer based in Luxembourg. She has 12 plus years of experience and specializes in enterprise UX and mobile. She teaches, speaks and writes about design, UX research, accessibility, cognitive biases, design, dev relationship, and much more.
Hello, Stephanie. Hello. I was thinking, and when I was thinking about how we structure the show, the first thing that came to my mind coming from our kickoff call was Stephanie and Cranes. True. Yes. I was also thinking, to be honest, to build a meme where you are sitting in a crane and promote the show like this, but maybe it’s going too far.
You tell us later on. Tell me really what is it?
But tell me really why is Stephanie into cranes? Or what does cranes, or what do cranes do have to do with Stephanie?
[00:01:29] Stéphanie Walter: I’m not into cranes, but I happen to have learned things about cranes because I was working on a project that was about monitoring the crane system. So you have to imagine, usually on a construction site you have one to three, a bunch of cranes, and the goal is to make sure they don’t collide.
And it’s not just about the middle of the crane. There’s this super long arm. So you have to put them somewhere in the construction site to make sure that even if the arm is rotating, because there’s a lot of wind, there’s no chance of collision or something like that. So I was working with a client and he had a monitoring crane system.
It was super fun as a nerd because I had the real time position of all of those little cranes mapped out on my screen. So I was like, is this real data? The guy was like, yeah, that’s somewhere in Paris, there’s three cranes. And I could see them, like, rotate in real time. I was oh, this is so cool, so fun.
So yeah I learned a lot about how the crane works and the different constraints and why you need to monitor them. Basically when there’s too much wind you need to let them loose, which might sound a little bit counterproductive, but the idea is if there’s too much wind, the Army needs to be able to rotate how it wants to rotate based on the wind.
Otherwise, you might just have the crane fall or something. Yeah, it was a really fun, interesting project. I didn’t know anything about cranes and how they worked before that. But yeah, also quite challenging because you had, it was a little bit of that visualization, like how do you show different cranes and identify them on the map because there was a not really 3D rendering, but like this fake 3D in the browser. So you could move it around to see the positioning real time and yeah, the monitoring part with others and stuff. So it’s basically you need to make sure that you don’t use only color, for instance.
Because if you have colorblind users, you can say, oh crap, the red one has an issue. Yeah, which one is the red one? So there was a lot of challenge with having a visual language to make sure that all the users, even if they are colorblind for instance, could see which cranes which, and which has an issue and things like that. Yeah.
[00:03:55] Tina Ličková: Really interesting. Really. But I’m still imagining you navigating a crane.
[00:03:59] Stéphanie Walter: I would love that. I didn’t ask the client to do that, but I should have said, “Hey, can I go and just go into the crane?
[00:04:06] Tina Ličková: Have you been, but have you been physically in one?
[00:04:10] Stéphanie Walter: No I wasn’t. No, but I think the issue is, I don’t know if they have a little elevator for you, or if you need to go through a ladder.
An elevator. I think I will be fine. But if I have to use a ladder with the wind and the height. Yeah. I’m not sure I would be okay with that. But if it’s a closed little elevator, I think I would just not move until I was at the top. And that would be fine.
Yeah, definitely. But no, it’s super fun because no one does a lot of construction site in Luxembourg. I was like, oh, this crane is rotating because there must be so much wind over there or something like that. So I’m like it’s not an obsession, but sometimes I look at the scams like. Huh, I know about that.
Which is fun. I don’t know if it’s a kind of interesting knowledge to have, but, yeah.
[00:05:00] Tina Ličková: You never know when you need a crane.
[00:05:02] Stéphanie Walter: Yeah. Exactly.
[00:05:06] Tina Ličková: My question with it, I can’t imagine the interface and how you were as you were explaining watching the cranes and getting some details.
Have you been, actually did you have a chance to talk to the crane navigators and if yes, what came out of it?
[00:05:24] Stéphanie Walter: Unfortunately not directly for that project. It was like years ago, I think eight years. And UX design wasn’t that popular yet in France. So I had information through a third part, which was someone made the, basically the back and forth with the project.
So I had access to a lot of information about how they work and stuff like that. But yeah, it was not direct information though.
[00:05:50] Tina Ličková: No worries. No worries.
[00:05:53] Stéphanie Walter: That’s also why I like working on internal tools. It’s easier to talk to the users because they are somewhere in the building.
[00:06:03] Tina Ličková: Yeah. Yeah. And that’s a good bridge to what I wanted to ask you. What are you doing now? After the crane history,
[00:06:11] Stéphanie Walter: Years after the crane’s history, I’m working as a consultant in Luxembourg. And today my main client, my only client actually, is a European investment bank. So it’s a little bit complicated because it’s half European, half private, and basically they’re doing some loans for different projects all over the world.
It’s just big loans. So it’s like an investment bank, but At a kind of bigger scale, and I work on a tool for the bank, which is a tool that is a project management tool that follows a project from the beginning to the end. So from someone saying, oh, we need to build a bridge somewhere in Germany, and we can have European money for that because it meets certain criteria.
Then you have to create the project. You have to do contracts, and then it needs to be improved. You have the money that is disbursed, reimbursed, so all the classic stuff with loans, except that it’s like for a kind of big project and different areas and KPIs and yeah. We have this old tool that is, I think 12 or 15 years old.
And we are completely rebuilding it. For various reasons and mostly because what we have today is a technical debt on the old interface and we can’t provide new features to the users. So due to. The fact that it was built a long time ago. There’s a lot of technical restraints, and this is why we are doing a new tool for the technical part.
But by changing the technical stack, it also means that we can provide a lot more interesting features to the users because the business evolved. Like today, you don’t do it alone like you used to do years ago. So in order to keep up to date with the business, we’re building that one. Yeah, it’s been going on for two years, a little bit longer, but I’ve been on that project for the last two years, and we are going to be live, as you say, for our internal users officially in September.
[00:08:14] Tina Ličková: And this combines two things where I hear, I personally love the finance field and research in that area, but it’s finance and it’s like governmental slash private. And it’s a bank and it’s an enterprise where some designers and some researchers are like, oh, that’s boring.
And I know my reason why it’s not boring, but what are your reasons? Why do you work on it and why do you like to work on it?
[00:08:43] Stéphanie Walter: Yeah. The first thing I think is that people are super nice and like users are just super happy to talk to you because it’s a tool they’re using on a daily basis. They’re almost surprised that you’re actually doing research and trying to understand things, because up until now it was more like IT projects. In a lot of companies it is the case in Luxembourg, but I think it’s the case in a lot of countries as well.
A lot of enterprise projects today, they’re really IT oriented. So you sometimes have business analysts or like PMs who try to gather technical requirements and then they build something, it goes to the users and that’s basically it. And sometimes it works, but most of the time the issue is between the moment they gather the technical requirement and the moment the thing arrives to the user, they might be changing their thing so it’s already updated or something like that.
So it’s a little bit new for my users to have a UX designer who tries to understand their needs. So it’s really nice to work with them because then you really understand how they work on a daily basis and We do some task analysis where we ask them about tasks. We try to understand what they need in order to do this task, whether it’s information.
So we are trying to bridge the knowledge gap from the business information they need, and. Interface that can help them do what they need to do. But also sometimes it’s other tools or maybe just some info from another person or something like that. So there’s a lot of things around trying to build bridges between the different tools at the bank to make their daily life a little bit easier.
And I think that’s what I prefer with that job is like you actually feel that you’re making people’s daily lives and daily job a little bit easier and space on their job. I’m just really happy for them if I can make something a little bit less annoying or complicated because when they work with some old tools, there’s also a lot of risk of errors and things like that when you have to duplicate information. For instance, one of the main things people say is we have to duplicate information because those two systems, they don’t connect today, so could we have a way to connect them so that information is automatically transferred?
Otherwise, every time you have a human being who needs to do the duplication, they may make errors, they may make mistakes and stuff. And since it’s a finance domain, you don’t want to make mistakes or you try to do as little as possible. So that’s the thing I really like, like being able to help people and actually see the results of how I’m helping them. So it’s really nice, in that sense.
[00:11:32] Tina Ličková: Before I go into what kind of methods you mentioned already, task analysis, I’m also curious because what I know when I am doing some B2B projects, or enterprise projects, it’s that the people are very happy if you talk to them, but they’re also very strict with the outcomes.
They’re like, but I told you that I want, I need this and that. And then they don’t see it because of course you have to analyze this and it, you have to come to aggregate the knowledge and make design decisions. But how do you work with the people then explaining them? Why does it end up to be like this or not like that?
[00:12:12] Stéphanie Walter: Yeah, there’s a lot of change management to do indeed. So a lot of things that we do is we have release notes, for instance, where we send an email showing the beta tested, the new version and explaining them, doing new features and all of that. And we are doing almost one-to-one change management.
So anytime someone has a question or, oh, why did you do something like that, we are open to discuss and explain. So there’s a lot of iteration actually with the people. Also, Sometimes I want to do something technically, but at the moment it’s not possible because we only have one developer or because we don’t have the APIs yet or so there’s a lot of things around.
Not teaching them how IT works, but more like managing expectations as well. But that’s also sometimes frustrating, because I have mockups and I validate it then, and then when we arrive on the dev side, it’s oh, we can’t do that yet, but we will do it. But eventually, we are going back to the user and say, we already implemented that, and that this part is going to be implemented a little bit later.
So I think it’s about building trust, first, so just the fact that we are going to understand how people work and trying to analyze that is already a first step of building trust. And I think that the complicated part is, yeah, building and keeping the trust.
So for now, we didn’t have that many complaints about, yeah, we told you to implement something like that. But it’s also about making them understand, and I think that’s the trickiest part that I’m here to understand what they need. And I’m here to understand the pain point and I’m here to provide a solution.
And since there’s a lot of areas in enterprise where, as I said, they were working mostly with IT people and they had to be the designer, like the user had to say the IT people, I want a checkbox that says that at this specific place of the interface. Because otherwise, if they don’t specify this super strictly, It might not happen.
So I’m trying to fight smoothly, fight like I have people when I’m showing them or like when we are doing some tests or just feedback sessions that they are like, oh, I’m sorry. I wasn’t really helpful. I didn’t have a lot of feedback. It’s fine- you’re not supposed to do the design- I’m supposed to do the design. You’re just supposed to tell me, show me how you work, and then we will find the solution. So that’s the kind of fun part as well is to say okay, you had a need today. We didn’t implement a checkbox the way you wanted us to do, but we implemented a way for you to do that.
Does that way work or does that way not work? And sometimes, because we’re not doing usability testing on every single checkbox of the interface. Oh, sure. Otherwise, it would be super, nothing would ever be shipped. So yeah, sometimes we say, you know what? We go on a hunch. We do that, it goes into the next release, and then for the release we ask for feedback.
And for instance, at the moment we’ve released something on a hunch and we got interesting feedback from the user and they say, no, actually, you know what? We prefer it that way because it makes more sense for different reasons, not gonna enter in the UI details. So now we are reverting back to another version of that and see how this goes.
So there’s also a lot of integration, but I think if we build trust, And we make them understand that it’s not maybe the way they imagined it. But it does what it needs to do- in a kind of okay way. Most of the time they’re quite happy. Like I had the opposite actually. I had people who said, yeah, I need that here and here, and when we offer the solution, they were like, oh, actually your solution is better than mine.
It’s yeah, I know it is- don’t worry. Again, it’s my job. It’s a little bit like, I don’t know if you could call this however I wanna call that, but it’s like years of people having to tell exact needs and know when they’re like lost when you don’t ask them for needs. You just ask them to understand how they work.
It’s okay. I just want to observe all your work and that can be fine. I have an example for that. We were redesigning, we were migrating a page. And on that page there’s a big list of operations and, one of those users, she said, yeah, it’s a little bit annoying. I would like to have an export to excel for this big list.
I was like, okay, but you don’t have an export to Excel today, so how do you do that? So she goes into the page, she selects the whole table, she copies it into Excel, and I’m like, okay, no. What do you do with this? Page in Excel and she goes into the Excel filters and she removes every operation that is not active anymore because she says, yeah, I don’t need the inactive one.
I need to be inactive, so I don’t care about that. Ah, okay. And I was like, okay. So actually what you need is not an export to Excel button but a way to remove the inactive operation from the list. And the cool thing is that now we have a new Technical stack that is a little bit more modern and we can actually put the filters directly in the table in the browser.
So instead of implementing an export to Excel button, what we did is we have those tables and we have a lot of filters. And if they say, I don’t care about inactive operation, they go to the filter and it removes every inactive operation from the list. And that’s it. Yeah. So in places where it makes sense to export Excel because they need to do some stuff with the datas, like graphs and share and stuff.
But for this particular place, the need was not exporting to excel. The need was, removing stuff from the screen and we have other ways to do that. But she expressed the need to export to Excel, because that’s how she does it, basically. That’s like she used to do that. So I think that’s the big difference between IT collecting requirements and users saying, I want an export to Excel versus me digging a little bit more and saying, ah, maybe I understand what you need, and it may be an export to Excel, but maybe we can provide something even better. And she was super happy that she can filter directly in the browser.
’cause then it’s like one, it’s way less steps to do that in the browser and the whole putting it in the Excel like she, she used to do before.
[00:18:44] Tina Ličková: And what really interests me is this building trust. But before that is this, how do you identify the users in a way that, okay, these are the people that I need to talk to.
How do you stumble across a lady that wants to have Excel export and then how, yeah how do you identify them?
[00:19:06] Stéphanie Walter: So I’m working with business analysts and in the bank we actually have people who are supposed to do the coordination between IT and business users. So usually when I need some users for specific things, I’m just reaching out to the people who already know that.
So the bank is, this is really organized by departments. So I know that some pages are more used by some departments than others. So usually it’s first thing is trying to find a few people via coordination. Now we have, I think, 100 people as beta testes. So I already have this kind of pool today.
But before that, yeah, it was whenever we would migrate to new pages or new topics. I had my business analyst who would go and say, okay, I need people to do that. And then he tries to find them based on like context, internal context. And then one little trick is at the end of each interview, what we would do is oh, by the way, can you recommend us to people?
Nice. You could talk to me as well. So that and that’s really cool because since that person recommended us, then we could say, oh man, we did that with that person. She recommended that we talk to you. Which works so much better than just okay, I found the name of someone I know. They don’t know me.
And out of sending a name, I was like, hi. I know you’re doing that at the bank and I’m looking for people to talk to, which is a little bit creepy. So recommendation, even for internal employees, is a really good way to just reach a wider audience and make sure you find the right people.
Most of the time, like even during the interviews, people would just like, oh, you know who you should talk to. I think this person would be someone you also need to talk to. So just organically, people would refer to the people. For the same tasks and activities. Yeah, that’s the perks of working on an internal tool is everyone is an employee, so it’s easier to recruit and find other people since at some point it’s all connected.
[00:21:09] Tina Ličková: And the building trust, how would you describe works that, and how, what are the, maybe there are some practices that you use every time or regularly. What would you recommend for building a trust?
[00:21:25] Stéphanie Walter: I think one of the main things is, and it’s something I repeat all the time, my business analyst repeats all the time that our door is always open.
So it’s like whenever you have an issue, like at the end of the day, I have people who contact me with issues that have nothing to do with my project, but I will still answer them because I don’t want to know, lose the connection. So it’s really if you wanna send us an email, if you wanna send us a Skype message, a team message.
Whatever, call us. Please feel free to do so there’s a lot of things where we adapt to whatever, however they want to communicate. And so it is a lot about showing that we are here for them and I have people who then go back and regularly do this kind of thing. So the thing is we have a part of the interface in a beta version.
So some people already have access to that. And what we do with them is we do a first session where. It’s not really a usability test because you can’t really write tasks upfront because we are doing, we are asking them, okay, this is the new interface. We are not going to present it to you.
What we want you to do is try to do whatever you are supposed to do today with the whole one. What? With this interface, we are here in case you have big roadblocks, but please do that. And we observe you if you want to think aloud. So it’s usually like a one hour session where people try to do what they used to do with the old one, and then of course they’re going to explore a few new features.
So it’s not like in the book usability testing, because in usability testing, when someone asks you, oh, what does this thing do on the screen? You’re not supposed to reply to them. Here we say, okay, what do you think it does? Maybe you can click on it to try it or, Something like that. And after they had this first session, what they can do is use it for a month and we have this user diary, which is an Excel sheet.
’cause I work in a bank, obviously it’s an Excel sheet where I have different columns. And so the idea for the people who are not is to use the diary. It’s a method to capture. Whatever you need to capture. Most of the time it’s behaviors or tasks and things over time. So what we do is we give them an Excel sheet.
We tell them to use the interface for one month, and then during the month whenever you need to do something with the old one and you can’t do it with the new interface, whatever it is. Please log an entry in the sheet. And then we have Colin, where we ask, what were you trying to do? How often do you do that?
Why weren’t you able to do it? Sometimes it’s, yeah, because this content wasn’t migrated yet because we are migrating in an agile one. Sometimes it’s, there’s a lot of – we moved the content to another place and they’re not used to it yet. So what we do after that is also a follow up.
So a lot of those follow ups are actually either oh yeah, this content wasn’t migrated, or, oh crap, this is a bug. It’s rare, but sometimes for very specific niche stuff that we find bugs like that. And yeah, sometimes it’s just a usability issue or they didn’t find it, this thing was moved to a new page because we changed a lot of the architecture – so sometimes it’s just like getting used to it.
And but usually like when they log something at the beginning and then we go back to them with the user days, they’re like, oh yeah, I logged it. But two days later I found where it was. So it’s perfectly fine. And this is also like this kind of building trust if we are not just asking them for feedback.
We really like following up on feedback and. And a lot of stuff. So yeah, it’s a lot of back and forth on really building a community of users. We can talk to them, they can talk to us in an easy way and just be there for them basically.
[00:25:13] Tina Ličková: But it also sounds like when I’m listening to you, that basically stakeholders, which is not my favorite word, because those people are also your users, and it overlaps. Could it be or?
[00:25:28] Stéphanie Walter: Depends on stakeholders, like super high level stakeholder, they’re so high in the bank they’re not on the daily basis of contracts, operation and stuff. So they are, I think, too high up to actually use the tool. But some people still like heads of units, but those people also like maybe a little bit different needs.
It’s more like we classify the needs in different categories, and usually when you go higher up in the hierarchy, those people, they’re not going to do things, but they want some reporting. So one of the things we want to bring in the new interface, because now you can do a lot of things in the browser, is our reporting, but also like some graphs.
So we have a lot of tables and we say, okay, it would be nice that we could switch some of those tables from table to graphs. So this is not developed yet because technically it’s a little bit complicated, but that’s one of the things. So now high level stakeholders like sponsors, and those are not really our users.
[00:26:29] Tina Ličková: And how do you build trust on that side?
[00:26:31] Stéphanie Walter: I’m not that involved with that because I’m a consultant, but yeah, I’m helping my colleagues. So there’s a lot of things going around. So that would be more a question from my pm and my PA and my technical architect. But I met some of them.
They know I exist. So that’s really nice. And so yeah, but here it’s more about reporting and stuff, but yeah, that’s more like politics, that they’re trying to keep me out of it at the moment so that I still have time to do my job because I’m the only designer in the team.
They’re trying to preserve me, which is nice.
[00:27:07] Tina Ličková: Okay. Your recommendation would be to work on an enterprise project as a consultant- so you have the little bit of a distance, but you are still involved.
[00:27:17] Stéphanie Walter: Honestly, it depends. I’m lucky, like every time I worked on a project as a consultant, they really understood that I’m a consultant. I’m an expert in my field, so they trusted me. I know some consultants, it didn’t go that well for them. It’s oh, you’re just a consultant. You’re not an internal person. Your voice matters less.
So I know consultancy can be a double-edged sword. I’m lucky it never happened to me like most of the time. As a consultant, I’m. They see me as the expert, so they’re just more than happy to listen to what I have to say most of the time. But yeah, I know sometimes it’s not always the case. So I think it would depend on the client to be honest.
Sometimes it’s better to be a consultant because then the people value your expertise. Sometimes it’s easier to be internal, one because the voices of consultants matter less than in internal people. But it’s hard to know when you arrive on a project before you work there. Unless you can, maybe you know someone and you ask around, but yeah, it really depends on the company- how they treat consultants.
[00:28:27] Tina Ličková: And going back a little bit to the research part and the UX part, if you would have any recommendation for people who are just stepping into the B2B or enterprise field, what would it be? What to be, for example, really to be careful about.
[00:28:47] Stéphanie Walter: Breathe. It’s scary, it’s messy. People will throw at you a lot of business knowledge and you will feel so overwhelmed at the beginning.
Like really? Sometimes you’re like, what? I can’t understand that. It’s impossible- My brain can’t. So yeah, it’s a lot, especially in complex businesses, it’s really scary at the beginning, like the complexity. But the good news is most of the time the complexity can be broken down in small little pieces.
And then I like to see this. I was like when you have a lot of strings that form a big ball at the beginning, you see the ball and you’re like, how am I gonna untangle that? That’s horrible. And then when you start your research, you start talking to people, you can see a small little part of the strings and then you say, ah, I can pull here.
It’s oh look, I actually have something already here and here. So it’s really about, I would say, untangling the mess. And then it’s about finding allies, like finding people who can help you understand the business. And I would say try to understand the business before going to talk to the users if possible, or.
Just have enough business knowledge. So you’re not going to ask them about every single acronym during an interview or something like that. So go prepared. But I think it’s the same for every single user research. It’s just that in enterprises you might sample up on topics you know nothing about, like cranes or how you do a lot of disbursement and reimbursement in a bank industry, which is something I didn’t really know how it worked before. So yeah, normally there’s like people who can help you with that. Usually a business analyst or someone in the team who has enough business knowledge so that when you go to the user, you already know a little bit of the field so that when they talk to you and you’re completely lost.
Otherwise, it might be a little bit complicated to do in an interview because you will just ask questions and they will answer stuff. Then it may not make total sense to you, so you’ll not be able to bounce back and do follow up questions, but, and yeah, sometimes it’s also okay to ask users genuine questions, like sometimes I know the business.
I know how it works, but I wanna check that like the user. Their mental model is the same as the one from the business and from the IT side. So sometimes I would ask questions and I know the answer on the IT and business side, but I’m super curious to see how the people will describe that.
And sometimes we have surprises like – okay, we might have a little problem because the process we imagine is not really the process they’re going through. So let’s go back to trying to find a better solution. But yeah, complexity is scary and you need to find some people to help you navigate that.
And it’s okay to ask a lot of questions, and I think it’s also okay to not take everything for granted. So it’s a little bit complicated to find a balance because sometimes you end up with a table with 20 columns and you’re like, Do they really need the 20 columns? Can’t we remove some of those?
And then you start trying to understand the business and you’re like, oh crap, we need the 20 columns. Because of different reasons. So I think it’s finding the balance between: what do we keep from the old interface? Like what decision that was taken before still makes sense today versus why, what doesn’t make sense and what can we improve?
So yeah, it’s a tricky balance sometimes to find this soft spot of what from legacy still makes sense versus what’s evolved so much in the business that the stuff that was built 15 years ago doesn’t work anymore.
[00:32:39] Tina Ličková: You mentioned understanding the business, then going to the users sometime before you also mentioned understanding the different user roles.
That would be something and what is also interesting for me is understanding the IT behind it and you tackled it a little bit with the IT stuff and you probably also report to the IT team.
[00:33:01] Stéphanie Walter: So I was in the IT team most of the time when I was working on enterprise use.
I don’t know a lot of companies where UX doesn’t belong to IT, like in Luxon. We have one company where they have a UX department that belongs to innovation, which is amazing. But yeah, most of the time, like in lower maturity, designers will belong and answer to IT.
[00:33:23] Tina Ličková: Interesting.
[00:33:23] Stéphanie Walter: Yeah. So it depends.
For me, it’s nice because then I work directly with the developers and I know it’s technically possible or not. So we have a lot of discussion as well as on my designs and the proposals, and I’m like, yeah, I would like to do that. And can the data do that? And also a lot of time before going to the users.
So the thing is, we are migrating an interface that exists. So the first thing I do, usually when I need to migrate something, is I go there and I look at what’s on the screen. Mostly, like I have some samples, but sometimes I have some ideas of what is there, but maybe I just have kind of a sample bias and it’s more complicated than that for some other contracts, and then I’m going to, I’m going to depth.
I’m like, okay. I think the structure of the page, like this is more information architecture work, but I think the structure of the page is this. We have that option and that – can you confirm or are there more options? Or more mess I’m not aware of. And we need to tackle it as well. And most of the time, the developer can answer part of the question.
Sometimes the users also answer the questions like, okay, be careful because here, 90% of the time you have this value, which is okay, but if you have this value, then you have a whole other page. I was like, oh crap. More exceptions, there’s nothing my developer hates more than exceptions. Because then it’s not reusable, so I’m like, I’m okay designing many exceptions. I can design many versions, but at some point my developer will let me. So yeah, definitely a lot of back and forth and understanding. But the thing is I also like to be able to challenge the technical stuff. ’cause sometimes they’re like, yeah, but it’s complicated.
So then it’s a discussion between is it worth investing in that new thing? So we have this priority metrics where we do some meetings with me, business analyst developer, head of architecture. And we give points to different things we wanna do. So it’s, how important is it for the business?
How important is it for the users? How much is it going to cost to develop that, and how much is it going to cost to design that? And then this gives a quadrant with things that are cheap and easy to develop and super important for the users. This is the stuff we’re trying to do first, and then you can find the balance between all of the things.
So it’s usually kind of discussions and a lot of compromises as well on the designs. But yeah, at some point The thing is I’m pushing for the users. It’s like I will always push for the users. That’s my, that’s my job. So if you ask me, is this really important? If I have a lot of users who want this and think it’s important, or if it’s going to help them solve a problem that I need to solve often on a daily basis, then yeah, I’m gonna push for it.
And if it’s gonna cost more, then we need to find some kind of balance or something like that. So yeah, there’s a lot of negotiation with it, but it’s fine. It’s, I think, part of the project.
[00:36:20] Tina Ličková: I’m amazed at how much joy is coming out of you when you are talking about, and how lightness.
So in a way that, okay, it’s something that I do and there’s this light feeling of that it’s smooth. And this amazes me, and this is something maybe when I can ask you for a human advice now, like how do you master staying in this smooth flow in this project?
[00:36:47] Stéphanie Walter: I think you interviewed Debbie and she has this phrase like low action hero and no low ego action hero.
Ego is the important word. And I think it’s about that. It’s about understanding that at the end of the day, I want to provide the best experience possible for my users to help them with their daily job. And. At some point, if a developer comes and they have a better solution, then the thing I was going to do to them, I will take that solution.
I like it, I’m not in love with my designs. If someone after a discussion can find something even better, then it’s perfectly fine. So at some point, if you have a team, I think, and it’s also the people I work with who are really nice on a human basis as well.
But if you have a team of people who want to do their best and everyone is working together towards the right direction and there’s no kind of ego saying, I really want this solution to be implemented because it’s my solution. And, that’s the, it is silly, but I’ve been on a project where, It was a contest of ego at the end of the day between two things to be implemented between two designers.
And everyone thought their solution was the best. And even if you come with a user testing and show that one of the solutions, then it’s yeah, but okay. You can’t win with people when ego goes Into here. So I think on a human basis, that’s the thing, is being open to other people’s suggestions, not following.
Falling in love with your work and knowing that, yeah, if someone has ideas to improve it, like I was designing a feature and I didn’t really imagine that we could have drag and drop because I thought it was technically super complex. So I didn’t even dare to go into direction. And when I showed those screens to my developer, the first thing it was like, Why don’t we do drag and drop for that?
It’s oh, you are the one who said that I didn’t like it. Yeah, if you’re open to drag and drop, I’m going to design the dragon drop thing because I think it’ll be a better experience, but it’s so oh cool, let’s do that. So it’s really about, yeah. Communicating and it’s also building trust with your team.
Like sometimes you might do some things that don’t really work or, so it’s about, yeah, trust and making sure that the small frictions that you can have sometimes in the team just stay small and don’t escalate. And so yeah. Human side, no, but I’m lucky that, really great team. And that also helps a lot like deescalate stuff.
And also I think it’s about acknowledging when you’re in a bad mood and sometimes you might react to stuff in a heavier way that you wanted to. So just tell the people like, look, I had a bad night yesterday, so don’t worry if I’m less cheerful or if the answer’s a little bit more direct, it’s just, I had a shitty night.
I have a headache. Gonna be fine. It’s not you, it’s me. So just acknowledge this kind of thing in a team- I think it can also help make the communication better because then you’re not like, wait, is she mad at me or something? It’s no, I’m not mad at you. It’s just that I have a headache.
Something like that. So yeah, being really clear about this kind of thing can help.
[00:39:55] Tina Ličková: And as one last question probably. Or one of the last you’re ending the project or ending going live with the project in September. I. What, what happens after it for you and for the project?
[00:40:11] Stéphanie Walter: Ah, oh, the project is just like one small thing, part of what we can do.
So now I’ll still be around. So September is supposed to be the official time. When we say to people, look, this is the official tool, but I have a backlog of 100 items to research. It’s an MVP today. We put the priority on migrating content, but there’s a lot of features that we want to bring to the users that are going to improve their lives.
There’s a lot of things around customization. Know that people see that we can do more things in browsers. They also expect more things. So we have things about being able to hide some part of the interface because some people never use some stuff because it’s there for the department or something like that.
So yeah, we still have a backlog of a lot of things to research and then there’s It is a little bit complicated, but there’s a lot of things around this interface. It’s not just that interface, it’s an ecosystem. So no, as long as they keep me and we have a budget and we can do amazing stuff I think it should be fine.
It’s a product at the end of the day, even if you have an official day to say, okay, this is the new one, and. Then you keep on having things that evolve and the business is evolving anyway. So I hope they will keep on having the project evolve, but that doesn’t, yeah, that’s beyond my control.
But I think we should be able to manage at least bringing more features and stuff. And there’s a lot of other demands for the small projects as well, so it should be fine.
[00:41:48] Tina Ličková: Great. Stephanie, where can the people follow you? Where can they get to know more about you?
[00:41:56] Stéphanie Walter: So I have a website and a blog – stephaniewalter.design and yeah, usually I’m on Twitter and LinkedIn. So Twitter is Walterstephanie, because I could not get to Stephanie Walter LinkedIn is Stephanie Walter Pro – because again, a lot of other Stephanie Walters around, so I had to find a way.
[00:42:18] Tina Ličková: And is there maybe something where you are like, oh, Tina, why didn’t you ask me that?
[00:42:24] Stéphanie Walter: Nope, I don’t think so.
[00:42:27] Tina Ličková: Good. So thank you very much. I really like the attitude that you’re bringing into the work and it reminds me how fun stuff could be.
[00:42:37] Stéphanie Walter: Oh, then you should have to design a table. Yay.
[00:42:42] Tina Ličková: Table?
[00:42:44] Stéphanie Walter: Yeah. Tables. No, like UI tables. Not an actual table.
[00:42:47] Tina Ličková: Okay. Okay. I was like, oh, woodworking. She’s also woodworking. That’s interesting. Stay on table. But no, it’s a UI table. Good. So wishing you luck.
[00:42:57] Stéphanie Walter: Thanks.
[00:42:57] Tina Ličková: I hope you have more fun with the product. Thank you very much for speaking with us.
[00:43:03] Stéphanie Walter: Yay. Thank you for having me.
[00:43:06] Tina Ličková: Thank you for listening to UX Research Geeks. If you like this episode, don’t forget to share it with your friends.
Leave a review on your favorite podcast platform and subscribe to Stay updated when a new episode comes out.