Designing for Enterprise Success: Hiring Strategies and Scaling Insights

Hello everyone, I'm really glad to have you all here, especially in these morning sessions. My name is Daria, I'm living currently in Berlin, and I started my career in this field as a designer. As a lot of you, I don't come from a design background - I actually have an architectural degree. I come from architectural background, and when I started working in the industry, I really didn't want to be an architect, so I kind of stumbled upon UX like a lot of you here.
What happened is I started working for a gaming company, and that's where I realized 'Oh, this interesting thing called UI!' I had no idea what that is. 'Oh Photoshop, that's cool! How do I do these buttons? Nice!' And then from there, I kind of ended up somehow in New Zealand and I started a company in New Zealand. That's where I learned a lot about UX and how to build products. Ended up moving to Japan, opening offices in Manila, and now I'm living in Berlin.
Before joining Miro, I actually worked for eight years at Amazon Web Services. For those of you who don't know what Amazon Web Services or AWS is, it's a heavily technical product - it's the cloud compute service from Amazon. So if you're using the internet, we're probably using AWS.
That's a little bit about me, but let's move on to why am I exactly here and why did they bring me on this stage. Before I start my talk, can I get a little bit of a sense of the room? How many designers do we have? I'm going to try to see - it's very difficult to see here. Oh nice! How many designers who work in a SaaS product? Cool. How many of you work specifically for a technical persona like an admin, a security engineer, engineer? I cannot really see in the back. How many of you are interested in this field? Good hands, nice! I hope I see more hands by the end of my talk.
Imagine this: imagine you get a job and somebody tells you you get 50,000 users or 100,000 users who are going to be using your product, and your company and your client have dedicated support. They will be helping you, you will have an easy way to research - sounds amazing, right? The reality is very, very far because that comes with a huge challenge.
Before we dive into the challenges, let's talk a little bit about Enterprise - not this Enterprise [referring to an image], and now that I got your attention, this enterprise UX Enterprise. This is more or less the definition that I'd like to give, and the definition is very vague and it varies - nobody really knows what enterprise is. In some companies, it's about the size of the company, in other companies is what this company does, but it's very vague.
When it comes to UX specifically, Enterprise is very different from B2B or B2C or even platform because it stands within this crossroad of everything in the middle. The sole purpose of what you're trying to do is you really try to improve productivity and the satisfaction of the users at scale. And 'at scale' is really important here because for those of you who work on Enterprise Products, you're very familiar with rows and tables that probably would be like 100, 500, or even thousand rows. Then you have to deal with all the complexity of 'How do I search? How do I filter?' Even these simple things like search and filtering becomes super complicated when you're dealing with it at scale.
The second thing is it is a professional environment. For those of you who work on Enterprise, you're probably working on internal tools or tools that are used by experts specifically, and everything you do you're trying to make their work more productive and you're trying to automate a lot of these manual workflows.
Some examples of companies that work in this field: HR Management Systems, any Cloud Solutions, ERPs, CRMs, internal tools. Some of the biggest companies that operate in this field - you've got Oracle, you've got SAP, one of my favorite, and some of the newest kids in town - you have Salesforce and you have Workday.
I feel very privileged coming after Chris on this stage and telling you this is a product somebody built and somebody's using. That's the reality of what we do. This is SAP, this is how they used to build products for their customers. Let's not pick too much on SAP, it's not very cool. Let's go for AWS - this is 2011, that's not very far ago. Like we're not talking about 80s or '90s, and that's what customers used to do. This is how Enterprise products used to be built, why? Because they thought that 'Oh, nobody goes to jail for building a horrible product.'
Let's say things became a little bit different in our field. This is Aana, and I don't know if anybody works in Aana, but I'm a big fan of what they've done with their admin console. Things changed - we no longer accept products that look horrible or look bad. Chris was talking about beauty, and that doesn't only talk about beauty within the B2C world, but there's also beauty in the Enterprise in the B2B world. Yes, our work is mostly forms and mostly tables, but that doesn't mean they cannot be usable.
So we went from CLI to actually building proper products with buttons, and you can see the difference between the first and the last - it's drastic. This is where we came in the last 15 years. So what exactly happened? The internet. Things you, the internet, with everything that came up with it like 'Oh this cool invention!'
What happened is a lot of these products like SAP or if you're working with Oracle, they used to be apps that get installed on a physical machine. Like you buy the license, the app gets installed, some of these machines were not even connected to the internet. So of course you build a product and this product is used by somebody and they cannot get out of it - this was the reality. However, when the internet came, now we have a lot more products and there's a lot more offering. The perception is changed and the expectations from your users also changed.
From a technical perspective, now you don't have to install an app - you could use the app or you could use your software online, which for us meant that we can update software. We could experiment, we could release something and take it back because 'Oh we made a really big mistake.' That would change and that's how things changed the perspective of how do we build software.
That came with a big opportunity for designers. Historically these products were built by engineers and no offense, but they're really good at coding but not exactly good at designing, as we saw before. So that opened a big field for us to go into this design world and get a seat at the table. However, that seat at the table doesn't come without any challenges - it's not free.
To be honest, when I started working in this field, my first reaction to what I was doing - I really felt this is Mission Impossible. I cannot do this, I don't know how to do this. There was nothing that I can go to or a book that I could read and say 'Ah, this is how you design products in the technical world or an Enterprise.' That was not very attainable for us.
Some of the challenges that I'm going to go through are challenges of my own personal experiences and what happened to me during my career. This is your face when you first onboard to a company if you work in Enterprise and you're completely clueless - like literally what am I looking at?
I remember my first job, my first week at Amazon, and I was sitting there in a room and we're discussing a product with a lot of VPs and CTO and a lot of high people, and there's just me - 'Hello, I'm the designer here in the room!' They just got a new designer. I think all of AWS had probably 30 designers, not really a lot of people in the company - 30 designers, right? And I'm one of them and I'm just sitting there in the room and they were throwing all these acronyms above my head and I had no idea.
If you are in this situation, you're sitting there like I was - so scared. I had all my insecurity firing up everywhere and I'm just sitting there hoping to be very invisible and like 'Oh my God, I hope somebody would not ask me a question, please, I'm not even here.' And then my manager looked at me and he said 'Oh Daria, what do you think about the user experience?' And I kid you not, my heart stopped and I thought I'm going to get fired. I don't know what I'm saying, I don't know what I'm doing.
I just composed myself and I thought 'We need to do something about this right now, we need to answer, I know something!' And I just said 'Really good question. Let me ask you another question: Who is the user? Who are we designing for? Can you tell me a little bit more?' And they all froze and they all started giving me different answers and nobody could answer my question. That was the moment that I realized - wait a minute, so wrong! Wait a minute, ignorance is actually a blessing! I really need this - like they don't know what they're doing, they know the technical parts but they have no idea what products they are building. This is a great opportunity.
So I really had to learn at that moment things like this - these are some of the acronyms that I had to learn at that point. For those of you who were in the talk yesterday from Kelly, she was talking about dancing the dance and getting tattoos. Yes, I have tattoos but that was not the point - I really needed to know all of these terms. I needed to understand when they were talking about data residency, cloud computing, authorization, authentication, optimization roles. For me, all of that was like gibberish - I had no idea what they're talking about.
And I realized ignorance is a blessing. If you're working in this field, you really need to be alcoholic - like all these stupid questions where you raise your head: 'I have another stupid question.' Is that exactly a stupid question? It's rhetorical, it's a very valid question and probably nobody can answer that question in the room.
So let's go back - really, who is my user? And working in Enterprise, the user is really complicated. You have two sets of users: You've got the customer, what we call a customer, which is the person who's giving you money, paying your salary. This is the business unit that signs the contract, that makes the purchasing decisions, that makes their decisions based on legal contracts. They make their decisions based on recommendation, pricing - there's a lot of factors.
And then you have the poor user who's actually using the product and hopefully they're not really suffering, but their main job is to get this done. They're busy, they require software that is very efficient, and if you ever have a feedback button in your product, the person who clicks on feedback - that is the user that's giving you the feedback. Most of the feedback that we get from the user category is feedback around UI, feedback around certain functionality improvement. But the feedback that we get from customers is mostly about features - we need this feature, we need additional security, we need additional compliance.
That can make it a little bit complicated because you're working with the engineers, you're working with the PMs, you think the priority is this, your boss, your manager, your business unit is working with the customer and they have a completely different priority. And that makes it difficult to juggle the two priorities.
Add another layer of complexity to this which goes into the company's size, the sector - of course designing for a government is very different than designing for a tech company. It becomes very different. This is an example of a project I worked on that was directly directed towards the DevOps persona. The Dev persona was such a new thing in the field at that time and nobody knew exactly what they were doing.
So we were going back and forth a lot with the management because we couldn't agree on priorities. My managers were saying they don't care about UI, they're only automating, they're only using code, and designers were saying 'Oh no, well the research is very different.' So we realized that when we were doing the research, we were actually bringing people from different backgrounds - we had the customer and the user, we had the technical user and the non-technical user.
So what we did, we realized that we could segment them on two axes - the size of the company (small and large) and how mature they are in the cloud. When we looked at if they are high, they have high maturity, you've got the startups in the world if they are small. If they are large, then you're talking about tech giants which is Airbnbs of the world, and they have a different way of doing things. If you're looking at a large company with low cloud maturity, then you're looking at government, so you design a little bit different to them.
I'm not saying this works for every company or for every project, but for this particular project this segmentation worked. This segmentation saved us a lot of cost in terms of building the right product for the right persona and getting alignment around what needs to be built.
Research - for the researchers in the room, when it comes to Enterprise, that's a completely different story because things that you know like A/B testing, heat maps, even UI metrics, they simply don't work. Why? Because a lot of these customers have bought the license already and the license is installed and the customer sometimes is forcing the user to use a particular product, so it's not exactly their decision to make.
The second reason is these companies print marketing materials or print tutorials for their internal users. So if you're playing around with a UI and changing the UI every other day because you're testing, what they have learned is different from what they have seen. So instead of making them more productive, you're actually shooting yourself in the foot.
Research can be a little bit more tricky. Does that mean it's impossible? No, it's actually more accessible because even though sometimes contacting the customer could feel like another mission impossible situation, but internally you have a lot of tools. So you can rely on the user feedback that comes from a feedback button, or you could rely on your customer supports - these are subject matter experts who are constantly talking to customers. You can talk to account managers who are on the phone daily with your clients and they're asking them questions. You can get a lot from them. Business units and sales - these are amazing because you can listen to their calls and understand what other features the customers are asking for, what do you need to build in order for you to be able to sell or to be able to increase adoption. This will give you a really good grasp on what's happening on both ends - on the user end and the customer end - and how to prioritize and balance these two needs.
Legacy - oh my God, if somebody tells me you have to deal with another legacy or you have to uplift another legacy, probably I will have a heart attack, but this is the reality of what we do. We're constantly building or we're constantly changing a certain interface to another one. Why? Because a lot of these Enterprise customers, they got to where they are at the moment because they bought other companies. There's a lot of acquisitions or they hacked things around and then they kept building on top, on top, on top, on top, and in 50 years you have code that's worse than spaghetti brains at this point.
But that would be probably one of the first things you will deal with, and there's so many different ways of how to deal with legacy and there's many different paths. That's probably like a 2-hour talk by itself, but I want to talk about one that I've worked on, specifically in AWS. So we uplifted the previous horrible screen to one that's a little bit less horrible, but this took 5 years. Imagine bringing 2,000 teams or 2,000 products into one particular design system.
So that was one way of doing it. We're doing the same thing at Miro at the moment. So we're uplifting our admin to something a little bit more usable and a little bit more comprehensible where you have more space where we can handle a lot more information on the UI.
So how do I get here? As a designer personally, you really have to be okay with having not very pretty portfolio - that's the fact. So you just have to bring a different perspective to your portfolio. Probably you're not going to have beautiful screens, most of the time you're dealing with NDA so it's not as easy and it could be a little bit complicated.
What I look for when I'm hiring designers and what I will say if you want to go in this field, what you need to show is I need to see the problem very clearly. I need to see exactly what was before, what was after, what was the workflow that you dealt with and then you automate it. That's really important because that's the core of your job. I'm not expecting to see beautiful UI tables, wizards, platforms, but I want to see how you got there - what kind of work that you've done. A lot of the work that you're doing is mostly like service maps rather than actual UI work. I want to see that, I want to see the flow iterations, and then I want to see the business impact.
And why I say the business impact? Because in this position, definitely planning business impact is very clear. This is a page of my own portfolio - that's how it looks like. Doesn't look really good but trust me, this gets me jobs. And this is a product that we worked on at Amazon and this was one of the most powerful products, and that screen that you see on the right, this was the UI and that UI took two years to make. Why? Because this UI allows you to onboard multiple services or deploy multiple services at the same time and that was very very difficult.
So what we've done, we took all of this manual process and we automated it, and what we show the customer is: 'Dear customer, this is what I'm going to do for you. The only thing you need to give me is a target and what I'm going to do in the background is I'm going to do all these workflows, I'm going to give you best practices and standards, and you will have an environment to deploy within minutes.' This was really successful and that what tells you how you can take a really complicated process and make it very simple.
I believe that the best products that you work on, if you work on Enterprise product specifically, is a product that has one button to it. And if you want to be even more successful, you should not have a UI because if we do our jobs properly, customers don't have to go to a UI and then actually try to maneuver around with the UI - things should just work.
Some of the metrics that we deal with - I realized I have three minutes, speed up - you're dealing a lot with engineering efficiency. So a lot of the work, especially if you're working on legacy, your best metric that will be your voice is reducing engineering time. I found this metric specifically very powerful and it helped me a lot in terms of securing resources for legacy product because, if you want to believe it or not, nobody wants to go on the stage and say 'Well, look at us, we went from really horrible experience to an amazing experience.' This doesn't get you on stage, but this metric was very powerful.
Customer support use cases, the number of support use cases you have reduced because that is time, adoption rate, time saved which is also one of my favorite - I've worked on a product that saved 10 seconds from a salesperson's workflow. And imagine 10 seconds is not a lot of time, right? Imagine that salesperson doing 50 cases a day multiplied by seven, you have 100 customer support - can you imagine how much time and effort you've saved at that point? And of course revenue - a lot of the work that you do has very clear dollar sign to it, and if you can include these in your portfolio because that's what we're looking for, this is what we are actually looking when you're looking at your impact.
Finding designers is very hard. There are jobs, a lot of jobs when it comes to Enterprise, and finding the right designer who is willing to adopt that mental model, who's willing to take the sacrifices with not having a great portfolio is very difficult. And the way I deal with this or the way I try to get a cohesive design team - this is my own way I look at my design. The designer skill matrix is I look at what designers I have and what the skills that I need, just purely soft skills and hard skills - what exactly who do we have on the team, who do we need, and then for every project requirement I look at the design skills that are needed.
Because sometimes you work on projects that would require the complexity of the project is mostly stakeholders complexity - you're dealing like in a legacy product, well you're basically replacing tables from an existing design system, not very hard right? But you're probably dealing with 50-30 more stakeholders. And other projects, if you're doing insights, if you're doing a dashboard, you probably need somebody with very strong design skills. So that's how I kind of try to balance the designers, the skills that I need, and what projects do we have.
So I hope I didn't scare anybody and I hope I see more hands, but Enterprise design is hard, it comes with a lot of challenges. However, it's very rewarding. As I mentioned, I did like a very small quick search last week and I wanted to see and gauge how many job openings are there for Enterprise designers in Europe specifically, and there were a lot. So you probably would not get 100 job opportunities, you probably got to get like 10, but if you build your portfolio properly, you probably got to get 10 interviews so your success rate will be 100%. This is my talk, thank you.
Moderator: Amazing Daria! I'm going to come and stand over here so I can see. This resonated massively with me. I used to work in UX research for software development tooling, and was in an interview at a point where one of my colleagues was trying to take this with a software engineer we were talking to, and they legitimately turned around at the end of a question and went 'I think we need someone more technical in the room' and basically hung up the call. Very challenging space to work in.
Particularly resonates with me when you said you realized you were the design expert in the room and you're in a field that is very technical first, and so you don't feel like an expert in the room but you have something to bring to the table. Talk me a little bit more, before we dive into questions, about how that realization was for you - like how that changed things and how you instill that in new designers coming into the Enterprise space, that they have a skill that is expert but maybe not at the fore?
Daria: For me that was eye opening, like the fact that I thought that I was an expert and then you go into the room and you're like 'Oh I'm so scared,' and then I realized wait a minute, I have another superpower that I could use. So I tried to get my designers to ask more - of course we hire a little bit more technical designers or designers who have the appetite to be technical, but I always push them. We have this mental model in the team: break things, don't ask for permissions - ask for forgiveness, go ahead break things, do things that you're not supposed to and if something doesn't work we're just going to take it back and fix it. It's okay, nothing is not removable, nothing is unfixable.
Q: How do you encourage engineers or end users in these Enterprise spaces to give honest feedback?
Daria: Usually this is how it goes - if they like your product, they're not going to say it. If they hate your product, they're going to give you tons of feedback. So they don't need encouragement to know what is not going well, but what you probably need encouragement in is trying to instill a little bit of confidence in yourself and say it's not that bad. Like when you hear a lot of comments from customers and they say 'Oh this is not working and this is not working' - yes, this needs to be fixed but that doesn't mean everything is not working. And with engineers what I find very helpful is get them to use the product - dog food your engineers and that's when they get this moment like 'Oh my God this is not easy to use.' Like yeah, of course that's what we're trying to fix.
Q: You mentioned a couple of things here - change took several years, one you mentioned five years. How are you keeping your designers motivated when progress is that slow towards making a difference?
Daria: Very very hard, very difficult. I think it's very rewarding - yes, it takes years for something to come out but when it comes out and people are talking about it, this is very very rewarding and it takes a little bit of patience. And I had like my own personal fan moment, if I can say it - I was working for Amazon and we spent 2 years building that screen and I was there in a conference, an AWS conference, and a guy came out to me and he's like 'Oh I love your product.' He didn't know who I am, I just was in the booth, and I was like 'I love your product, this is amazing' and we started talking like 'Where are you from?' and he's like 'I'm from NASA.' I'm like 'Oh my God!' I had this like fan moment like 'Oh my God, you're doing my dream job' and he's telling me 'You're my dream job.' So I think yes, it takes a lot of patience but when you hear these comments of how you actually impact people's life, that's worth it. And yes it takes patience and you need to have a lot of resilience to be able to do this job.
Q: NASA is a fan of yours, that's amazing! You've obviously been in the design space for a while, you've built up through quite complex area of design that is hard to get into I would guess because of the technical aspect. What advice to junior designers?
Daria: A couple of ones actually. What I see a lot with junior designers is with the portfolios - I see a lot of screens which is great, mockups are amazing, prototypes are amazing, but they always lack or they don't put how did they get here. Like my expectation is to actually see a process, like sometimes I want to see the different iterations and that's what I see lacking in a lot of portfolios at the moment. So my advice: put the process. The process is more important than the screens because I can teach somebody how to do good UI or the company has design systems so I don't really have to design tables or fields - they're available for you. I want to see that you're able to take a problem and then take it from a complex to an easy to understand problem. Like I want to see that and that's my advice - put more energy and effort into this."
Q: Skills can be taught, mindset needs to be shown. I love it. You spoke a lot about the pain of legacy code. I've again been in the sort of organization that turns around and goes 'If this breaks, no one for 10 years in the company has known how it works.' How do you recommend managing that kind of legacy code whilst you're also trying to be lean, trying to design well in an MVP fashion?
Daria: There are so many ways that this can be done, there is no one way or one size fits all. I've seen it done in some projects in Amazon where we actually lifted features or lifted a particular product from legacy to new and we always had this feedback button. This feedback button was really important and the go back button was really important, and that was very difficult because the two products will stay there for a certain amount of time. So as a designer you're designing for the old experience and the new experience and that's devastating, but that's really necessary in such technical products because as I mentioned customers have materials and you need to onboard them slowly.
I've seen it in other ways that is done by experiences, so you just have like a journey and then you uplift the journey. In other ways you just want to stop development, clean the code and then build new features. We built, we just removed chunks of legacy and then all the custom components and then we injected new components. It really depends on what you're dealing with and it depends on how fast you want to go in the market, depends on what state you are in the product - can you afford to stop development and not release features? There is a lot of ways and pros and cons for every way and I'm happy to talk more about that from what I've seen works and doesn't work.
Q: I love that. I'm also now convinced you're not a designer, you're a researcher because you used our researcher favorite phrase 'it depends' when answering a question and actually giving an answer.
Daria: Everything depends in this, everything depends, everything is contextual, nothing in our space is simple, there is complexity in everything we do, you have to understand the context.
Q: Prioritization, a big one. How do you manage it? I like this one - there are user needs, there are customer needs, needs that might be different. You have lots of metrics for business impact. How do you pick which one to prioritize?
Daria: So the way we prioritize or the way we should prioritize is based on customer impact. What a lot of times happens is that you kind of start ignoring the user feedback and you say 'Well this is not important, it's okay they're dealing with this' and that's prioritize building features. And other times you flip the coin and say 'Well we need to fix all of this user problems' - like we need to fix filter and search, it's always filter and search are a problem everywhere, always. It's like you need to fix that because people cannot use it - 'No, we need to build features.'
So having one without the other, it doesn't work. The company needs to move so you need to build features in order for you to sell, in order for you to get a salary - that's one. The second thing: you cannot just be quiet on all this customer feedback, like user feedback when they're saying the search and filters doesn't work. So it needs to be like a balance and as a designer this was one of the most difficult parts - like how do you prioritize search and filter?
What I found very well - create a big noise around it. Your management would listen to whales. When I say whales, it's like your biggest customers, right? Like you might have few of them but they're paying a lot of money so their voice is very loud. So what I found very useful in order to get some of these fixes is I found who the big customers are and then I don't say - I go to my management and then I don't say 'I think this is' or 'The user thinks this is' - like no no no, 'NASA wants this fixed. Would you jeopardize the NASA contract for not fixing this? It's up to you, I'm fine with both decisions, but how about Airbnb? Would we not fix it for Airbnb? They're paying millions.'
So I kind of found these arguments work very well in terms of bringing that user voice because a lot of the management or decision makers or the C-Suite, they look at the customer request and they want to get the features out without actually looking back and going to the debt that we've accumulated. So this was my trick - I don't know if there's any more tricks but that's what I've seen work both in startup, mid companies and in corporate.
Moderator: Everyone, Daria. Thank you.