Tag: Vitaly Friedman

This article is a sponsored by Wix

In this episode of the Smashing Podcast, we ask how you can prove the value of a Design System and how you can pitch it effectively to stakeholders. Vitaly talks to Ben Callahan to find out more.

Show Notes

• Ben Callahan on Twitter
• Ben’s website
• Sparkbox

Weekly Update

• Meet Skeleton: Svelte + Tailwind For Reactive UIs written by Chris Simmons
• Everything Developers Must Know About Figma written by Christine Vallaure
• Designing A Better Back Button UX written by Vitaly Friedman
• An Introduction To Context Propagation In JavaScript written by Evyatar Alush
• Implementing A Reset Password Feature With Next.js Dynamic Routes written by Caleb Olojo

Transcript

Vitaly Friedman: He studied computer science and worked as a software engineer, as an audio engineer for independent films, as an animator and of course, as a front-end developer focused on standard-based web development. These days, he’s the design system researcher and consultant working with wonderful people, almost sparkling people at Sparkbox to build a better web. Now, he’s always in learning mode and there is no better way to describe him as an explorer, maybe even Internet Explorer, with a very strong focus on design systems. Now, he lives in Dayton, Ohio, loves cooking, poetry, travel, photography, coffee; that was an important one. And has two, pretty as well kiddos, my threshing friends, please welcome. And I hope I can hear the cheers and applause right here, Ben Callahan. Hello Ben, how are you?

Ben Callahan: Hi, Vitaly. I am smashing.

Vitaly: Well. That is fantastic to hear, while you do look smashing as well. If I may say so, Ben, let’s start right away and dive right in there. How does a person who just happens to be a software engineer turn into a design system researcher? Can you show a bit of your journey to get there? Because I know that you’ve been working on design systems probably before it was even a thing. So I want to hear it all.

Ben: Yeah, absolutely. Thank you for having me, Vitaly. I do appreciate it. I’m super excited because I love design systems. And one of the reasons that I think it’s become an area of focus for us is because I have seen how it has helped organizations create a lot of unity inside their teams, which is something that I’ve always wanted. And so, if you’re asking about my journey, the reason I’m pointed in this direction is because of that. And if I go back, I did study computer science.

Ben: I was frustrated working in the corporate world feeling like I didn’t have a lot of... There wasn’t just a lot... This wasn’t a vision for the things I wanted to work on. And so eventually, I stepped out of that space, took a year to just explore different technologies like animation and audio, and just other things that I was interested in, and ended up starting a business, doing video production and audio engineering.

Ben: And then we did a website for one of our clients. And as soon as the rest of our customers saw that we offered that, it just was the only thing they wanted. This was early days of the web, and so I ended up buying my partner in that business out and transitioning it to a web studio, a very local web studio here in Ohio. And eventually merged that with a few other folks who were doing good creative technical work in town, and the result over a few years of us churning to figure out what we really wanted to do was again a focus on the web.

Ben: And that’s how Sparkbox was born. I’m really fortunate because we’ve grown slowly and steadily over the last 14 years. And that means that as a front-end engineer, as a computer science guy, I’ve transitioned out of writing code every day. And instead, I get to focus on where I want us to be headed. What do I think is important for us to be learning, and how can we best serve our customers? And that’s really how I pretty naturally ended up digging in deeper to design system work. Because I actually do believe that it is a unifying opportunity for a team, so that’s how I landed here.

Vitaly: Oh, that sounds very exciting, indeed. And I think in many ways, we are everybody who is listening to the show now as well; I think we all have been in one place, and then we moved to a slightly different one just steadily and slowly. And I know a couple of people who used to, I don’t know, sell glasses before the internet was a thing. And then off you go becoming a designer, developer, manager into design systems and all things like that, so that’s really exciting to see that.

Vitaly: Interestingly, talking about design systems, I think we are in a very interesting position right now because it feels like we have been playing, and doing, and experimenting, and working around design systems for many, many, many, many, many, many years now. And I don’t know about you and probably have, of course, way more experience than that. Many teams already have one, right? Or they’re trying to get one, and it might be up-to-date, maybe not, but they’re definitely not something new and shiny around the block that we just need to try out.

Vitaly: Many people have tried to do that, you did spend a bit of time trying to understand what makes a design system mature. So maybe you could actually dive a little bit more into this and explain, based on your experiences, of course, the Sparkbox as well. What is the maturity model for a design system? So what does it entail?

Ben: Yeah, you’re right, Vitaly, that we have been as an industry working very systematically for a long time, years before we started to use the word design system. And Sparkbox, like many other studios or consultants, had been working in that way for a long time. I think when you put a name on a thing like design systems when you give it a name, it takes on a life of its own.

Ben: And so definitely, there was a point probably six years ago when our clients just started asking us for that, six or seven years ago. And so I think when that starts to happen, as an organization, as a leader in an organization, I feel like it’s my job to better understand that. And for us, what that has meant is for the last five years, we’ve done what we call the design system survey.

Ben: And that’s just to open to the industry. And as part of that process, I get to ask; I get to do lots of interviews with folks who I just find online, who are doing this work in an interesting way. And I just ask if I can have half an hour or an hour of their time, and I just ask them a ton of questions.

Ben: And so that has given me a lot of exposure to very broad perspectives on what’s happening in the space. And so with all of that, as part of an input for me, what I have done over the last four or five years is each year talk to lots of folks and then sit down and try to find some cohesion in all the different stories that I’m hearing.

Ben: So, a couple of years ago, leading up to the release of our survey for 2021, I had done that series of interviews. And I realized that there were some patterns that I was seeing emerging in terms of how systems were moving and maturing. And that’s where we landed on these four stages that we think most design system programs move through. And that we tried to keep these quite simple because I don’t want this to be something that’s super theoretical.

Ben: I want it to be practical and useful, but at a high level. The model is there are these four stages; the first is just building version one, so that’s literally everything you do up until you release something for subscribers inside your organization to start using. And then pretty much every team that I’ve spoken with who has gone through that and actually got something out the door, their next big focus is almost always on adoption.

Ben: And that makes a lot of sense, right? You spend a bunch of time building a thing. Of course, you want to see if other folks are interested in using it. And so that second stage is driving adoption. And then, if you’re able to make it easy to become a subscriber, and if you do a really good job supporting folks who are using your system. And if you continue to evolve the system in a way that it shows value to lots and lots of different types of subscribers inside your organization, then you can reach this third stage, which we just call surviving the teenage years.

Ben: And it’s a tricky season, because there’s lots happening, right? You’re having a lot more people use the system. I can guarantee you that they’re probably going to try to do things with it. You never imagined they would. This is where you heard of having to make a decision. Are we actually going to treat this like a product? Are we going to offer support in a really healthy way? Are we going to come alongside the subscribers and engage with them been good ways?

Ben: And if you can continue to survive that stage, you reach what we call stage four, which is just evolving a healthy product. And this is really where the design system team actually takes a role in terms of leadership inside the design organization itself. And these teams that are stage four are doing incredible things. When I talk to people inside these organizations, they talk about the design system team as the place where the most skilled workers in their organization operate.

Ben: They say things our design system team was ready for us. When my product team came and said, “Hey, we want to try view.” That they had already done a spike on the design system team to show they could support that. They’re very proactive. They’re not reactive. And that’s, I think, a really healthy place to be at the table for big conversations, to be driving decisions inside the org. That’s what I think is possible if you mature in that way.

Vitaly: Well, that sounds very exciting. But then in your experience, looking again at the work that your clients are doing, where would you see most companies are at this point? How many actually reach level four, and where do most companies struggle?

Ben: Yeah, that’s great. I’m glad you’re asking that because I think doing that work, one of the outputs I was hoping for is to make it clear how to move through these stages in a healthy way. I think you said something earlier that I’ll just harken back to you which was... You said most folks have a system already. What I’m seeing is that many organizations are on their second, third, fourth, or fifth attempt at doing this work.

Ben: So it’s not just that they have a system; it is that they have been struggling to build a successful system for years in some cases. Most of the time, I would say most organizations that I get a chance to interact with are stuck somewhere between two and three. And it’s actually really common to get stuck there because this is where everything before stage three is about building something people will value and use.

Ben: And in order to transition into three, you have to... What it seems like right now is that you need to increase the size of your design system team. And the skill sets that are needed are a little bit different. This is where you have to actually add in a product support team, like customer service for your subscribers, right? And it’s because the system is if it’s going to take root, it’s going to be a really fundamental piece of any interface work that your organization does. And for that to be the case, you have to really actually support those folks in a really healthy way. If they don’t feel like you’re there for them, if they’re going to use your product, you have to show them that you’re trustworthy, and so-

Vitaly: That’s right.

Ben: ... that requires more people, there’s just more to do. And so that’s a tough spot. I see folks oftentimes moving between two and three quite a bit. I haven’t spoken with a ton of folks who have reached that stage for more mature, really driving more proactive decisions inside the org yet, but they’re out there.

Vitaly: Yeah. One interesting thing for me was when I encountered working with one of the bigger companies from Romania, actually, and they’ve been working on a design system for six to seven years, pretty much aligned to what you were saying as well, where everybody was on the gold-rush design systems, gold-rush in a way. And I was extremely impressed with just how concise, how well established, how reliable, and how sophisticated the design system was.

Vitaly: And so that took a lot of iteration, of course, as well, but it also takes a big commitment from the top. And I know that you also have been speaking for a while now about how to sell design systems because very often it is expensive. And very often, you still need to convince the right people that this is the right amount of effort and that the return on investment will be worth it. Would you say that at this point, it’s something that’s already considered to be true most of the time? Or is it something that you actively have to prove every single time with some metrics or KPIs? How does this work for you?

Ben: Yeah. It’s not proven. I think, I mean there are organizations who have done that work for their use case and I think that’s great. This is a tough area, and I don’t have a single answer. I have more of an approach. I think that has helped us. So I have had the opportunity to speak with a lot of leadership inside organizations where they’re trying to make a decision if they should be investing heavily in a system.

Ben: And I think that’s actually probably the right first step. I’m not somebody who is absolute in this. I think there are situations where a design system is really helpful, really beneficial. There are situations where I probably wouldn’t recommend it. That doesn’t mean some variation of patterns and components and things isn’t needed in most cases.

Ben: But if you have a single product and a small team and you’re in startup mode, it’s probably not worth investing all this time and money to build a design system to support a single product. It's just the bang is not there for your bucks. So there are definitely use cases. That’s one of many where I probably wouldn’t recommend it.

Ben: In terms of once you’ve made that decision to pursue it, then it is about making sure leadership is on board at some stage in there, you have to make that transition to getting leadership really bought in. Not every system starts that way. We talk about in the maturity model, there’s a concept called origin stories, which is just really how involved and aware and supportive your leadership is in those early stages.

Ben: And there are many systems that are very successful now that started without any... No leadership involvement at all. It’s a transition; it’s maturity that has to happen. And as part of a successful system, you do need that long-term, but the way we help our clients figure out how to get support from leadership is that we do what you would do with any other product as we go. And we talk to those folks, and we try to understand what their needs are and what their goals are.

Ben: And how can a design system be shaped to serve those things that are important to them? And if you can reposition, the effort in a way that it solves problems for folks, they’re going to be willing to support it. The other big thing to talk about in those early days when you’re selling the systems especially is that you... A design system is only going to show its value over a very long period of time.

Ben: So this is truly an investment, right? It’s the kind of thing you put time and money into, and you have to trust that over the years, you’ll start to see a return on that, but it’s not a quick thing. So being clear about that upfront is actually really helpful in the work. And your last question was about, is it something you just sell once? And then you’re done.

Ben: I’ve never seen that really work. It’s a constant. That actually is part of the maturity model. We talk about three things, education, which is convincing folks, talking to folks, casting the vision, explaining why, what, how, and all those things. Engagement, which is getting folks involved in the work with you. It’s not a one-way thing.

Ben: It’s definitely very... There’s a lot of work required from all the different groups involved and then evolution, which is just simply making the system better over time. So if you’re not doing all three of those things all the time, you get stuck in that, in those steps to mature, so that’s what we’ve learned.

Vitaly: Right. Well, that’s very exciting. I’m wondering, and I really want to know more about what you have learned because you did mention that you and the wonderful team at Sparkbox have released the design systems survey 2022. And I’m really curious about some of the new things that you maybe haven’t uncovered there. What were some of the most surprising findings that you discovered there during that research?

Ben: Yeah. I mean, each year, we do that. This is our fifth year releasing that; each year, we come away with some really interesting insights, and this year’s no different. One of the things that really stood out to me I remember when we were working on what questions we would ask this year. And there was a series of questions in the survey this year about your top challenges. And we give folks a list of options to choose from, and then what are your top priorities? And we give them the same list.

Ben: And I remember reading that question and saying to my team, aren’t people just going to pick the same things here, right? If these are my challenges, then why wouldn’t those be the things I’m prioritizing? But they convinced me to leave it in, and they thought we would find something insightful there. And, of course, they were right. One of the things that are really interesting to me is in that survey; there are a handful of areas where you can see a difference in what is important to people in terms of what is a challenge and what they’re actually able to prioritize and work on?

Ben: The one that stands out the most is staffing. And this ties in actually with what we were just speaking about, Vitaly, around that stage two to stage three transition where you need to grow the team, the number of folks working on this, like the volume of work gets much larger as you move from stage two to three. And if you don’t have the support from leadership to increase staff, which is what that is hinting at, you can’t really do that well. You can’t make that transition well, and to me, the way I’ve interpreted this is that a lot of folks in the survey data say staffing is a big challenge, but it’s not; it can’t be a priority for them.

Ben: And it’s interesting because I think what that means is there’s a separation in the things that the design system team has the authority to prioritize, right? So they may be able to say, “Here are the things objectively that we have as challenges,” but maybe they don’t have the authority to choose how to spend the money or how to prioritize things, which I feel is a disconnect. If we’re going to trust these folks to run this design system program, we have to trust them to set their own priorities. So that’s one that stood out to me for sure.

Vitaly: Right. Right. It’s always kind of a story because I think in many ways when I deal with companies that choose to go ahead and give the green light to the team for design system, there is still always a little bit of trust that this is a simple, relatively simple site project, which is not going to drive us away from the main core product that we’re working on. So if designers, in this case, believe that this is the right thing, surely this cannot be the priority. And so surely there will be no extra stuff involved in making this happen.

Vitaly: And so that’s pretty much, I guess, aligned with what you are saying here as well. And obviously, people are important. So I’m wondering, though, in your experience, maybe that would be interesting to explore. What would you say are some of the important ingredients of a successful design system? When do you know that you are on the right track? Or how do you know, do you ever know, Ben? Do you ever know?

Ben: Yeah, it’s hard, man. It’s hard because it gets into the promises you make early on, which are the things that people are going to expect you to prove later. So I think successful systems can look very different inside different organizations, and it’s really. I wish there were a simple answer. I think there are some common things; we talk about a lot of those things in our survey we ask each year, do you feel your system is successful?

Ben: And then we can take that information and look at the other characteristics of design system programs that where they feel they are successful? And then we can make some interesting observations. One of the things that we always see is that having better engagement almost always means that individuals feel that the system is more successful. So, in other words, you can’t operate on this. You can’t build and offer a system unless you’re actually working alongside the people who need it.

Ben: It’s like any other product, you have to understand their needs, and you have to get down into the work with them. And so that’s what we encourage and help our clients set up as those engaging practices. I think the educational side of it is always key too. And this is where, in fact, this year, one of the things I’ve been focused on is just going back to what a design system is.

Ben: And this sprung out of a couple of consulting engagements last year, where big companies that have had systems for years, and we get in there and ask a ton of questions. And what we understand very quickly is all the people here have very different ideas about what a system is. Why it’s important? How should it be done? And this is seven, eight years into folks working on this stuff. And people still don’t actually understand what a design system is? And so that’s a problem, right? And-

Vitaly: Right, right.

Ben: ... I’m not saying that you have to have the same exact definition that I do, but if you internal to your organization, don’t have that defined, that’s where the real problem is. So we did a bunch of work this year to lay out what we just call the anatomy of a design system, which is a very simple breakdown of what a system is. It gives us some common language to use, and that’s been really helpful for our clients and for us as we work alongside them. So I think going through that exercise with your own internal team is one way to make sure that you’re going to be setting yourself up for success. There are probably many more.

Vitaly: Right. But then, Ben, can you maybe shed a bit more light on things like, “Hmm, how would I put it best?” So if I’m working with semi design system in the company, and I’m pretty confident that things are going in the right direction, and it seems like everything is reasonably well structured within the organization, there are people who are working on it. It goes as it’s supposed to be. What would you say as some of those red flags that one usually should be aware of? Just avoid... I don’t know, deterioration, I guess, of a design system in the company.

Ben: Yeah. There are definitely seasons. I think folks go through where they feel like, “Hey, we’ve got things figured out. We have a good groove. We’re following our processes. Everything’s good.” I think one of the things that we’ve seen is that, like any other product, there is a level of stability you have to aspire to as well. And the same challenges that we’re used to solving for our externally facing products are also going to be the reality for us with an internal product, like a design system.

Ben: And that’s when things change around. And so many times we’ve come into work with an organization where they felt they had a great program running and leadership changed, like a new director comes in, or a new VP comes in. And they have a very different perspectives on how to approach the work. And they haven’t been there for the journey that you have been on. And so, all of a sudden, you’re thrust into this instability where you have to, again, prove that you’re a valuable part of the organization and the process you have to show.

Ben: Sometimes, this is where the metrics come in, where you have to not just tell them which you have to actually show them. And so that’s one tiny example, but shifts in the market, right? Pivoting a product like a rebrand, all of these kinds of things can impact that. What feels like that stability? And so we try to think about... We’ve done a bunch of work to try to figure out what are the things that we can have in place in the seasons where things are feeling good. How do we make sure we’re creating more stability that will actually help our system last through those kinds of changes?

Ben: And there’s three big things we’ve identified. The first is authority, which is that real visible support from leadership. The second is value, which is that you’re continuously monitoring the product you’re offering. The design system itself is actually valuable to the folks you’re asking to use it; that’s engagement, right? You have to be making sure that it’s doing something helpful for you... It has to be the easiest way to work, and then tradition is the third.

Ben: And that’s a little bit different in that you earn that over time, right? Having authority and being valuable over time, you become the way an organization builds interfaces. And that tradition of this is how we work. Actually is quite a stabilizing force in the context of a lot of change. So those are the three things we help our customers put in place in order to create systems that last beyond just those seasons of feeling like we’ve got it figured out.

Vitaly: Right. But I also think the underlying asset behind all of that is something that we spoke about in Berlin when you were here. I remember that cup of coffee. That was a very nice cup of coffee.

Ben: Yeah. That was good.

Vitaly: And also very nice conversation that we had back then. And we were talking about culture.

Ben: Yeah.

Vitaly: We’re talking specifically about... For all of this to succeed, we need to have proper culture and companies and organizations that not only support and enable a design system but also have a little bit of a design system sprinkled pretty much everywhere in the organization. So maybe you could share a bit more on that because I know that you spent quite a bit of time working around design systems and culture.

Ben: Yeah. Yeah. This is what I’ve been working on most recently. And I’m so excited about it. I think I have learned a bit from a couple of our engagements with clients where... Any place where people are getting together consistently, a culture is formed. So that means if you work at a big company, there’s an organizational culture that is created from all of these folks coming together to work on a thing. But also, each day, you’re probably not interacting with every employee.

Ben: And so, your small team that you interact with on a daily basis will form a subculture that exists inside of that larger organization’s culture. And there are probably hundreds or thousands of subcultures inside big organizations, right? The group of folks who get together on Zoom and knit over lunch, there’s going to be a subculture formed there, right? The book club where they’re reading about whatever science fiction book just came out.

Vitaly: Well, I love a Good Book Club.

Ben: Yeah. See, there’s a subculture being formed there, right? I have been doing a bunch of research by just reading papers from the last few decades of other folks much smarter than I who have been researching organizational culture. And I’ve been looking at that because I feel like there’s a missing piece in what we’re talking about with design systems. And that’s an observation that I’ve made just in our work.

Ben: And one of the things that I think is helping us to frame that challenge up a little better is understanding the different types of cultures that can exist. And there’s lots of material on this. There’s a model that I love. That’s, I think, from the late or early ’90s, which is called the competing values framework. And I’ll send you a link that at least you can share in the show notes, but—

Vitaly: Absolutely.

Ben: ... it’s really nice. And it just takes two ideas on a spectrum X and Y. And it gives you four high-level general types of cultures that can exist in an organization. And one of the things that I’ve learned is in my interviews, almost every single one of our design system teams that I’ve talked to is on the left side of this diagram, which means they’re internally oriented. So they’re either collaborative or they’re controlling. Those are the two culture types that are the most common for a design system team.

Ben: And that makes sense, right? A collaborative approach is when you’re saying, “Hey, everybody come help me do this.” And together we’ll build something that we can all use. That’s very common. And then controlling is a little different. And that’s we’re saying, “Hey, this design system is in place to ensure that the output is consistent.” And so you cannot veer from this. It’s more like us being restrictive.

Vitaly: Like a strict guideline that we need to stick to, right? Mm-hmm.

Ben: That’s right. So those are the two... This is very general, but those are the two general ideas of cultures that exist really in design system teams, but there are two others, and those are more externally oriented. And one of those is competitive, which is about being driven by the market, and the other is more entrepreneurial and it’s creative, it’s called. And these are folks who are just trying to disrupt stuff. And so, with these four ideas, what I’ve learned is some of these cultures work well together, and some of them don’t.

Ben: And as a design system team, you don’t get to choose the culture of your organization, right? You are going to be a subculture. And so what we’re learning now is there’s a lot of nuance in being smart about how to structure the culture, how to curate the culture of your design system team in a way that it can operate successfully inside the larger organization’s culture.

Ben: And that’s a lot of the work that I’ve been doing. And I’m real. I just feel like there’s so much to this. I have a lot more research to do, but it’s already starting to show a lot of value in our consulting work, so-

Vitaly: Yeah. Yeah. That makes sense. Because once you have an organization that already has a culture in place, you probably can’t change that, but you might change the way how your design system would operate in that environment to make the best out of that.

Ben: That’s right.

Vitaly: Well, I hope that at some point you will be, I don’t know, writing articles, maybe even books about this.

Ben: Yes.

Vitaly: Either hear something, a rumor about an upcoming book on just that eventually.

Ben: That’s the plan. Yeah. Trying to put something together that has these three big concepts, the anatomy of a system. So actually getting some nuts and bolts about being very clear and articulate about what a system is? Understanding how systems mature, as we’ve already spoken about, and then recognizing the impact of an organization’s culture on the design system team and how we can structure that in a way that it’s successful? So those kinds of the big—

Vitaly: Any deadlines that you’ve put yourself in your calendar?

Ben: I’m hoping to have my draft done this year. And then from there, that the whole process of editing and all of it, so-

Vitaly: Yeah. I even know a publisher who might be interested in publishing at some point-

Ben: Oh, yeah.

Vitaly: ... who knows you.

Ben: Yeah. Give me their name.

Vitaly: Yeah, I will, I will maybe let’s just spend a bit more time thinking more hands-on about what are some of the things that designers developers working in organizations, working in companies on a design system? What can they do to make things a bit better for the process, for collaboration, for the workflow, for everything?

Vitaly: Let’s start maybe just by you briefly maybe highlighting, how do you start the kickoff projects when it comes to design systems with your clients? What do you usually start with? Obviously, there is going to be some research involved and all, but what would be the initial steps to get to a solid foundation early on?

Ben: Yeah, you’re right. It is research. We call this phase onboarding at Sparkbox and what we try to recognize is that those early days of an engagement like that, or the days when you know the least, right? And so we try to embrace the idea that we’re going to know a little bit more tomorrow than we did today. And we try to be very iterative. I think those early days for us are oftentimes about building relationships with the folks inside the organization.

Ben: And we do often ask to be introduced to lots and lots of people, even if we’re not going to work with them daily in the design system work. We still need to know what they’re dealing with? What they’re going through? How are they accomplishing their tasks each day? What are their goals? And what we’re trying to do is I think, model for our clients that you cannot do design system work effectively unless you really truly understand the needs of your users, your subscribers.

Ben: And so that is where we start. And so it’s about... We do that in a lot of different ways. So we may run a small internal survey and send that to lots and lots of people. We may schedule three to five interviews with each discipline. And one of the things that’s a little bit of a pet peeve of mine is that we talk so much about how a design system can benefit a designer or a developer, but we ignore a lot of other disciplines.

Ben: And so one of the things that we’re intentional about is making sure we’re not only speaking to the designers and the developers but also let’s talk to some folks in QA, let’s talk to the product owners. So let’s talk to UX research folks. I think the system should be broad in its goal of serving lots of different disciplines. And so the only way that we can do that is if we understand the needs of all of those folks so that’s how we get rolling.

Vitaly: Right. And then, as time progresses in terms of collaboration, let’s say between designers and developers, right? It’s still always a topic handoff or no handoff. Den Mole and Brett Frost are speaking about the hot potato model as we throw.

Ben: Yeah.

Vitaly: The stuff from designer to developer, from developer to designer, it’s all alternative. And there is no notion of a handoff because it’s just happening all the time in small bits and pieces. What do you see working? Or do you see it working best or maybe not working well at all?

Ben: Yeah, it’s funny there. This is a spectrum; there are so many organizations that are more iterative in that way. There are a lot of organizations out there that are still very linear, and I definitely fall more in the camp of iteration where we believe, but I talk with our team a lot about this idea of empathy. And I’m not talking about empathy for our end users. I’m talking about empathy for the other disciplines that we have to work alongside.

Ben: And I think that is key to doing this work well, is understanding that every decision you make, say you’re a developer, every line of code that you write to build an interface has an impact on the visual side of the things, right? So, and the experience for the end customer. So recognizing that all of our decisions are interplaying with each other, I think, is necessary. And that’s where building relationships with those people is the way that you can do better work.

Ben: So we encourage that. And that’s why I love design systems because it forces all of us onto the same team instead of us thinking about, “Oh, I’m on this products team.” No, we’re actually all trying to build stuff that better serves our end customers, right? And the one way we can do that is with a system.

Vitaly: Right. And when it comes to... Let’s say those little fine little details; for example, many teams will be working with storybook on the coding side of things and then Figma on the design side of things. How do we then, the ultimate, the billion dollar question from me to you? Ben, of course, how do you breach that gap? Will tools save us? Will processes save us workflows, Slack channels? I don’t know. You give me an answer, Ben. I don’t know.

Ben: Yeah. I definitely don’t think tools are going to save us. I get asked a lot about tools because right now, especially with design system stuff, there are so many tools coming on the market, and every tool that’s out there is investing heavily in offering better and better services. And that’s great. We need that innovation happening in the space for sure. And I’m not saying you shouldn’t use tools, of course, but I don’t think tools will save us.

Ben: I think it’s... So in our anatomy of a design system model, we talk about every layer of the system consisting of three different parts. And those are, of course, the assets, which are the things everybody thinks about, the files, the components and react, the Figma designs, all of it. But those are important, right? But also, we talk about documentation, which is like a major piece, which is offering a really actual, insightful explanation of what a component is or what a token is. Or whatever the thing you’re documenting.

Ben: Of also, why is it important? Why is it that way? And, and then we also talk about the process as a key part of that, of this for each layer. And this is, I think I had to say what will save us; I think being intentional and thinking through the actual process that you’re going to follow and being clear about what it is and how to follow it is the way that we’re able to set these different disciplines up for success. In the example you said, designer developer, like one of the common things that one of the biggest challenges we see is that folks don’t trust the design system because the version of it that a designer used is no longer in sync with the version of it that a developer is going to use.

Ben: And that’s a problem, right? Because now, all of a sudden, I’m going to... The next time when I come around, I go through the process thinking that it’s in sync, and at the end, I realize, “Oh my gosh, I used the design system as a developer. And now, the output is different than what my designer designed. That’s a problem. I’m not going to want to use the system anymore because that issue means I have to go redo stuff, right? So that actually has taken away any efficiencies that we might have gained by having a design system because I’ve just created a bunch of rework for myself.

Ben: So the solution to that, there’s two big things, right? One is defining a process to keep these things in sync and just being clear about what that is. And the other is transparency about the current state of each piece of a system. So now, I can choose as a developer to use the system. I know if there’s transparency, and I know that it’s not quite in sync with what the designer used. That just means, oh, I might have a little bit of iteration to do on it, but I haven’t gone through expecting it to be perfect at the end so that transparency creates trust.

Ben: And the process is the way that you can say, “Hey, we know things will, at some point, become synchronized, you can choose to wait until that’s done, or you can go now and maybe help us create the synchronization.” So I think those are the two things that’s just one example, but it’s a balance, right? Of the way that we work with each other and the tools offering some of that automatically. And then when they don’t putting the process in place to do it manually, so-

Vitaly: Right, absolutely. Well, that sounds very exciting. Well, I do have to ask one more thing, Ben; as we’re wrapping up slowly, I know that you’ve been working on so many different projects with so many different companies, so many different brands, and so many different designs systems across. I don’t know how many companies and brands, at this point, do you still have a dream project that you would love to be working on one day? I don’t know, maybe it could be a design system for a big brand, or maybe it could be anything else.

Vitaly: I know that you know, you are a big audio guy, right? So you have been spending quite a bit of time with audio and as not your engineer as well, and you have so many other things that are really interesting to you, and during the conversation that we had back in Berlin, I just realized just how broad your interests really are. So if you could do anything, any big project that you would like to take on, what would it be?

Ben: Oh my goodness. Yeah. I think it’s not, for me, it’s not about the size of a company or the brand awareness, that kind of thing. I mean, we have worked with some big organizations, and that’s always fun to... When you’re talking with your family later to be like, “Oh, you went to that website; we helped build that.” That’s always a fun moment, but I think for me, it’s always been about impact.

Ben: So if there was a way to help organizations actually create that unity on their teams, that’s the thing that really is driving me at the moment. So, the idea of a book, I think, is a way to put that together and actually see folks grow from it and make better decisions within their daily work.

Ben: That’s pretty exciting to me. The other one, I think, is just that I really enjoy teaching and working with folks. And so, I think at some point in my future, I probably will find a way to give back in that way. And that’s pretty exciting for me to think about. So there’s a couple.

Vitaly: That sounds great. That’s great. So dear friends, we’ve been learning quite a bit about design systems this episode, but I’m still wondering, what have you been learning about lately, Ben, that might not be related to design systems or might be related to design systems? What keeps you busy these days? What keeps on a toast?

Ben: Yeah, that’s fun. My son is at a camp this week, and he is studying VR gaming. He’s learning how to make VR games. And so, he and I have a lot of fun. He’s learning to program as well. And so my computer science background gets me back into some code, goofing around with him. So there’s some stuff I’m learning there. I’m always learning about coffee. You can probably see some of my coffee equipment here. So I have a couple of new toys that I’m playing with within the coffee world too always, so-

Vitaly: That sounds great. So do you think we should be expecting you to become a VR developer or VR engineer or barista anytime soon?

Ben: Yes. That’s definitely. I’ll be a barista probably in the near future if nothing else works out.

Vitaly: Right. Well, that sounds about right. If you, dear listener, would like to hear more from Ben, you can find him on Twitter, where he’s @bencallahan, and will obviously post the link to it in the episode notes and also on his website @bencallahan.com. That’s not very surprising, or I would say, but you also can find him @sparkbox.com, where the wonderful sparkling Sparkboxers. Is that the right way of saying that?

Ben: That’s what we say. Sparkboxers. Yeah.

Vitaly: Spark boxers are doing all the incredible job on design systems and beyond. So thank you so much for joining us, Ben. It was a pleasure and fun as always.

Ben: Yeah.

Vitaly: Any parting words of wisdom streaming to the internet out there as an Internet Explorer?

Ben: Oh my gosh. Internet Explorer. No. Well, go check out the second draft of the tokens spec that’s coming out. There’s a lot of feedback needed there if you’re into that space, so that would be a thing. I would encourage folks to go read.

This article is a sponsored by Storyblok

In this episode, we ask how you can affect change to UX design in large organizations stuck in their ways. Vitaly talks to Marko Dugonjić to find out.

Show Notes

• Marko on Twitter
• TypeTester

Weekly Update

• Article vs. Section : How To Choose The Right One written by Olushuyi Olutimilehin
• Testable Frontend: The Good, The Bad And The Flaky written by Noam Rosenthal
• Fluid Sizing Instead Of Multiple Media Queries? written by Ruslan Yevych
• Migration From jQuery to Next.js: A Guide written by Sam Robbins
• Rethinking Authentication UX written by Vitaly Friedman

Transcript

Vitaly Friedman: For him, everything started with a passionate love for CSS and typography in early 2000s. He used to be a front-end developer and UX designer, then moved to the role of user experience director. Working with plenty of clients, such as Deutsche Telekom, SGS, Hrvatski Telekom, Font Bureau, L, National Geographics, and so many others. He also built a tool called Typetester, which has gained quite a momentum in the 2000s and even beyond that, allowing designers and developers to test their topography in the browser.

Vitaly: Now, five years ago, he moved from Zagreb, Croatia, where he's originally from, to Sacramento, California, where he now is working as a Director of User Experience at SymSoft Solutions. So we know he's an expert in UX, but did you know that he has been an avid fan of Acapulco Beaver's Handball team from Zagreb since the age of seven and remains one up until today? My Smashing friends, please welcome Marko Dugonjic. Hello, Marko. How are you doing today?

Marko: Great... I mean smashing, I guess.

Vitaly: Excellent. That's wonderful to hear. It's interesting because we have these conversations every now and again, talking about the meaning of life and so many other things. But one thing that really excites me, and I think it deserves a bit of attention, I have this incredible story of how you actually just fell in love with the web many, many years ago, where you used to do something very, very different. And look at you now, work on enterprise applications for a pretty fancy company. Can you tell us a bit of that backstory?

Marko: Sure. It's a weird story in a way, but maybe it'll give someone an idea about how to start with completely different expectations about your career in life and end up in, as you said, in California. And so my story really began when I tried to build a website for, believe it or not, my dogs, my kennel because I used to breed dogs. And at that time, my full-time job was as a fitness trainer.

Marko: So as I was working with people who would have rehabilitation needs or any type of permanent or temporary disability, I also learned about how people who don't have the visual ability to use the web by listening to the web pages. And so one thing led to another, and I was thinking about, "I have this website for my dogs. Is this even accessible?"

Marko: And so what do you do in early 2000s? You find a web forum where real web professionals reside, and you start asking questions about how to improve the accessibility of your website. And it was really just my hobby website, and it's almost something that I've built out of my front-end or front page software, Microsoft FrontPage. I don't know if you remember that one.

Vitaly: Who doesn't, Marko? Who doesn't?

Marko: And I don't know how, but I never used tables for layout, but I did. And this is probably the first time after almost 20 years that I'm saying it, "I didn't use tables, but I did use a bunch of frames." It was a frameset that pretty much I used to create the header and the sidebar, and the footer. So I had four frames on that page.

Marko: And of course, it didn't validate and everything was really horrible from [inaudible 00:03:45] perspective. But I was hoping that the web design community would help me. And I started researching and learned about CSS positioning, and that was the first thing that I fixed. And then, I learned about Internet Explorer because at the time, I was using Mozilla. I don't know what was even before Firefox. Maybe Phoenix or something like that.

Vitaly: There was Netscape Navigator, of course.

Marko: Netscape Navigator, yeah. I knew about it, but I think I onboarded with the Mozilla type of browser. But what happened is that at some point, the web forums really weren't enough for, I guess, my obsession with making things perfect. So I started reading web standards from the W3C website, and I read the specs because I thought, "This is probably what every web professional does." And so this is how I learned about accessibility and web standards and all the stuff.

Marko: So that was 2002, 2003. And then one thing led to another, again. I was participating in these web communities, and eventually, people from what today is called Human Design Agency from Zagreb, had a call just like this one. And they said, "Hey, would you like to be paid for what you know?" And I was like, "What are you talking about? I'm a fitness trainer."

Marko: But they did convince me, and then I joined that incredible team. We just had so much fun back in the day. And stayed with them for a couple of years, then moved on to an in-house position, and everything else is pretty much standard. But I think that moment when I realized, "I know something that somebody's willing to pay for," was incredible for me. Again, at that time, it was still almost like a hobby to me. But soon enough, it became a profession.

Vitaly: Right. And then, of course, you also ended up having your own studio, which then eventually, after a couple of years, moved you to this decision of maybe it's a time to move to or try to move to the US. How did that happen?

Marko: Well, I think what has always been following me is that I didn't really have any general plan. I knew what I wanted to do day-to-day. I knew what I felt about projects and work and skills and all that stuff, but I didn't really have a general plan of moving from this company to another company and then to that company. It was really about maybe selecting good projects, and good people to work with.

Marko: And so when I had my studio, we became pretty international. And you know that we also collaborated on a couple of projects in Europe. And for me, it was really for the past couple of years in Croatia; it was really just 100% international. And so one of our clients, and through a good friend, Christina Portner, who also participated in some of the Smashing activities, I think she gave a talk and had a couple of articles for you guys.

Vitaly: That's right.

Marko: She introduced me to Savita Faruki, who owns SymSoft Solutions with her husband. And it's a nice, small, family-run business. And looking at the projects that they had and still have, it just made sense for me to move over here, and so I accepted the offer that they extended to me after that visit. Where I really didn't plan to get employed, but we were just discussing some of the collaboration and maybe working on some projects together, but it ended up being me becoming a director of the user experience here at SymSoft.

Vitaly: Right. That's an interesting story, and also chose a journey that one can take from one place to a very different place. Now you've been all around UX for now 15 or 20 years now. I don't even know. Who counts at this point anymore at this point? And of course, you've seen quite a lot of stuff happening in terms of just UX, I would say.

Vitaly: We've been fighting, as you could probably find thousands of articles stating that we need to have a seat at the table. And it seems like now, at this point in 2022, we have a pretty solid seat at a table. Do you think that we are in a place where we wanted to be 15 years ago? Is there still something missing? Where do you see us as a community and just as an industry, I guess, in terms of the state of UX today?

Marko: So I think the there's a couple of things right in there. It's an interesting and also complex topic. So I think we do have a seat at a table; however, the horizon is now different. Because as you travel, you just discover other things are behind the horizon. And so once you climb that first peak, then you reveal more peaks to climb. So I think this is where we are right now.

Marko: And a huge thing that nobody really talks about is that even IT or digital as a whole has had that problem in the past, of the seat at the table. And so we just now joined the crowd of people who might have better access to decision-making, but it's still not at the level where we can really immediately influence any decision, especially in big companies and enterprises.

Marko: Obviously, this is where I work at. Startups and younger companies are slightly different there. But enterprises or anything massive, like big insurance companies or big telecoms or financial institutions, or the government, 90% of my clients are now the government... these organizations have been around for years and hundreds of years, even.

Marko: So old ways and things that led to the success that they have right now are not necessarily something that you have to change, but very often, you can also change them by applying correct organizational change management principles. So I would say the challenge that we have nowadays is just general organizational change management. That's a hot topic.

Marko: And again, it's not just the UX people. I think it's the technologies in general or anyone who just have this new way of managing things. I would say digital marketers as well. So all of us, we have to sit at the table, but there's just this huge job of driving and steering the organization into whatever is next, whatever is the future.

Vitaly: Right. That's interesting. Maybe we should dive into this a little bit more in a little bit more detail. Just because, of course, we read and see and hear a lot of articles around UX, and many of them are very much focused on traditional, I would say, good all startups, digital products, and so on and so forth.

Vitaly: But at the same time, I find it quite difficult to even find case studies about enterprise UX. So maybe you could actually share those insights about if you do have this situation where you might have a seat at the table, but you actually need to change the organization. And organizations of that size are usually very reluctant to those changes, and people don't like to change their habits quickly.

Vitaly: So what would be then your process to make it all a reality, to establish a user-centric approach in a relatively tight and conservative and maybe even quite dated, let's say, environment?

Marko: Well yeah, sure. I wouldn't say necessarily that the organization is resistant to change or that people are not willing to change. Just, I would say the volume or the size of the organization is really your biggest enemy because you can influence only so many people in your immediate circle in the organization. And then some organizations are lucky enough to have a big enough UX team or, more broadly digital team that would also have a bunch of developers, solution architects, business analysts, and any type of role that you can think of in IT.

Marko: So it's just a matter of how many people you can touch within the organization with the new principles, how many people are actually in a UX type of project, user-centered service, something like that. So the change doesn't happen in the way of infecting people. You cannot just spread the UX type of virus to people, and they'll all get it. It requires a lot of effort. It requires a custom-tailored approach to communication.

Marko: Someone who has a desk job and is in departments that are understaffed, for that matter, they don't necessarily have enough bandwidth or capacity. And it has nothing to do with the personal preference of the individual person, but just the organizational structure is such that you don't have access maybe, to everyone that you would like to. And of course, it would require a lot of, a lot of time out of the regular day-to-day desk job for people to even get educated.

Marko: So I think the biggest enemy is the size of the organization. So you have to strategically pick and choose your champions within the organization. People who, whoever shows up on your open office or office hours, whatever you call it, meeting, that's a good champion. Even if they have low maturity in UX, these are people who have the intent to change something. And so strategically picking and choosing people, and then helping them become almost like a mentor within the organization to the people around them. And maybe you'll have that department embracing more of an interactive approach to understanding end customers.

Marko: I think this is the way to go. But again, I don't think people should be discouraged with that because even 1% improvement in the business process or in conversions or in optimization is... Vitaly, you and I work with web performance and conversions and E-commerce and all the stuff, and 1% can be a huge improvement.

Vitaly: Of course. I'm wondering, though, just what your way of dealing with a situation is when you have people in front of you, maybe higher up the ladder in senior management, who just have a very different view on things. Who very strongly look, of course, at their data and their KPIs, at their business metrics, and try to move them.

Vitaly: And how would you then, in a case where you, again, have to work with a company that might not have a user-centric approach at all and maybe don't think about the customer experience as much as they think about the financial benefit by the end of the year? How would you then argue in those kinds of environments about the role of UX or the importance of UX, or the importance of customer experience?

Marko: Well, I think the best way to sell something is to show them with a live example, with a practical example. And you also know that whenever we would come to an organization and say, "Hey, let's see what's the problem there." And you and I worked with a major German retailer couple of years back, and they were saying, "Hey, mobile is not performing really well. Desktop is much better." And then we realized that the average visit to a mobile E-commerce solution that they had was about 50 years or something like that.

Marko: And so once you start showing off these numbers and say, "This website is now faster," or, "This software will shorten the time from idea to conversion," just, I think performance is such an easy-to-use tool to convince people to invest into it, that it's just unbelievable... Because you can measure the before and offer, and this is something that my team at SymSoft always does. We always do the baseline measurement, whether that's the conversion rates, satisfaction, whatever, you name it, seconds to load.

Marko: And then we test and retest and retest and retest, and then you have hard facts that you can actually tie back to dollar value. And this is how you convince people that this is a good investment. And again, just starting small; almost like when you work with a new chemical that's dangerous, on your car or whatever... they say, "Hey, try somewhere where it won't mess anything up, like in a corner that nobody sees." And so we can also pick a pilot project, a really small case study, prove that it works, and then scale it up to something larger.

Vitaly: Would you say that it's important to have a buy-in at this point? Or would you say, "Just go ahead, experiment. Build a little prototype, maybe even a little bit in your spare time," just to convince that this is working? Or do you think that commitment from management and green light and approval is critical here?

Marko: So I would say that, and again, this is my experience. I don't necessarily think this is something that happens in every organization... But for me, whatever worked, whenever I was proactive and more on the side of, "Hey, let me do something in my spare time," or, "Let me finish the main task earlier so that I can actually work on the fun stuff."

Marko: Also, signaling to the management that you are proactive, that you are self-driven, that you are self-motivated, that you're not waiting for someone to approve, that you're not waiting to be served or approved or given the space. So I think management definitely likes people who are just thinking that way.

Marko: And so you basically have two benefits. You don't have to ask anyone for permission; you can figure out what is the scope and what is space available for you and just decide to do it. And then, if it doesn't work, you are not even embarrassed. Nobody needs to know. But if it works out, if it's a nice prototype, if it's a nice concept, you can definitely present it to the upper management.

Marko: And then again, you get double credit. You create something fun, but you also show that you care and that you are proactive and self-driven, and all these qualities that everybody ever always writes on the job posts, I guess.

Vitaly: Right. Well, you did mention scope, and of course, it's a wonderful keyword for me because, of course, I can almost hear the voices in the back asking about how to deal with scope creep. I mean, you are working with very different organizations and, well, of really big size. And eventually, I'm sure there will be situations where late changes come in, poor specifications are in there, communication issues, delays, and all of that.

Vitaly: So what would be your way to prevent things like this from happening, where you're missing deadlines because of the scope creep or poor estimates? What's your process in there to make sure that we don't get in trouble for delays and maybe underestimating the effort needed?

Marko: That's really a great topic. I think there are two things in there. So definitely, if we underestimate, it's completely on us, and there's no... That's very clear. It's on us. We should have had our due diligence before the discovery stage of the project when we were estimating. But these things happen, I guess, in the beginning for everyone, until you have enough experience to move from a one-page contract into a 50-page contract.

Marko: And my friend, Eva Lucas from NetGAN, from Croatia, he said once to me, "Hey, we started with one page for a contract. Now we have 70 pages," or something like that. So as you are more experienced, you just put more things in the contract and you, I guess, put more things into researching and estimating, and you probably track your hours, and you know how much time for each feature is required. So as you grow more mature in the field, there's less surprising when it comes to estimates.

Marko: Now, the second topic, which is the scope creep, usually in enterprise organizations, they already have this type of... they mitigate that with, again, other contractual clauses. Maybe something that you can communicate early on is the unanticipated effort budget. So that might be 10 or 20% of the budgets that's allocated to the project, that we don't have to spend, but this is our contingency plan.

Marko: And then another thing that's very, very useful, and this is what my director of project management always enforces, is regular meetings. Every week, we have at least weekly meetings. If not, daily stand-ups with the project management on the client side. And we have a really detailed status report that we carry over week after week after week. And we update it, and share it with everyone.

Marko: And we are not really afraid to raise any old risks. So whenever we see that there's a delay in reviewing and providing feedback, we will put it out in the status report, change the green light to yellow light, and just say to everyone, "Hey, we think that this is something that can get out of control."

Vitaly: Yeah. So that's a very interesting point for me as well because I was working with a company where this turned out to be quite a helper. So really having a more clear overview, I guess, of what our expectations are, what the process is going to be, when we expect some feedback and what kind of feedback we expect as well. And one thing that was really critical and useful at this point was to actually explain to clients that late changes are expensive.

Vitaly: Late changes are difficult to implement, and they are expensive because if you're coming from a very different industry and you're expecting a product to be delivered, you might not know just how expensive, how difficult it is to actually make those changes later on because you don't have this technical knowledge necessary. So explaining this early on, having this clear communication channel is indeed, I think, quite useful in many ways actually.

Vitaly: From my end, I think, and one thing I actually definitely wanted to cover today is, because this is something that comes up quite a bit and most recently is... you've been, again, in this industry for quite some time and you had your own head where you had your own agency, and now you are working for a company. What do you think, especially for people who might have just a few years of experience in UX... looking back, what do you think would be the right way to just guarantee personal growth in the company? Negotiate salary, get more ownership, all those things.

Vitaly: How would you say, what would you recommend maybe to people listening to this today, if they want to maybe improve their salary, maybe grow over time, maybe take more leadership position? What skills would be required, and what would be the right strategy to get where you want to be?

Marko: That's a great question. And so maybe from a manager position now, I can talk about people that I had in my teams, and what qualifies a successful UX designer or professional in general is, it's always, I guess people who are able to manage-up are more successful. Managing-up meaning that understanding that your supervisor or whoever you report to also has their life and their problems and their different, different tasks. And just understanding your overall environment, it's leading peer-to-peer.

Marko: So the understanding is that if you're in UX, there's another person at the same level in your organization in frontend or backend or marketing or project management. So just being aware of who's above, below, on the side from you and just understanding that these are also people. And then, what can you do to really move everyone, together, forward? And so this is, I guess, the attitude, being proactive, something that we talked about a few minutes ago.

Marko: Just not asking for permission because it's not true that you need weeks and weeks to create a concept. Maybe you can just catch something and say, "Hey..." You wake up one morning, and you don't necessarily have to open up your company laptop or anything like that. But just put it on a Post-it, and when it's office time, you just can say, "Hey, I have this idea. Let's do this."

Marko: And that really cost you nothing, I mean, you had that idea anyway. But you're building up your muscle of generating and communicating, and suggesting. And of course, it goes without saying, if you hear crickets every time you have an idea in your company, you should just change the company. But if you have a good environment and receipting environment where you can voice your ideas, that's a great place to be.

Marko: And so what happened is that, once you build up your credit and you look like someone who cares, not necessarily about the company... and I don't want to fool myself thinking that people want to stay here forever, but caring about the quality of work, caring about your teammates, caring about leaving some kind of impact after you leave. And there's another topic that we can also talk about. What do you do when you decide to leave the company? So are you that type of person who thinks about these moments?

Marko: And so once you have that, then salary negotiations are just straightforward because you opened up the communications channels, and then you can just come and sit and say, "Hey, what about the raise?" And then we can talk about that. But if your communication is completely blocked and you're just doing whatever you're told, and you're checking out the tickets, then that conversation about the salary is just difficult because you didn't really create an environment where you have this dialogue anyway, in the first place.

Marko: So I think practicing talking to your boss, good times or bad times, and just not necessarily sharing everything that's happening in your life, but just having this more proactive, I guess, communication. When nothing's really happening, you can just drop by and say, "Hey, this is what I'm working on. It's nothing special, but here it is." And then maybe having this regular cadence.

Marko: And if you don't have one-on-ones, and by the way, which is something that you should have with your boss... because that cadence in one-on-ones really allows you the space at some point to say, "Hey, I would like to work on something else." Or "I would like to have a better impact." Or, "I would like to have a better salary." Or, "Hey, I'm actually looking for a new job. Can you support me while I'm looking for something else?" Just being fair, I guess, to the people that you're working with. So that would be my advice about negotiating salary and these types of things.

Vitaly: Yeah. I think that many people are struggling with finding themselves in companies where there is just no culture for this kind of feedback. I mean, in some good companies, you will likely have maybe 360-degree feedback or 360-view feedback, whatever it is called, where you get feedback from everyone. And then you would have a dedicated time to bring up any issues with your manager once every three months, four months, two months, six months, I don't know...

Vitaly: But this is probably an important part to have or an important asset, I guess, to have at least. I think that many people just are afraid maybe a little bit to ask these questions, to bring this up, because I think that it might create a wrong attitude around them and that they're there in the company for the money alone. But I mean, looking at inflation rates happening right now around the world, it's probably important to have that conversation later or earlier. Right?

Marko: Yeah, definitely.

Vitaly: So maybe also building up on top of that, there're quite a few conversations happening in Europe, at least around salaries. And of course, everybody's looking at salaries in San Francisco thinking about, "Wow! Those salaries. This is incredible compared to the pay you get in Europe. Even if you're living in London or in Berlin, it's just much, much, much higher in San Francisco."

Vitaly: You happen to be in Sacramento, in California, and you happen to have moved from Croatia to the US, and shared the story about how you did that. So now being there, can you tell us maybe a little bit more about how different everything is for you? So do you feel like the culture, the way companies are run, the way people are working together that it's influenced you in some way, surprised you in some way, disappointed you in some way? What was your experience overall in these five years?

Marko: That's a good question. I think looking back, what really was new for me is how people over here are really focused. Organizations, not necessarily individuals, really focus on processes and repeatability of the process. So if you have certain steps, we can talk about the process... In design, we have double-diamond or triple-I or 5-Ds, or design sprint or design thinking.

Marko: And the reason for all of that, which is not very common in Europe... In Europe, we have a problem and solution. These are two steps that we have in Europe or have had in Europe. But here, it has to be detailed a little more with applicable tools and a decision-making diagram. So this is different over here. When it comes to San Francisco or Sacramento, I think in Sacramento, what happens is that we have a government here, so I'm not in a position to compare our environment in the projects to maybe the Bay Area, where there's a lot of just private companies and startups.

Marko: And there's a start difference even here. A two-hour drive from San Francisco. So I would even think, and this is completely my personal opinion, that Sacramento is closer just to the rest of the US than to San Francisco, compared to Europe. But another thing that's really different here is that the whole communication piece is just much more intentional because a lot of people are landing in California specifically from all over the world, and then you have a mix of cultures. And this is something that I definitely didn't think about when I was working in Europe, however internationally, but still, Europe, which is super tiny, by the way, as a piece of land.

Marko: And then we didn't have so many differences in the sense of just different cultural backgrounds, different educational backgrounds, how people have just different school systems in the first place. And so all of these people come over here, they're talented, they have certain talents; otherwise, they couldn't make it here. But then you have these different communication styles, and you have cultures that are just very generally speaking...

Marko: Far Eastern countries have high context conversations. And then you go more to the west; you have low context, which means that you have to always reiterate what the last conversation was. While in some cultures, it's implied. Everybody knows what we were talking about in the last meeting. So just these types of, I guess, communications skills that we develop now are really... that was really eye-opening.

Marko: I think especially Croatia for that matter, compared to California, is super monocultural. It's just unbelievable... That contrast is just super visible for me now, mowing from one to another.

Vitaly: Right. So having moved to the US now, do you feel like at any point you could consider moving back?

Marko: I think so, yeah. That's not off the table. I think what we like here, my family and me, and this was really a more collective move, not just necessarily for projects or work, is the access to nature here is just incredible. The way you can consume nature in California specifically is just unbelievable. It's just geared towards families. And over here, everybody's outside all the time, which is our family style anyway. So these are some of the fun things over here.

Marko: The good thing about Europe is that everything is very close. The furthest away is, I don't know, Spain from Croatia, which is a two to three-hour airplane flight. And, of course, I can fly to LA to visit Disney Land or something like that, but it's a drag to even think about the distances over here. So these are some of the differences that we notice. But again, I wouldn't say it's different or better; it's just, I guess, down to every person's personal preferences.

Vitaly: Right. Okay. Well, now, if you actually could recommend something to yourself when you were breeding dogs back, what? 20, 25-ish, 22 years ago, when you were just starting out with UX and all of that, well frontend and all that... what would you recommend to yourself?

Marko: I guess I would enjoy it more. I would joy the ride more. I was lucky enough to meet really, really great people along the way. I mean, such as yourself included.

Vitaly: Oh, that's very kind of you.

Marko: Yeah. But also coworkers and other speakers and just professionals. I think at certain points; I could have enjoyed it more, I guess. Just being more relaxed and having more faith in the future that things will work out the way they actually eventually did. So I guess, just more patience.

Vitaly: Okay. That sounds good. So we've been learning about UX in this episode of Smashing Podcast. So what have you been learning about lately, Marko? Any podcasts, books, TV shows, anything that drew your attention?

Marko: Well yeah, that's a good point. And you know me, I'm all over the place. Right? So I think lately-

Vitaly: You surely are, Marko. You definitely are.

Marko: ... lately, I'm really into mental health and just on all levels. So personal level, family level, organizational level. Just thinking about all the consequences of COVID, and just remote versus in-person. This is something that I'm really thinking about, not necessarily as something that we have to deal with right now, but what will be the outcomes in the years to come? So just getting ready for that, I guess.

Vitaly: All right. Well, I'm very much excited to actually meet you in person after all these years. In four days, we're going to meet in San Francisco for SmashingConf San Francisco. This is going to be very exciting. Quality time, family quality time, isn't it?

Marko: Yeah. It's going to be smashing.

Vitaly: That's kind. If you, dear listener, would like to hear more from Marko, you can find him on Twitter, where he's @Markodugonjic. And you can also check on Typetester, which is still kicking and still around, on typetester.org. Well, thanks so much for joining us today, Marko. Do you have any parting words of wisdom that will be staying with people listening to this, I don't know, decades from now?

Marko: No. Yeah. Thank you for having me. This is so exciting. And I think the best advice that I can have is to keep reading Smashing Magazine.

In this episode, we ask what qualities are required to introduce change in large organizations, how to convince management to do the right thing, and how to ship a billion-dollar idea. Vitaly talks to expert Paul Boag to find out.

Show Notes

• Paul’s personal website
• Paul on Twitter
• Click! How To Encourage Clicks Without Shady Tricks (published June 2020)
• User Experience Revolution (published April 2017)
• Digital Adaptation (published Feb. 2014)

Weekly Update

• Accelerating UX Maturity With A Breakthrough Project written by John Scott Bowie
• How To Build A Localized Website With Hugo And Strapi written by Zara Cooper
• Designing A Perfect Pricing Page UX written by Vitaly Friedman
• An Accessibility-First Approach To Chart Visual Design written by Kent Eisenhuth & Kai Chang
• A Five-Step Approach To The Metaverse written by Lyndon Cerejo

Transcript

Vitaly Friedman: He’s a user experience consultant conversion rate optimization specialist, and all-around expert in digital transformation from Dorset in southwest England. He helps savvy marketers, product owners, and UX advocates make the case that a usable, accessible, and people-first experience and are not reading this and seeing this. He’s the best part of business success. In fact, he’s worked in digital for 25 years, and according to his Twitter profile, he’s a very grumpy old man off the web. Apparently, he also is an author of six books on topics such as conversion rate optimization and digital and transformation. And he provides coaching, training, and consultancy for digital strategy. So we know he’s an expert in digital transformation, conversion rate optimization, and UX, and all that stuff. But did you know that he spends every Saturday evening drinking tea and chatting with his Cheshire cat called Frankie.

Paul: Lies.

<span class="smashing-tv-host”>Vitaly: Mass smashing friends, please welcome Paul Boag, and hello, Paul, how are you feeling today?

Paul: Not bad. All things considered. That’s the official British answer to how are you. There’s a really funny comedian called Bill Bailey who talks about that. He says about how Americans, when they’re asked how they are, they’re awesome; everything’s awesome. It’s an awesome day. And I’m having an awesome time, while the British say, well, not bad. That’s as good as it ever gets; it means all things considered.

Vitaly: Means that it’s okay. Yeah. Okay.

Paul: Yeah. Yeah, no, that’s, that’s a good thing. Not bad is good.

Vitaly: Right. Right. Well, it’s wonderful to have you back here. I mean, we go way back, and it’s wonderful to see you in person as well. Although I have to admit, in a very different setting, with a very great background in the back and no fancy lamps, no fancy lighting, no even fancy microphones, what’s going on with your life, Paul. I was told that you’re now not at home. And this is kind of going to stay this way for a while.

Paul: Yeah. So it’s your fault because I saw your jet-setting lifestyle for so many years where you were traveling around continually. And I thought I wanted that, but being me, being old and not quite as adventurous as you going from Airbnb to Airbnb, we bought an RV out in the states. And so we are now traveling around. We’re basically trailer trash now. We’re traveling around the states, sleeping in car parks, and just visiting the various places around the states. It’s good; actually, it’s very enjoyable, but yes, it means I don’t have my fancy podcast set up, and I just look like a disembodied head amongst the brown background.

Vitaly: No, that’s not that bad actually. So I should give you credit for that. You blend in well. Talking about blending in, I would say it’s interesting because always now, when I think of you, I always think about all the things that you’ve been doing all these years. And it feels like you had so many different hats. At one point, you would be doing mostly UX, and you would be doing digital strategy, and then you were coding websites back in the day as well, right?

Paul: Yeah. Well, we all did back in the day.

Vitaly: Yeah, sure. And also, we worked in agencies, and being a big part of an agency and not having your own big career as a digital UX consultant. So I’m wondering, there might be some people here listening, thinking about, who are just starting out their career, and UX is a good thing to kind of dive into. Is there anything Paul that you are now looking back think, okay, I wish that when I was starting out, when was it like 20, 25 years ago, I wish I had known X or Y, what would be those things?

Paul: Yeah. I mean, it was 27 years ago now, which is terrifying. Yeah, it’s a question that I often get asked. I think the main thing that I would say to myself, and of course, it was a very different world back then, and the web was very different. So people often ask me, oh, what advice can you give someone starting in their UX career today? Well, none because I started mine so long ago that it was totally different. But in terms of what I would tell myself, which is what you asked, I think I tell myself to focus on the soft skills. Don’t get caught up on the latest tool or the latest design technique, or whatever. Those things come and go, but interacting with people, being persuasive, presenting your ideas well, and not being a complete idiot to work with.

Paul: Those are the kinds of skills that really last, so. And we’re really bad at teaching those. Take Smashing Magazine, and this isn’t a criticism of Smashing Magazine, because everybody has got this problem. You’ll find hundreds of posts about design techniques, development techniques, all of those kinds of things, but you don’t find as many posts about how to survive a meeting with your boss or how to pitch the design-in, or how to review somebody else’s code without coming across as an asshole. That those are the kinds of skills that I think are in short supply.

Vitaly: Well, maybe we should change that. I mean, I heard that you have a bit of time while you’re traveling some places. Would you like to write a few articles maybe that would be just on that topic?

Paul: Well, to be honest, yeah. I mean, to be honest, a lot of the articles I have written for you have been around that kind of thing.

Vitaly: True. That’s right.

Paul: Because I do tend to write that kind of stuff because I think it’s important. I mean, the favorite article I ever wrote for you was one about mental health, wasn’t it? “You’re not a machine” and “you’re not alone”, which it’s still one of my favorite articles I’ve ever written because I think it was a very important article to write, but it had nothing to do with design or development.

<span class="smashing-tv-host”>Vitaly: Well, I remember another article that you wrote a while back that got quite a bit of... How to put it? It was argued. Many people were arguing if this is a good way of kind of explaining things or not because I remember vividly you publishing that article about SEO, right? Yeah. Do you want to share that story?

Paul: Not really. No. Because I don’t want to drag it all up again. No. So, I wrote an article saying that, yeah, SEO, I can’t even remember really what it said.

Vitaly: I remember.

Paul: But basically, I was rude about SEO, wasn’t I? but that was a long time ago, to be honest. And SEO has come a long way since then. It was back in the day where SEO was a lot of smoke and mirrors, and oh, we’re going to spam links and all of that kind of stuff/ now, of course, because Google’s algorithm has matured, most of SEO is basically good content, which is great. That’s the way SEO should be. And actually, that was what I implied in the article back then, that you should just focus on creating great content. That was part of what I said as I remember. Spend your money on content, not on SEO consultants.

Vitaly: Yeah, yeah. Yeah. Pretty much sort of plenty of SEO consultants that came your way decided to argue with you in the comments. I remember that vividly. Not only in the comments, I’m sure.

Paul: But it was really good, you see. See, I think sometimes it’s really difficult because we’ve lost the ability to disagree without it escalating. I mean, that did escalate to some degree. There were a lot of people that strongly disagreed with me, but I had some amazing conversations at the back of that. And I actually posted a follow-up post on my own site, which basically said, “You’ve educated me.” The view that I shared of SEO on Smashing Magazine was even then a little bit out of date, and that SEO was already transitioning away from what I described as being towards more being content-focused. And so, it was a really educational process to me, and I think it was a very worthwhile conversation. But these days, it’s like that would’ve exploded up into quite a violent and obnoxious discussion. And it did to some degree even then, but not as bad as I think it would’ve done today.

Vitaly: That’s about right. That’s about right. Well, you mentioned that you’ve been in this industry for 27 years now. That’s a lot of time, of course. That makes me wonder, though. So, you’ve been doing this, maybe some kind of similar work, for such a long time. So have we actually managed to sort out these general misunderstandings about the role of UX and what UX means and how to use UX, and how to transform organizations? Because it seems like we still keep running in circles, having the same conversations. So did we fail at kind of doing the good UX education work out there? Or where do you see the state of things now working with companies and organizations small and large?

Paul: Yeah. Yeah. I mean, things have certainly progressed; they’re much better than they were. So I think most organizations now recognize the value of UX, which is a huge step forward. They didn’t always. I think the many larger organizations, UX is taken more seriously. And it does have that “seat at the table” to some degree. I think, however, there is still a lot of confusion about what UX is and what it isn’t. I think it’s still used interchangeably with UI. So UX, UI designer. While in my mind, those are very different roles. So yeah, I mean, we’re making progress, but like anything, these things take time, don’t they? Cultural change is always difficult. And when you’re talking about an entirely new discipline and integrating that into existing organizations, that doesn’t happen overnight, and we’re still only a quarter of a century old, which is barely out of our teens.

Vitaly: That’s right. That’s about right. Well, now that you’re talking about those large organizations/companies because you’re spending quite a bit of time working with companies on digital transformation. And I even heard that you wrote some books about this.

Paul: I did, which are published by Smashing Magazine of the Excellent Publishing House.

<span class="smashing-tv-host”>Vitaly: Oh, that’s very kind of you, but this was not supposed to be a promo at all, actually. But I’m actually quite wondering because I’m working on my own in some kind of large rooted organization, and they are bringing along this notion of let’s establish a UX culture. This sounds very foreign. Something doesn’t feel almost alienating to some people like, oh, you want to do this now? We’ve always been working differently. So why should we do that now? Why should we change that now? So what would be then your starting point if you want to start moving an organization again, of any size, really towards something that would be a little bit more user-centric? They have their own, of course, business goals. They have their own KPI. They have their own old way of thinking. And in my experience, changing the way people work is hard. It sometimes takes not even years, like multiple years; it’s really, really difficult. So, how would you start moving the needle?

Paul: Yeah. The bigger the organization, the longer it takes to turn. I mean, there are different ways of doing it, top-down or bottom-up. If you do it top-down, then you are basically targeting senior management initially. And sometimes, someone in senior management gets it, and then you can start chipping away from that angle. But most of the time, it has to come from the grassroots. And really, I think of it as a political movement. Let’s take changing policy towards the environment, right? If you just go in and you write your MP, you’re not going to get anywhere by yourself. Okay? The way that you get large-scale change like that is your band together with other people that feel the same. You make a lot of noise, and you get the attention of those people in power.

Paul: And fundamentally, it’s the same when you’re trying to change an organization, you have to find allies. You have to find other people in the organization that has got the same desire to be more user-centric. Now they might not know the term UX, but they might. Marketers, for example. UX people are very rude to marketers, but ultimately they want to achieve the same thing because they want customers to be happy; because if customers are happy, they repeat buy. They recommend you to other people, et cetera. So you could go to those people, and you start creating an informal group of people that share your views on UX. And then you start to mobilize just like a political movement would do. Write yourself a manifesto, right? What do you stand for? What do you want? What change do you actually want to see? Very specifically.

Paul: Then do you start propaganda, basically. You start doing lunchtime sessions and sharing UX best practices. You send emails around. You get in guest speakers. You make a noise. I’ve run internal conferences within organizations. I’ve started newsletters and internal blogs; you run a marketing campaign, promoting user experience best practices. And that’s how you do it. And you begin to build momentum over time and only go to senior management when you have got sufficient momentum that they can’t ignore you. But you’re right. That takes time. Takes time to build that kind of culture.

Vitaly: Yeah. So the interesting part for me is really that very often it feels like you really have to be so well prepared for that meeting with senior management.

Paul: Yeah.

Vitaly: Sometimes it feels like you have like 20 minutes shot. This is the window that you get. And if you can convince them, that’s the only chance you get because nobody’s going to be talking to you ever again.

Paul: Then you’re doing it wrong, right? I’ve walked into meetings like that. I’ve been in meetings like that, but I already know the result by the time I stepped through the door, right? A meeting like that has got to basically be a rubber stamp by that stage. You have got to have spoken individually to each of the people in that meeting before the meeting, you have to need to have won them over beforehand. And a lot of that is about, let’s say... It’s a couple of mistakes people make; first of all, they go into meetings like that, and they go, well, no one think of the user. And nobody cares about the user other than you. So that’s mistake number one. And then-

Vitaly: That’s a little bit disappointing.

Paul: Yeah. But it’s true. Because we’re all inherently selfish, and we’re no different, right? If somebody from the compliance team said to you, will you not think about our legal obligations, right? Are you telling me you would really give a shit? No, of course, you wouldn’t. Right? Because you’re selfish. You care about users because you’re a user experience designer. So we all are selfish. We all think about our own individual areas. So, that’s one thing, don’t talk about users. You’re wasting your time. The second thing with those kinds of winning over senior management is that you got to not ask for too much, right? So, for example, I don’t know, let’s say you’re Disney, right? And you’re a little group of Disney, and you’ve got this amazing idea of you to want to create magic bands with RDF chips in them that could do all these incredible things.

Paul: But you know it’s going to cost a billion dollars to renovate all of the hotels, all of the theme parks, all the rest of it. You don’t go into senior management and say, can I have a billion dollars? Because they’re going to say no, no matter what it is that you say. What you do is you go in and say, can I build a prototype, a proof of concept, right? For a much smaller fee using a backlog, right? And this is exactly what Disney did. So, reduce your ask, go for little steps. Slimy tactics to move towards your idea. And then in terms of the, not talking about the user, instead what you do is you go to each of those stakeholders and to the finance person, you say, well, if we implemented this magic band, yes, there’s going to be a big upfront cost.

Paul: But our ongoing operational costs are going to go down as a result because the finance person likes that, right? And then you talk to the marketing person, and you say, oh, can you imagine how excited kids are going to be to get their band? And how people are going to photograph it, and they’re going to share their band if we could personalize the band, so they’re different. They’re going to love that.

Paul: And then you talk to the operational director, and you say, oh, well, people won’t have to have money, so the number of transactions that need to be processed will go down. And so we could be more efficient in the way we work. So I’m taking the same idea, and instead of talking about the user experience, I’m tailoring it to each of those different people that I’m speaking to. So when I walk in the room, they’re already all convinced, right? Otherwise, you are wasting your time because you walk into the room, you give a pitch, and you can’t tailor it to the individual person. You’ve not got enough time to convince them. So you’ve got to do it before you get there.

Vitaly: Okay. Well, I think we should be speaking a bit more in the nearest future as well, but maybe actually looking into some more of the kind of navigation search kind of problems that often show up on websites. People don’t find what they want to find. People can’t accomplish stuff that they want to accomplish. And let’s imagine just taking an example, you have a huge site, which has dozens and dozens of subsites, different departments, owning different sites. It’s all very messy. Some of them are a kind of legacy. Some are just really poorly designed, and all those things, plenty of content duplication, ambiguous labels, just all the best things kind of put together, right? What would be the kind of your process to actually just deal with it in a complex organization that has just literally hundreds, maybe even thousands of people involved that is willing to actually get better in terms of UX?

Paul: Well, it depends how willing they are.

Vitaly: Well, they hired you. They hire the best person in town. So they pretty much are.

Paul: No, no, no, no. Do you honestly think that’s the case? Lots of people think they’re willing until they realize what is actually involved. In a situation like that, Okay. I was going to make a flipping comment. I won’t make a flipping comment. What would I really do? Okay. In a situation like that, I think the first thing I would want to do is audit everything, so. And I don’t mean an in-depth audit because there’ll be too much to do a proper content audit. But I literally would want a list of all of the sites. And I would want an owner for every single one of those, who owns it, right? And who is maintaining it. I’d also probably want very top-level analytics on it. How much traffic is each of those sites is getting and a sense of when the site is last updated, right?

Paul: And the reason that I want all of that is because normally, in the vast majority of situations, there will be a load of stuff that could be just cold, right? That nobody really owns, that hasn’t been updated for the longest time, that has got hardly any traffic going to it. So the aim would be to viciously cold back everything that was there. And the logic is very simple, right? The logic basically boils down to... For a long time, there’s been a perception that it’s like a brochure. You publish it, and you’re done, which we now know is not an option. That you get rocked, redundant and trivial content. And so any web service, any website, needs to be maintained over time, which means it needs an active owner and active budget, regular reviews, et cetera.

Paul: So when you’ve got hundreds and hundreds of websites, potentially thousands of websites, you’ve got one of two options, haven’t you? One is that you hire enough staff to actively manage every single one of those websites, right? Which you end up with hundreds and hundreds of people, basically, which is totally unfeasible. So you pitch that first. And of course, everybody says no, because that’s completely unrealistic. There’s no way that you can justify that. So that leaves option B, which is to reduce your footprint, your digital footprint down to a manageable level, right? And so that means culling anything that can’t be actively managed and maintained across the organization.

Vitaly: But Paul, that means deleting and archiving stuff. That’s scary. Who wants that in a large organization? Who knows, maybe we’ll delete something important, maybe we will not be able to find something important. Who even knows all the dependencies on all those things?

Paul: Yeah. Yeah. Yes. So you’re not going to delete anything. Because A, why? The web is cheap. Having content online is cheap, but what we need to do is we need to archive it. And by that, we need to remove it from navigation. We need to remove it from search .it can still be Googled, and any internal links that go to it will still work. But then, at the top of the page, we need to add a banner or notification that basically says this page is no longer being maintained. It was last updated on this date, right? So, that can deal with anybody’s fears that content is going to just disappear and it’s going to break stuff. Then there’ll be other content that you have to have online for compliance purposes that nobody ever looks at, but it has to be there. Fine.

Paul: Then with that kind of content, what you’re going to do is you’re going to remove it from navigation. You may potentially remove it from the internal search, but you still have a direct link that you can share as you need to. So there are lots of ways. Everybody thinks that every page that we have online has to be treated equally and has to be treated in the same way. There has to be part of the navigation. It has to be part of the search. In reality, probably most stuff doesn’t. A lot of stuff is just legacy or standalone content, or that could just be directly linked, that could be handed out as a URL, et cetera. And then, of course, that simplifies your navigation down. It simplifies your search down. It means that people can indeed find the needle in the haystack, so. Because you’ve just suddenly made that who stack a lot smaller. So, yeah, I mean, it’s really about stripping back to something that’s actually manageable and maintainable by the organization.

<span class="smashing-tv-host”>Vitaly: I can always hear people screaming in the back of the room, screaming and asking about things that were related to what you mentioned earlier, all those practical tips about how to convince management about anything. I think, at some point, you were even thinking about writing an article, how to convince... Or maybe it was my title that [inaudible 00:25:44].

Paul: You suggested I wrote a book on it.

Vitaly: Yeah.

Paul: And I said, "I’ll write an article for now." And I’ve actually written the article for you, but I just don’t think you’ve published it yet. So it’s your problem, mate.

Vitaly: Oh, okay. Well, I’ll have to look into that, but maybe kind of bringing this up again, it’s always the same story. I think it’s always very useful to get insight from experienced people like yourself about how would you even deal with situations where you get difficult clients, where you get scope changes that are coming in late, where you have situations when you just have a really poor specification, you have communication problems, all those things, right? This is pretty much in every single project that’s going to be appearing in one way or the other. So what would be your good strategy to deal with on the one hand with managers, right? And on the other hand with clients?

Paul: I mean, I do a whole day workshop on this. I’ve literally just done a workshop on that for front-end masters. So yeah, it’s a huge subject that I think... What would be my top tip out of that?

Vitaly: You surely have some topics.

Paul: Yeah. Yeah. The trouble is a lot of it is kind of interlinked things. So, for example, it’s about how you set up a project in the first place and manage expectations out of the gate in terms of whose role is what. And let’s take, for example, scope creep, right? With scope creep, there’s nothing wrong with scope creep, right? As you go through a project, right? You learn things, don’t you? You do user testing, hopefully. You do user research, hopefully. You just have ideas when you’ve seen the prototype that hasn’t occurred to you. So what happens out of those things? You have ideas, you learn new things, you learn improvements, and you want to improve them. So actually, scope creep is good, right? The only problem with scope creep is we insist on having projects with fixed budgets, with fixed timelines, and fixed deliverables, right?

Paul: If we get rid of that idea, then suddenly scope creep is fine, but that’s complicated to do, that opens up another can of worms, right? So one of the things that you might want to do is don’t do these big website projects, right? So occasionally, I get asked to redesign a website. I don’t tend to do a lot of that work these days. But often, if I’m asked to do that, I’m asked to kind of oversee the process. And the first thing I say is, I am not going to do a project that is an end-to-end project, right? From initial user research through to delivery and post-launch optimization. I’m not doing that as a single project. That is a big mistake. Instead, I’m going to run a series of smaller projects. I’m going to do a discovery phase, right?

Paul: Which is going to clearly identify user needs, the competition, the constraints, everything like that. And then that is going to inform me, giving you a quote and a timeline for a prototyping phase where I create a visualization of it. And I test that and that visualization and that prototype, that’s going to allow me then to quote for the build phase, right? And I could give you a price hourly because each phase informs the next. So how you structure projects makes a big difference. And then, of course, that means that between each of those stages, between discovery and prototype, between prototype and build, you could change the scope all you want because it’s another project. So things like that make a big difference as well. So, yeah.

<span class="smashing-tv-host”>Vitaly: Yeah, but what if you’re working, let’s say, you have this big procurement processes and all those big companies and tenders and all those things where you kind of need to know upfront. I’m guessing looking at your face right now that you are going to say, just don’t do them. But I’m wondering if this is the answer that we should be getting to?

Paul: Yeah. Yeah. I mean, I don’t do them. It’s the honest answer because I’m lazy. And any time there’s a procurement team involved, which requires a fixed price and fixed scope, immediately that’s a warning flag for me that it’s going to be a nightmare project. So I’m just too lazy to deal with it. But I understand that I’m in quite a privileged position. What I did do when I ran Head Scape with projects like that, and my preferred approach there is to, yeah, I’ll give them a ballpark for the whole thing, right? I will quote them for the whole thing. But in my tender, I will say that this is an estimate only. And I will introduce the idea of breaking the project down and doing it in different ways. Just because you receive a brief asking for a certain set of deliverables in a certain thing doesn’t mean you have to give them that, right? It’s okay to say, hang on a minute. I don’t think you’re doing this in the smartest way, right? And that there is an alternative, better way of doing it.

Paul: Now, one of two things will happen in a situation like that. Either they’ll dismiss you out of hand, right? In which case, you really don’t want to work on that project, right? Because it will be a nightmare from beginning to end, the expectations will be unrealistic. It will be challenging. There will be problems with scope creep and all those different areas that we’ve just talked about. They will happen. There will be no way around them, right? So that would be a huge warning sign.

Paul: Or they go, oh, these people are suggesting something different. Oh, that’s interesting. And they’ll actually like the fact that you’ve challenged their brief, and suddenly all of your competition that has just blindly followed the procurement rules and done what they were told to do suddenly look less proactive. They look less like they care about the project and that they want the best for the project. So actually, it’s a really good way of differentiating yourself to actually turn around and say, well, here’s something that kind of gives you a sense of the overall budget, but this is how you really should work it. And that ultimately it’ll work out cheaper that way. Because obviously, the overall budget, I have to add a load of guesses in there and a load of contingency in case my guesses are bad.

Vitaly: Yeah. Yeah. So I also see some agencies or companies using value-based pricing, where they actually go in and think about the impact that they can make in an organization and then kind of price based on that. What’s your take on this?

Paul: It’s BS. There you go. Here we go. This could be SEO, the SEO article all over again.

Vitaly: I’m very much excited about what’s coming up next year listeners, please pay attention now. Bookmark this spot in the recording.

Paul: Oh, people are going to hate me for this. Jonathan’s start is a great... I think it’s Jonathan’s Start. My brain is just shut down. He’s a really great guy who pushes value-based pricing a lot. I’m cynical about it. Some people seem to manage to get it to work, and good on them. And well done them, but it feels like a fantasy to me, value-based pricing. I understand, theoretically makes a lot of sense. If I’m going to earn a company a million, then it’s perfectly reasonable for me to take 10% of that $100,000, even though it’s five grand worth of my time, right? That’s perfectly reasonable. Don’t disagree with the principle. It’s the reality of it that is difficult for two reasons. One is that in a vast number of projects, depending on the type of projects you do, that can be extremely hard to prove, to get real numbers, right?

Paul: So unless it’s an eCommerce site or something like that, then actually it’s pretty hard to get a solid estimate on how much potential you could make. Secondly, you are giving no guarantees that you will get that level of return. And you can’t make those guarantees because there are so many variables involved. When you are quoting at the beginning of the project, you don’t know what constraints may exist that would limit what you can do. You don’t know what the client might say they want or don’t want. They might come up with stuff that’s a bad idea. There are so many things you do not know that there is nowhere on earth you can be confident you can generate that degree of return, right? And so how then, can you say, I want this percentage of that number. So I think, in principle, it’s great, and it sounds wonderful in practice, but it rarely works.

<span class="smashing-tv-host”>Vitaly: So Paul then can you hear the voices from the back again saying, but Paul, but Paul, but we are UX practitioners. If you look at the number of job applications all around on UX, it’s tons of openings. So because he was speaking about millions, how do you then become a millionaire by being a UX designer? It doesn’t work. Well, the reason I’m bringing up this question is because a good friend of mine told me once many, many, many years ago, he’s kind of more my mentor. And he told me, “Well, you never become a millionaire by just working 24/7 or kind of having a full-time job alone. You really need to think about passive income. You really have to think about how do you invest money? And you cannot just make a lot of money by working nonstop. That’s just not going to work.” So how then do we become a millionaire, as you expect?

Paul: Why are you asking me? I’m not a millionaire?

Vitaly: Why not? Well, you do have a wonderful, fancy chocolate background in there.

Paul: exactly. Well, this looks really high quality, doesn’t it? You can tell that I’m in a quality vehicle at the moment. First of all, I would challenge why do you want to become a millionaire? And this is really interesting. Take my dad, for example, right? My dad is a worldwide photographer. They have barely any money ever, right? They earn below the national average of the UK. Okay? Yet they travel around the world, right? They go on multiple cruises every year. They go all of these amazing places on somebody else’s dime, right? Because he’s a wildlife photographer. And he lectures on cruise liners and stuff like that. So money is only a way of enabling you to do what it is that you want to do. So the question then becomes what you want to do. And because I do a lot of mentorship of agency owners, right? And agency owners, a lot of them start going on about passive income and stuff like that. And don’t get me wrong. I have passive income. I get passive income for the courses that I run. I would say the royalties from the books, but how little that actually is, but I do get-

Vitaly: Let’s not put it out there.

Paul: Well, you don’t get rich writing books. Everybody knows that. That’s not why you write them. I mean, unless you write Harry Potter or whatever, so. So, but I do have passive income, but not an enormous amount, but I live the life. I want to live. I go where I want to go; I do what I want to do. So the question then is not, how do I become a millionaire, but how do I get the lifestyle that I want, right? And that’s a very different question. And there are different ways of doing it. And passive income might be a part of it.

Paul: In other words, an exit strategy where you sell on your business, whatever that is. And then you can retire early. I take the approach of I’ve designed a business where I have to work four hours a day, right? So, and that is achievable as a UX designer or a UX, or you can get your rate to a point where you can get away with working four hours a day, take over a good income, and spend the rest of your time enjoying yourself. So, I don’t think the answer is just to become a millionaire. I think the answer is to get the lifestyle you want. That’s my opinion anyway. Unless, of course, your lifestyle is I want a yacht. In which case, you do need to be a millionaire.

<span class="smashing-tv-host”>Vitaly: Well, yeah, but just because you’re working four hours a day, we cannot afford you anymore. Because you’re getting really, really expensive, no, I’m just kidding at this point.

Paul: Yeah. No, no, I am very expensive, right? I’ll be upfront with you. I will charge anywhere between 195 and 165 pounds an hour, right? That is my rate, depending on the number of hours that you buy. And I can maintain a charge-out rate at that level because I’ve built a reputation that means that demand for my services outstrips my ability to supply that. So basically, I could charge and weed out people that can’t afford me unless I really fancy the project. That’s enough. This is how you should price projects, right? And this comes from Mike Coos. Do you know Mike Coos? Yeah. He’s an amazing, amazing designer amazing from Australia. And he told me this once, he said... when he comes to pricing, this is how he prices. He says to himself, “How much would they have to pay me to make me want to do this enthusiastically, right.” And I think that’s a great way of pricing. Okay? Because then you work on the stuff that you really, really want to work on, right? That you really enjoy. And because you charge that at a lower rate and then the stuff that you don’t want to do, you charge at a higher rate, which subsidizes the stuff at a lower rate, so.

Vitaly: Yeah, that makes sense. But what would you suggest then to people who maybe don’t have that much experience and they kind of have to compete on the market, and the market is quite saturated? I mean, if you’re a UX expert, that’s great. That works, but still, you go to there are plenty of platforms which provide services for like $30, $50, $80.

Paul: Yeah. Don’t play the game.

Vitaly: Yeah. So what would be the strategy for kind of pricing there?

Paul: So, I work with a lot of agencies that are kind working on these platforms like Fiver and Upwork and stuff like that. And those platforms are universally, without exception, price orientated, right? So you are always going to be stuck at the bottom of the market, and you’re always going to be competing on price at that point. And also, you’re competing against free stuff. You’re competing against creating a page that you can use a template from on Square Space; it’s a losing battle. So you’ve got to move out of the bottom of the market. So how do you move out of the bottom of the market? Where you start to build your own audience, rather than relying on the audience that’s provided by these marketplaces. And I’ve got a course on this called Finding Clients where essentially you need to decide, okay, I want to target a specific sector, because most freelancer agencies, their marketing approaches are terrible because they’ve got no training in it.

Paul: They don’t know how to do it. Nobody’s ever taught them how to do this kind of stuff. And so they throw out the old blog post, and they redesign their website for the 20th time. And they put out a few social updates, and they call that marketing well, that’s not going to win you any new clients. You need a strategy for targeting a particular sector, getting into that sector, and building relationships with that sector. So you become the go-to person for that sector. And once you are the go-to person, once you are the person that everybody goes to higher education, you must go to Paul for that; once you get to that point because you are specializing, then you could push your rates up. And also, you are targeting a sector that isn’t just going, oh, I need a cheap web designer. Now I know I’ve skipped over a lot of detail about doing all of that, but you know, we haven’t got that long, but.

Vitaly: We’ll have another session on just that I’m sure, sometimes soon in the future, I think.

Paul: Sure.

Vitaly: So maybe just one final question to wrap this kind of slowly wrap this up. I think just two weeks ago, I received an email from somebody who just, again, working maybe I think three or four years spent in the industry, and what they were asking is how do I negotiate my salary? So I’m working, let’s say, in a product team, or I’m working in an agency, and it feels like you are hired for the position, and you’re kind of stuck. So, the inflation is now through the roof, and it doesn’t seem like everybody’s going to get any increase in the foreseeable future also because the company isn’t doing that well. So at which point and how, what would be kind of strategic advice from your end to say, this is how you do it in order to increase your salary, at least, get a stronger position in the company, maybe instead of salary have more ownership or anything like that over time. What’s the right way of doing it?

Paul: I don’t really know. Sorry. That’s a really bad answer to your last question.

Vitaly: No, that’s an honest answer.

Paul: But the truth is the reason I don’t know is the last time I worked for a company was in 2001. So yeah. So it’s not an area I work in. Of course, I was an employer for a long length of time. And I could tell you what an employer’s big fears are, which is that you leave and so our desire is to maintain our staff because getting the new staff is really, really expensive. So I think if you are getting dissatisfied with your salary, probably an honest conversation with your boss and say, look, I want to be completely upfront with you, all right? I’m getting to the point where my cost at home because of inflation and all the rest of it is getting high. I’m going to need to start looking for another job, I’m afraid, right?

Paul: And instead of me taking lots of half-day sick and that kind of stuff, which is so obvious, I thought I’m going to be upfront with you and tell you instead. And if I get offered another job, I will come and talk to you first; if you want to match the salary, then we can certainly have that conversation because I don’t want to leave here. But this is the situation that I’m in. And it might be that is enough for them to want to nip that problem in the bud. And they’ll give you an increase there; if not, follow through on that, look for other jobs, find other positions. And if you do get an offer, go back to them. So sometimes, that’s the only way of doing it. It’s just honesty about your situation. Because most employers, in my experience at least, they’re not out to screw you over. They’ve got their own targets and things that they’re worrying about their own, budget-free constraints and that kind of stuff. And so honesty is always the best policy. Isn’t it really?

Vitaly: Yeah. That sounds about right. Well, maybe the final one, then. So Paul, is there the universal wish you would be writing a book about all those things combined and again, the management and the growth, and I don’t know what else. Do you have time doing it, don’t you?

Paul: No, I don’t have time on my hand. I will write another book. I will inevitably write another book eventually. It’s obviously quite a big-time commitment to write a book. I don’t think it could be about...

Vitaly: Is it? I think for you, it’s easy peasy. You just go ahead and say, okay, I can commit to the next three months. And then I get a chapter once a week. That’s much what it was like last time around.

Paul: Yeah. I mean, I can write a first draft in about a month of solid effort. Yeah. But I don’t earn any money in that month, so. And you got to keep that in mind as well.

Vitaly: I mean, we do pay some pennies,

Paul: But it doesn’t cover my charge out rate. Let’s put it like that, which we’ve already established is unrealistically high, so. But of course, it’s completely worth it for me to write a book because it kind of generates new business and stuff like that. But it does mean I’m in an interesting position. Let’s be honest about these things, right? I write books about subjects that I want to work on more right. So when I wanted to do digital transformation, I wrote Digital Adaptation. When I wanted to do more organizational user experience cultural change, I wrote User Experience Revolution. When I wanted to do conversion rate optimization, I wrote Click. That is simply how it works. And every time, without fail, it shifts people’s perception of what I’m an expert at.

Paul: And I win work in that, right? So it’s a really good marketing strategy, but there’s the problem. Literally, if I write a book on soft skills or I write a book on winning clients or whatever, what work does that bring me? See, that’s the interesting one, isn’t it? And that’s where you have to think ahead with these things. And what I was saying earlier about your marketing approach needs to be strategic. Yeah, perhaps it would get me more work with agency mentorship, freelance mentorship, and stuff like that. But that’s not a big earner compared to working for a multinational company.

Vitaly: Well, I know I have another title. No, no, no, no, no. I have another title. I would love you to write a book about something like, I don’t know, establishing processes or working in large enterprise organizations.

Paul: Yeah. See, now that one, that’s got a lot more potential, a lot more legs for it in terms of running my own business.

Vitaly: I think so too. So when should we sign the contract then?

Paul: No time soon, I’m afraid. I’m overjoyed in my life at the moment, so.

Vitaly: Okay. Well, that sounds about good. That’s good enough for me, but I’m not going to let it go, Paul. I’m just saying, so I’m going to send you a few messages back and forth.

Paul: Yeah. I’m feeling really bad about this interview. I feel like all I’ve come across is this really callous person that won’t do anything unless I’m paid; there’s other money to do it.

Vitaly: No, I don’t think it comes across this way at all. I think when I look at the articles and every now and again, when I Google anything really, I will be stumbling upon one of the articles that you have written over all this, what, 200 years?

Paul: 200. Yeah. Coming up to 200, right?

Vitaly: Yeah. That’s pretty impressive. So this in mind, I mean, I have no doubt that you do a lot of things also just because you honestly believe in that. If you, dear listener, would like to hear more from Paul, you can also find him on Twitter, where he’s at Paul Boag, and on his website, which is, surprise, surprise, Boagworld.com. His books, all the books that he’s so kindly mentioned in the last five minutes also available, of course, from Smashing Magazine. So you can also find them and read them. And if you want Paul to write more books, send him messages. Actually, he’ll appreciate that. Right from that end. Thanks so much for joining us today. Paul, do you have any parting words of wisdom with the wonderful people listening to us now?

Paul: I’ve always got the same one, which is a success is going from failure to failure with no loss of enthusiasm, which is a Winston Churchill quote. And when it talks about whether you’re talking about getting a pay rise, whether you’re talking about changing the culture in your organization, or whether you’re talking about getting a project over the line, success is going from failure to failure without any loss of enthusiasm. So just keep chipping away, and you’ll get there.