Register Now to Beegin Your Journey!

Register Now For Free to Beegin Your Journey!

Register Now to Beegin Your Journey!Register for free

UX Geeks Podcast Transcript: Episode #5 Stéphanie Walter

UX Geeks Podcast Transcript: Episode #5 Stéphanie Walter
UXtweak Team
•  30.05.2022
Hello and welcome to UX research geeks. I'm your host - Tina Ličková - a researcher and a strategist, and this podcast is brought to you by your next week and only one UX research tool.

This is the fifth episode of UX research. Where we spoke to Stephanie, who is a UX researcher and designer based in Luxembourg. She has 12 plus years of experience and specialized in enterprise UX and mobile. She teaches, speaks, and write about design UX, research, accessibility, cognitive biases, design, dev relationship, and much more.

Hello, Stephanie.

Uh, I was thinking, and when, when I was thinking about how we structure the show, the first thing that came to my mind, uh, coming from our kickoff call was Stephanie and cranes. True. We were also thinking, to be honest, to, uh, 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. Yeah. Yeah. Tell me, tell me really what is,

but tell me really why, why is Stephanie into cranes or what does screen or we’ll do cranes? Uh, 

I’m not into cranes, but I happened to have learned things about cranes together. I was working on a project that was about monitoring a crane system. So you have to imagine usually on a construction site, you have 1, 2, 3, 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 the super long arm. So you have to put them somewhere in the construction site to make sure that even if their 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 kind of super fun as a nerd because, uh, I had the real-time position of all of those little cranes mapped out on my screen. So I was like, is this real? That other guy was like, yeah, that’s I’m somewhere in Paris, there are three cranes.

And I could see them rotate in real life. I was like, oh, this is so cool fun. So yeah, I learned a lot about, uh, how a crane works and the different constraints, and why you need to monitor them. Basically when there’s too much wind, uh, you need to let them loose, which mine’s a little bit…, a little bit counterproductive, but the idea is if there’s too much wind, the army needs to be able to rotate how, um, how it wants to rotate based on the wind.

Otherwise, you didn’t mind just having the crane fall or something. So, yeah, it was really fun. Interesting project. I didn’t know anything about cranes and how they worked before that, but, um, yeah, also quite challenging because you had, it was a little bit of that realization. Like how do you show different cranes and identify them on the map?

Because there was kind of. Not really 3d rendering, but like, you know, like this fake 3d in the browser. So you could kind of move it around to see the position in real-time. And, uh, yeah, the monitoring part with ROS and stuff. So it’s basically, you need to make sure that you don’t use only color for instance, because of.

Colorblind users. Uh, you can say, oh crap, the red one has an issue. It’s like, yeah, which one is the red one? So there were a lot of challenges for having a visual language to make sure that all the users, even if they are color blind, for instance, could see which crane is which, and which has an issue, and things like that.

Yeah. Really interesting, really, but I still imagine you navigating your crane. 

I would love that. I didn’t ask the client to do that, but they should have like, Hey, can I just go into the crane? 

You know, just have you been, but have you been physically? 

No, I wasn’t. I think the issue is, I don’t know if they have a little elevator, if you, or if you need to go through a ladder and elevator, I think I would be fine, but if I have to use a ladder with the wind and the height, I’m not sure we’ll be okay with that. But if it’s kind of a, you know, like a closed little elevator, I think I would just like, don’t move until it happens. That would be, there would be fine. Definitely. But no, it’s super fun because no one does a lot of construction sites in Luxembourg. I was like, oh, this crane is rotating because there must be so much wind over there or something like that.

It’s not an obsession, but sometimes I do get this. Oh, I know about that, which is fun. So kind of interesting knowledge to have, but yeah, 

Well you never know when you need a crane. 

My question is, I, I mean, I can imagine the interface and how you were, as you were explaining, uh, watching the cranes and, uh, getting some details.

Have you actually, did you have a chance to talk to the crane navigators, and if yes, what came out of. 

Uh, unfortunately not directly for that project. It was like years ago I saw like eight years and UX design. Wasn’t that popular yet in, uh, in France. So I had information kind of through a footpad, which was, uh, someone made, uh, 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.

No worries. No worries.

So like why I like working in an internal tool, it’s easier to talk to the users because are somewhere in the building. 

Yeah. Yeah. And that’s a good bridge to what I wanted to ask you.

Like, what are you doing? After the crane history.

Years after the crane history, I’m working as a consultant in Luxemburg. And, uh, today my main client, my only client actually, is a European investment bank. So it’s a little bit, uh, complicated because it’s half European, half private. And basically, they’re doing some loans for different projects, uh, all over the world.

It’s just like, it’s 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 kind of a project management tool that is following a project from the beginning to the start. So from someone saying, oh, we need to build a bridge somewhere in Germany. And, uh, we can have European. Uh, money from for that, because it’s many 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 dispersed, reimbursed. So all the classic stuff with loans, except that it’s like four kinds of a big project and different areas and KPIs.

And yeah, we have this old tool that is a thing, 12 or 15 years old, and we are completely rebuilding. Uh, for various reasons and mostly because what we have today, uh, is a technical debt on the old interface, and we can provide new features to the users. So due to. The fact that it has been built a long time ago. There are a lot of technical restraints and this is why we are doing a new tool for the technical part. But changing the technical stack 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 like, keep up to date with the business where we’re rebuilding that one. And 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 kind of life as you say, for our internal users or officially in September.

And did this combines two things where I here, I mean, I personally love to finance field and, uh, research in that area, but it’s financed and it’s, uh, kind of like governmental slash private and it’s, uh, 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. Not boring, but what is your reason? Why do you work on it? And one you liked to work on it. 

 Uh, 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’s the case in Luxembourg, but he needs to get similar in a lot of countries as well. A lot of. Enterprise projects today they’re really ITU-oriented. So you sometimes have business in ideas or like PMs who try to gather technical requirements and then they build something. It goes to the users and that’s basically it.

Yeah. Sometimes it works, but most of the time, the issue is between the moment they gathered the technical requirement and the moment the thing arrives at the user, they might be changing things. So it’s already outdated or something like that. So it’s kind of a little bit new for my users to have a UX designer who tries to understand their needs.

So it’s really, really nice to work with them because then you really understand how they work on a daily basis. 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 kind of bridge the knowledge gap from the business information they need.

The interface 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 are a lot of things around, I’m trying to grid 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 are making people’s daily lives and daily jobs a little bit easier. Based on their job. I’m just kind of really happy for them. If I can make something a little bit less annoying or complicated because when they work with some, 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 like, we have to duplicate information because those two systems, they don’t connect today. So 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 duplication, they might be errors. They may be mistakes and stuff. And since it’s a finance domain, you don’t want to do mistakes or you try to do as little as possible. So there’s a real, like, like being able to help people and actually see the results of helping them.

This is really nice on that.

Before I go into, like what kind of methods you mentioned already tap disc analysis. I’m also curious because what I know when I am, uh, doing some B2B projects, Uh, 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 are like, but I told you that I want, I need this and that.

And then they don’t see it because of course you made to analyze this and you have to like some do aggregate the knowledge and, um, make the sign, those design decisions. But how do you work with the people then explain that? Why did it end up being like this and not like that? 

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, testing the new version and explaining them, doing new features, and all of that. And we are doing almost like one-to-one change management. So anytime someone has a question or, oh, why did you do something like that?

We are open to discussing and explaining. 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 API yet, so there are a lot of things. Not teaching them how it works, but more like managing expectations as well.

But that’s also kind of, sometimes it’s frustrating because I have more gaps and I validated them. And then when we arrive on the deaf side, it’s like, oh, we can’t do that yet, but we will do it. But eventually, so we are going back to the user and saying, we implemented already that, and that this part is going to be implemented a little bit later.

And so there’s a lot of, I think it’s about building trust. So just the fact that we are going to understand how people work and trying to analyze that is already kind of a first step of building trust. And I think that’s the complicated part 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. 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, there were working mostly with IT people and they had to be the designer like the user had to say the ITB, but I want to check the box that says that at this specific place of the interface, because otherwise.

If they don’t specify this is super strictly. It might not happen. So I’m kind of trying to fight smoothly, fight that. Like I have people when I’m showing them or when we’re doing some tests or just feedback session, I’m like, oh, I’m sorry. I wasn’t really helpful. I didn’t have a lot of feedback. You know, it’s like, it’s fine.

You know, like 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, um, fun part as well as to say, okay, you had the needs today. We didn’t implement a checkbox the way you, 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 are not doing usability testing on every single check box of the interface, for sure. Otherwise, it would be soup. 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 asked for feedback, and for instance, At the moment, um, 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 going into the UI details.

So now we are kind of, um, reverting back to another version of that and see how this goes. So there’s also kind of a lot of intuition, but I think if we build trust, And we make them understand that it’s not maybe the way they imagined. But it does what they have to do kind of okay. The 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 you, we offered a solution. Oh, actually your solution is better than mine. Yeah, I know. It’s, don’t  worry again. It’s my job too. It’s there a little bit. Like, I don’t even know if he could call this a, how I won’t even call that but is like years of people having to tell exact needs and know when they, they like lost when you don’t ask them for needs, you just ask them for like, understanding how they work.

You know, it’s like, it’s okay. I just want to observe where you work. And that kind of is fine. Like, I have an example for that. We were redesigning, we were migrating a page. And, uh, on that page, there’s a big list of, um, operations and one of the users she said, yeah, it’s a little bit annoying. I would like to have an export to Excel for these big lists.

It’s 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, um, selects the whole table. She copies it into Excel and I’m like, okay, no, what do you do? And she goes into the Excel filters and she removes every operation that is not active anymore because she says, yeah, don’t need the inactive one.

I need to the inactive. So I don’t care about that. And I was like, okay. So actually what you need is not to export to Excel button is a way to remove the inactive operation from the list. And the cool thing is that no, we have a new. Technical stack that is a little bit more modern and we can actually put the features 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 the inactive operation, they go to the filter and it removes every active operation from their list. And that’s it. Places where it makes sense to export to Excel because they need to do some stuff with the data, like graphs and charts and stuff.

But for this particular place, the need was not exporting to Excel. The need was to remove stuff from the screen, and we have other ways to do that, but she expressed the export to Excel because that’s how she does it today. Basically. That’s like she was used to doing that. So I think that’s the. Kind of the difference between, um, IT collecting requirements and user saying, I want to export to Excel versus 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 when there’s way fewer steps to do that in the browser, then the whole putting it in Excel.

Like she used to do before. 

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? Uh, I have an excellent export. Uh, and then how, yeah, how do we identify them?

So I’m working with a business analyst and I’m 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 use for specific things, I’m just reaching out to the people who I already know. So the bank is, this is really like organized by departments.

So I kind of know that some pages are more users based on departments and others. So usually it’s the first thing is, uh, trying to find a few people via coordinations or. Now, we have, I think 100 people, as beta testers who 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, uh, at the end of each interview, what we would do is like, oh, by the way, can you recommend us to people I could talk to as well?

So that, uh, 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 like so much better than just like, okay. I found the name of someone. I know they do it. They don’t know me and out of the blue sending an email, it’s 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 like internal people, employees a really, really good way to. Reach a wider audience and make sure you find the right people. I, most of the time, like even during the interviews, people would just like, oh, you knew who you should talk to.

I think this person would be someone you also need to talk to. So just kind of organically people would refer to the people at. For the same tasks and activities. Yeah. That’s the perks of working on internal Tuliza. Everyone is an employee, so it’s kind of easier to recruit and find other people.

At some point, it’s all connected 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 trust? 

I think one of the main things is, and it’s something I repeat all the time.

My business analysts repeat all the time it’s: “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 they would still like to answer them because I don’t want to lose the connection.

So it’s really like, if you want to send us an email and if you want to send us a Skype message or teammates. Whatever call us, please feel free to do so. So there’s a lot of. Of things where it just like, we adapt to whatever or however they want to communicate. And so it’s a lot about that. Like, I’m showing that we are here for them and, uh, I have people who then go back and regularly do this kind of thing.

So, um, so the thing is we have a part of the interface is a, in a beta version. So some people have already access to that. And what we do with them is we do kind of a first session where. It’s not really a user usability test because you can’t really like 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 were supposed to do today with the old one, but with this interface and we are here in case you kind of. Have big roadblocks, but, uh, 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 by 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 into trial.

Something like that. And after they had this food session what they can do is use it for a month when we have these a user diary, which is an Excel sheet because I work in a bank, obviously, it’s an Excel sheet, um, where I have different columns. And so the ID for the people who are not used to using a 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, which they use the interface for, 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 look at an entry in the sheet.

And then we have coloring where we asked, 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 its discontent wasn’t migrated yet because we are migrating in an agile way. And sometimes it’s, there’s a lot of, uh, those that are just like, we moved the content to another place and they are not used to each yet.

So what we do after that is also a follow-up. So a lot of those for a website, I actually either like, oh yeah, this content wasn’t migrated or, oh crap. This is a bug. You found a bug. We are going to fix that. We need to fix it. It’s rare, but sometimes, uh, for very specific niche stuff we find bugs like that.

And, um, yeah, sometimes it’s just usability issue or like, ah, they didn’t find, um, the, um, this thing was moved to a new page because we change a lot of the, um, the architecture. So sometimes it’s just like getting used to it. And, um, but usually like when they look at something at the beginning and then we go back to them with the user days, they’re like, oh yeah, I loved it.

But like two days after I found where it was, so it’s perfectly fine. So, and this is also like this kind of building trust. We are not just asking them for feedback. We really like following up on feedback. And a lot of stuff. So yeah, it’s a lot of back-and-forths and really building a community of users. Uh, we can talk to, they can talk to us in an easy way and just be there for them basically. 

But it also sounds like when I’m listening to, basically stakeholders, which is not my favorite word because those are people who are also your users and it’s overlapping. Could it be? 

Depends, uh, stakeholders like super high-level stakeholders this so high in the bank.

They, they’re not on the daily basis of contracts, operation, and stuff. So they are kind of, I think, too high up, uh, to actually use the tool. But some people still like the head of unions, but those people also like maybe a little bit different needs. It’s more like we classify the needs into 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 drafts. So we have a lot of tables and we say, okay, it would be nice that we could like switch some of those tables from table to graph.

So this is not developed yet because technically it’s. It’s a little bit complicated, but, uh, that’s one of the things. So now I take higher-level stakeholders like sponsors and those are not truly our users. 

And how do you build trust on that? 

Uh, I’m not that involved with that because I’m a consultant.

Uh, yeah. I’m hoping my colleagues, so there’s a lot of things going around with, uh, so that would be more questioned from my, uh, PM and maybe, and my technical architect with that. I met some of them. They know me. So this that’s already really, really nice. And, uh, so yeah, but here it’s more about reporting and stuff, but, uh, yeah, that’s more like politics that they are trying to keep me out of it at the moment so that I still have time to do my job because I’m kind of the only designer in this.

So they’re trying to preserve me, which is nice to me. Okay. So, uh, the, the, your recommendation would be to work on an enterprise project as a consultant. So you have a little bit of a distance, but you are still involved when I heard really weirdly, uh, honestly depends like, um, I’m lucky. Like every time I worked on a project as a consultant, they, um, really understood that I’m a consultant.

I’m an expert in my field. So they trusted me. Um, I know some consultants, it didn’t go that well for them. It’s like, oh, you’re just a consultant and you’re not an internal person. Your voice matters less. So consultant consultancy can be a double-edged sword. I’m lucky it never happened to me. As most of the time as a consultant, then 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 an internal one because of consultant motherless.

Internal people. So, but it’s hard to know when you arrive on a project before your, 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.

Going back a little bit to the UX research part. If you would have any recommendation for people who are just stepping into B2B or enterprise, uh, field, what would it be? What to be, for example, really, to be careful about. Breathe. It’s scary. It’s messy. Uh, 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, you know, so yeah, it’s a lot, especially in like complex businesses. It’s really, really, really scary at the beginning. As the complexity, the good news is most of the time the complexity can be broken down into small little pieces.

And then like, I like to see design as you know, like when you have an, a lot of strings that form a big ball at the beginning, you see the ball and you’re like, how am I going to untangle that? That’s horrible. And then when you start your research, you start talking to people, you can see as a small little part of the strings, and then you say, ah, I can put here.

I was like, oh look, I actually have something already here on 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.

Just have like enough business knowledge. So you’re not going to ask them about every single app change during, um, an interview or something like that. So be prepared. But I think it’s the same for every single user research. It’s just that in enterprise UX, you might stumble upon topics, you know, nothing about like cranes are like, uh, how do you do, uh, like a, a lot of disbursement and reimbursement in the banking industry.

Something, I didn’t really know how it worked before. So yeah, normally there are people who can help you with that. Usually business analysts or someone in the team who has enough business knowledge so that you, when you go to the user, you kind of know already a little bit the field so that when they talk to you and you’re not completely lost, otherwise it might be a little bit complicated to do an interview because you will just ask questions and they will answer stuff, then.

Not make the other sense to you. So you will not be able to kind of bounce back and do follow-up questions, but, and yeah, sometimes it’s also okay to ask using genuine questions. Like sometimes I know the business. I know how it works, but I want to check that the user’s mental model is the same as the one from the business and from the IT side.

So sometimes I would ask a question and I know the answer on it and the business side, but I’m super curious to see how the people will describe that. And sometimes that surprises them. Oh, okay. We might have a little problem because like the process we mentioned is not really the process they are going through.

So let’s go back to trying to find a better solution. Yeah, complexity, complexities are scary. And you need to find some people to help you navigate that and okay. To ask a lot of questions. And I think it’s also okay to not take everything for granted. So it’s kind of a little bit complicated to find the balance because sometimes you end up with a table with 20 columns.

Do they really need the 20 columns? Like, can we remove some of those? And, um, but 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 kind of 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 it’s, uh, yeah, it’s kind of a tricky balance sometimes to, to find, uh, this soft spot of, um, what from legacy still makes sense versus, uh, what’s evolved so much in the business that the stuff that was built 15 years ago doesn’t work anymore.

You mentioned understanding the business and then going to the users sometime before you also mentioned understanding the different user roles, that would be something.

And, what is also kind of like interesting for me is understanding the IT behind it. And you would tackle that a little bit with the IT stuff and you probably also report to IT or. 

Um, so here, I’m in IT team. Most of the time when I was working on enterprise use, I was in IT team. I don’t know a lot of company where you access and belong to it.

Like in Luxembourg, 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 in the IT. Interesting. Yeah, so it depends. It’s nice because then I work directly with the developers and I know what’s technically possible or not.

So we have a lot of discussions as well as, um, 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, um, 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.

But the most, like I, have some samples, but sometimes they have like 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 model contracts. And then I’m like, okay. I think the structure of the page, like this, is more information architecture work, but it’s like, I think the structure of the page is this.

We have that option and that, can you confirm, or are they a moral option? Or, more mess. I’m not aware of it, and I will 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 and 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 lot of pages like, uh crap, More exceptions.

Like there’s nothing, my developers hate more than exceptions because then it’s not reusable, you know? So I’m like, I’m okay designing many exceptions. I can design many versions but at some point my developer will be mad. So yeah, definitely a lot of back and forth and understanding. But if it is, um, 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, uh, priority matrix where we do some meetings with, um, me business analyst, uh, developer, um, head of the kind of architect. And we give points to different things we want to do.

So it’s, uh, how important is it for the business. How important is it for the users? Uh, how much is it going to cost to develop that? And how much is it going to cost to design that? And then in these gives, kind of a quadrant with, uh, things that are cheap and easy to develop and super important for the users. This is the stuff we are trying to do first.

And then you cannot find a balance between, um, all of the things. So it’s usually kind of discussions and kind of a lot of compromises as with when the designs, but, um, yeah, at some point. The thing is I’m pushing for the users. So it’s like, I will always push for the users. That’s me, that’s my job. So if you ask me, is this really important while 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 they need to solve often on a daily basis, then yeah.

I’m going to push for it. And if it’s going to cost more, then we need to find kind of. Yeah, kind of a balance or something like that. So yeah, there’s a lot of negotiation with IT, but it’s finding, so I think part of the project. 

I am amazed on how would, how, how much joy is coming out of who when you are talking about and how much lightness that means in a way that, okay, it’s something that I do.

And there is this slight feeling that it’s smooth. Uh, and this amazes me, and this is something maybe when I can ask you for human advice now, like how do you master staying in that smooth flow in this project? 

I think you interviewed Debbie and she has this phrase like a low action hero and a no low ego action here. Ego is the important word. And I think it’s about that. It’s about understanding that the, 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 than, I will take that solution.

I like it, I’m not in love with my designs. If someone after discussion, you know, we can find something even better than it’s perfectly fine. You know? So at some point, if you have a team, I think, and it’s also kind of, the people I work with, uh, really, really nice on a, on a human basis as well. But if you have a team of people who want to do their best and everyone is kind of working together towards the right direction, and there’s no kind of ego saying, I really want maybe a solution to be implemented because it’s my solution.

And you know, that’s 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 like everyone for their solution was the best. And even if you come with a user testing and showed that one of the solutions, then it’s like, yeah, but, okay.

So, you know, you can’t, you can’t go in with people when egos 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’s 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 in that direction. And when I should do screens to my developer, the first thing he was like, Why don’t we do drag and drop for that? It’s like, oh, you’re the one who said that I didn’t get, if you open to drag and drop, I’m going to design a drag and drop thing, because I think it will be a better experience, but it’s like, oh, cool.

Let’s do that then. So it’s really about. Communicating and a kind of, it’s also building trust with your team. You know, like sometimes you might do some things that don’t really work or so it’s about trust and making sure that the small friction that you can have sometimes in the team just stay small and don’t escalate.

So yeah, human side. No, but I’m lucky that I have a really, really great team and that also helps a lot like descalate stuff. And also, I think it’s about, uh, knowledging when you’re in a bad mood and sometimes you might react to stuff in a heavier way than you wanted to. So just tell the people like Luke, I had a bad night yesterday, so don’t worry if I’m less like cheerful or like if the answer’s a little bit more direct.

It’s just, that I had a shitty night. I have a headache. It’s going to be fine. It’s not you, it’s me. You know? So just like, acknowledge this kind of thing in your teammate, it can also help make the communication better because then you’re not like, where is she mad at me or something? It’s like, no, I have a headache, something like that. We have been really clear about how this kind of thing can help.

And as one as the last question, probably. Well, one of the last, uh, you were ending the project or ending going live with the project in September. W-what, what happens after it goes live? 

Oh, the projection is just like one small thing we can do.

Part of what, uh, what we can do. So now it’s barren. So September is supposed to be the official time. When we say to people, look, this is your official tool, but I have a backlog of 100 items to research design. It’s kind of an MVP today. We put the priority and migrating content, but there are a lot of features that we want to bring to the users that are going to improve their lives.

Like there’s a lot of things around customization, I know that people see that we can do more things in browsers than they expect, or some of the things. So we have, uh, things about being able to hide some part of the interface because some people never use some stuff, because it’s, therefore I know the department or something like that.

So yeah, we still have a backlog of a lot of things to research. So, and then this. So it’s a bit complicated, but there are a lot of things around these interfaces, not just that interface is kind of an ecosystem. So, now as long as they keep me and the project 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 kind of a new official day to say, okay, this is the new one. Then you keep on having things that evolve and the business is evolving anyway. So I kind of hope they will keep on having the project evolve, but that doesn’t, yeah, that’s beyond my control, but, uh, I feel it should be able to manage at least bringing more features and stuff.

And there are a lot of other demands for the small projects as well. So it should be fine. 

Great, Stephanie, where can the people follow you? Where can they get to know more about you? So I have a, um, 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 the Stephanie one.

Um, LinkedIn is StephanieWalterPro. Because again, a lot of other Stephanie Waters around. So I had to find a way. 

And is there maybe something where you were like, oh Tina, why didn’t you ask me that? 

Nope, I don’t think so. 

Good. So thank you very much. I really, I really like the attitude that you’re bringing into the work and it reminds me how fun, uh, stuff could be.

Not only if you have to design a table.

Good, a table? 

Tables like UI tables. 

Ah, Okay. Okay. It was like, oh, woodworking. She’s also woodworking. That’s interesting, but no, it’s a UI table, good. So wishing you luck. Hope you have more fun with the product. Thank you very much for speaking with us. 

Yeah, thank you for having me. 

Thank you for listening to UX research geeks.

If you liked 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, this podcast was brought to you by UX week and only one UX research tool.

Share on socials |

Read More