Episode 91: Investing in Internal Tools with John Athayde
Melissa Perri welcomes John Athayde to this episode of the Product Thinking Podcast. John is a design team leader, strategist, and individual contributor, as well as VP of Design at PowerFleet. John and Melissa discuss how he shifted focus to the importance of internal tools at Living Social, how he got buy-in from leadership to prioritize internal tools, the process of creating a design system for a scaling organization, the benefits of design systems, design systems vs. style guides, and the tools and org structure he recommends to get set up for success.
Subscribe via your favorite platform:
Here are some key points you’ll hear Melissa and John talk about:
What led John to PowerFleet.
John shares how he started pushing for improved internal controls. “As I was working on the front-end screens, [I realized] we could make this a little better.” He convinced some product people and engineers, and they collaborated to do a bunch of mockups. They presented them to the CTO, who gave them his blessing.
Designers should know how to code, or at least know how code happens, according to John. “You can’t design a building without knowing how a building is built.”
You can use product thinking to design your internal tools. It’s less of just a design issue and more of an issue of creating a product, which is a complex internal operating system. This is necessary to actually scale.
A UX engineer is a front-end developer who is primarily focused on the look and feel as opposed to functionality. They are the bridge between functionality and design. It's a person with the design sensibility who can speak code and help implement, but they're not doing the implementation.
Now that almost everyone has some kind of experience with software, UX and UI have become more essential. Consumers are going to subconsciously compare their experience with your user interface with others.
Every company needs a source of truth for their operations, that is, documentation for all the relevant information needed to continue operations. In the event of key people leaving, the work they did would still be there for the next person to take over.
We often take for granted how important the role of a UX designer is in a high-growth organization.
Resources
John Athayde on LinkedIn | Twitter | Website
Transcript:
Melissa:
Hello and welcome to another episode of the Product Thinking Podcast. Today we're joined by Jonathan, who's a VP of Design at Power Fleet, and we're gonna be talking all about internal tools and design systems. Welcome, John. So John, can you give everybody a little, uh, overview of your career so far and what led you to Power Fleet?
John:
Hi, thanks for having me. Uh, sure. I've been, I happened to kind of grow up with the web and so I, you know, I started off in high school in print and, and went to architecture school and there somebody introduced me to Hot Dog Pro on Netscape one and all that kind of stuff. So I had the benefit of making it up as I went, cuz there wasn't much there. Um, and I ended up doing a lot of the marketing web in the early, you know, early odds, late nineties, and shifted in about 2000 5, 6, 7. That time, uh, started a business with Amy Hoy doing, uh, high end UX work called Hyphenated People. Uh, and from there went to a rail shop called Info Ether, and I was the sole designer there. And a, and it was about seven of us when I started, grew to about 15. And then we got picked up by Living Social. And after that I jumped around and went to Cargo Sense, and I'm now at Power Fleet, which is a logistics o t place. We do all that kind of work,
Melissa:
Great. So one thing that I was catching up, uh, with you about before we jumped into this podcast was really internal tools. Um, and I know that I get asked questions about this from all the product people out there. Uh, how do you make a case for internal tools? You're not shipping net new features. How do you get people to invest in them? How do you convince people you should be, uh, doing this? And I know that you have a great story about how it got started at Living Social. So can you set up the scene for us when you came into Living Social, what did it look like? How was it growing? You know, what's your team look like? Give us the lay of the land.
John:
Right? So 2010, 2011, uh, info beater got acquired by Living Social and Living Social had a split engineering and design team. You know, they were, they were very siloed at that point. Uh, there were only 15 engineers in the company at Living Social and Info Ether was 15 engineers. And so a little bit of a culture clash, merging teams and, and thoughts and whatnot. But that, um, that became the core of what grew to 150 ish person engineering org over the next two years. Um, and, and originally as most startups do, it was a, you know, monolithic app. Um, and for those who don't remember Living Social and IT competitor Groupon, which then acquired it, are very much this Daily deals thing. It was a big, big hotness in the early <laugh> 2010s. And it was, you know, people like, if the, the deal was a new price.
So if you wanted to go out and, and do something and you lived in, in one of the markets, you would go see what was on Living Social to Groupon, pick up a a deal, and then go do that event or something along those lines. And, and they expanded out into, you know, vacations and whatnot. But there's a couple different things you have with the consumer business, which is what, you know, we would consume. Then you have the merchant side of the business, which is actually one of the more important things that was kind of lost, and that's where you're helping merchants put this deal through. So a lot of these merchants aren't used to having 3000 people suddenly show up. Um, so you're trying to run that and also then looking at merchant tools, things of that nature. Uh, and then there's other stuff too with, you know, the, the, uh, the, uh, escapes, I believe was the name of the, the product offering, which was, you know, vacation trips and package, like prepackaged vacation deals in a similar vein where, you know, they've gone through and set up these discount deals with all these different things to try.
Uh, so that was kind of the, uh, the, the business app and, you know, having that monolithic app and you, you, the more engineers you add, the more likely to have, you know, code conflicts and weird bugs start getting lift in. And, um, so one of the things was to move to a service design. So you start chopping up the app in Logical parts. So obviously the consumer facing piece became one, merchant became one, uh, and internal tools kind of was just like, you know, we have some of these things that are CRU apps, there's stuff in Salesforce, all sorts of stuff just floating around. Um, and so we were doing, I was starting off doing front end work there, uh, and, and just kind of cleaning up some of those UIs with some of the other people. And, um, and that started to grow from there
Melissa:
I feel so bad for all the 21 year olds moving to New York City, who will never know what it was like to just subsist off living social coupons for like my whole first five years living there. <laugh>, it was, it did. It was like the wild, wild west. We just went out to dinner every night and new places. You get a massages for like 30 bucks. It was great. I missed those days <laugh>.
John:
Right? Yeah. I mean, that couldn't go forever though, right? And it's, there was something missing there and <laugh>.
Melissa:
So no, definitely was something missing like there. Yeah, I I mean I, it totally makes sense why, why it's not around anymore, but, so we've got your, your company, you're scaling really fast, you're moving into this services business, and what, what kind of prompted the whole, like, Hey, we should be looking at internal tools and you know, who, who was behind some of those discussions? How did you present it to people? Were you getting any like pushback?
John:
Yeah, so some of the, um, as as I was doing the working on the front end screens, I'm like, Hey, we could make this a little better, you know, talking, you know, we're just, we're just trying to basically keep the, keep the ship running, right? So, I mean, things are, are literally duct tape, you know, that's just the nature of a really fast startup. Um, so we've got, you know, a lot of Excel files, things getting bounced around, um, a lot of credit interfaces somebody made in Rails. Like somebody said, Hey, I need to see the account order history. Okay, here you go, here's orders. And it's literally an admin dump. There's no styling, it's just, it, it technically works, but it's not very usable, right?
Um, and so as I'm going through and doing a lot of these front end edits, it's like, Hey, we could make this better. Hey, we could tweak this. And I finally go through and, and you know, talking to a couple of the product people and, and some of the engineers and I, I end up doing a bunch of mockups, uh, bouncing back and forth with them and the internal users and kind of say, Hey, here's five screens of where this could go. And, um, we present them to Aaron Battalion, who's the cto, and Aaron is not one who who holds back an opinion, right? So if he, he's very quick to like boom, boom, boom, very quick decision maker. Um, and he doesn't say anything at all. He's just looking at these screens and I'm sitting there, you know, like, Oh dear, I'm, I'm about to be fired, or I'm gonna get read the Riot act, or something like that.
Uh, but he, he, after a while, he finally looks up at me and says, you know, this is like 18 months of work at least. And I'm like, this is just a, these are vision boards, man. These are not like, we're not shipping this today. This is not a product plan. This is like, Hey, maybe this is a thing we could do and it would be fun and cool. Um, and so we, we kind of got that, that blessing. And so one of the first primary projects is that, uh, Ben Getson, who was the product, one of the product guys, uh, he and and I started working on, um, customer support. We kind of thought that was something we have metrics on. We know it's bad, we, we know it's a pain and it, the customer is right here in DC down the street. We can walk down.
I mean, this was literally, we were downtown DC I was sitting near the White House. They, these guys were sitting over in Chinatown. It was a really weird kind of like, explosion of how an office worked, but um, you know, you could go over and shadow them, which is, was crucial. So that's how we kind of kicked off and getting the buy-in, uh, there, I mean, a lot of people were, were kind of like, what, you know, not quite sure what we were doing, making internal tools why we should be focused on this part of the business. But once they started seeing some of the results that, that went away. And I think a lot of people then realized the, the richness of that, kind of like multiple wedges of the pie, each one getting improved in different ways for the customers. And they had an r and d, um, like five person engineering r and d group that would do just come up with crazy stuff, you know?
And, and so a lot of that, you know, we would do quick mockups with them too, just to be like, Hey, you know, a lot, just like a lot of the, the Hail Mary design passes, right? This doesn't exist. And, and we've not researched this, but this could be really crazy fun, right?
Melissa:
I think your story is such a great example of companies that are scaling super, super fast and they're thinking about like, new feature, new feature. What can we put out to the customer? What can we put out to the customer? But they're not really like looking internally on how do we scale ourselves or how do we make sure that we're not, you know, overextending ourselves or setting ourselves up for failure when everything breaks. Um, but you know, you talked about not everybody was super bought into it at first. Can you explain a little bit about, you know, what your CTO had to do, what kind of air cover you needed to go out and be successful for it? Like what, what were the conversations that were happening and how were you holding off all these, you know, requesters there? Like, why don't you just build things for the business <laugh>?
John:
Well, some of it, I mean, once, once we got the CTO buy in, that definitely helped cuz he was, he kind of blessed us and said, go try something. Um, but you know, before that I'm, I, you know, I'm a designer, but because I, I'm very much the fan of a designer who codes, which is an unpopular opinion. Um, and I, so I think designers should code or at least know how code happens, right? Cause I come from an architecture literally building perspective, and it's like, you can't design the building without knowing how a building is built.
And so, you know, I was doing front end development because the, I felt that the, at least the initial team was very siloed, and I felt that they were just throw, you know, waterfall, traditional, here's the design spec, toss it over the wall, boom. Which I mean that works, but, and, and the industry, this was 2010, right? This is almost 15 years ago now. Things have changed a lot. But, um, you know, so that, that kind of thing was, I was not in design, but yet I was starting to do design. So there's a little bit of pushback there, like why is that guy doing it? Um, there was also a little bit of like, we have all these, you know, things we're trying to ship and you want to go off and do a party project <laugh>, I got that from a couple people.
No, it wasn't, I mean, these aren't endemic. It wasn't like there was a wall of people's and, and there's three of us standing at the base of it being like forward, right? No, it was, it wasn't that bad. But, um, you know, I mean, like some of the stuff that, you know, we, we had a problem, like agent SLA on the, the customer service reps was only 20%. So that means, you know, one in five calls were getting abandoned before they could even pick up the phone. Not even someone getting mad hanging up, just never got to it. Um, and it took a really long time to complete a case, you know, like all the solutions they could offer, people were all custom one off things. They would have to get approvals on. Some of 'em go back and forth. You'd have a lot of touch points back and forth with the customer.
Let me call you back, let me email you back. And when we did shadow them, we noticed that more time was spent documenting the call than actually being on the phone with the customer. So we had a rich story and a compelling argument to fix that. Uh, but it still took us, it took us some time messaging that. And then, you know, Ben was able to do that on the product side. I was able to do that with the engineers and we kind of, and, and at this point, you know, they had started to spin up a proper internal engineering team. So we had, you know, people dedicated to work on these projects. So it, it was a, you know, that the team was growing so fast too, that, that, you know, sometimes the old guard didn't necessarily have time to really hold onto something.
And so, and, and everyone was pretty, I mean, everyone was pretty laid back about it, um, in the sense of like, okay, that's where we're gonna go now when, I mean, I think, I think there was a lot of comfort with the pivots because part of the company was moved fast and break things and, um, and fail fast was another one of the kind of tenants from, from the, the C level. So try it and, and I mean, we're not gonna give you two years, but go, go break it, see how it is, and then if it failed, then we'll we'll put a pin in that and move along. Um, but um, yeah, there was definitely a little bit of the initial like, you're doing what <laugh>.
Melissa:
So with the, it sounds like the culture was kind of set up a little bit for you to go out and do this. You know, you're still getting some side eyes from some people, but, but it's not too bad. It's not like preventative. I imagine it also took a little bit of initiative for you to look around and be like, Hey, these things are broken. I'm gonna really go out there and advocate for it myself.
John:
So yeah. And before we did the pitch to Aaron, the cto, there was me just kind of, this table is ugly, I'm gonna fix it.
You know, so that's the benefit of being a designer in the code, right? You know, I'm not asking permission early on here. I'm just going and being like, Hmm, okay, fix that font size. That contrast is bad, you know? I mean, you're not doing big sweeping designs, but you're going through and you're your fixing components. You're fixing elements. You're saying this could be better. And, you know, then you ask somebody, Hey, does this work? And they kinda look at you funny, like you're asking me like internal tools. People tend to be, you know, they, they are used to the duct tape, especially in a startup. So they, they aren't used to being like, Oh, you, you can make that better. You can change that. Yeah. Whoa, hey, could we do this? And then, then you gotta watch out. Cause then the feature factory starts, it's like, here's all the things I want.
Um, but yeah, at least you know, you, you start to kind of trickle that stuff in and then that kind of builds out like, okay, I'm seeing where this is going. And so some of these, um, some of these mocks, which are, I are in the, the thing I sent over to you, and they are public so people can see them. Um, we're, we're very much around, um, what they call deal quality and programming. So people doing a lot of research on markets, um, business research, right? I mean, it's kind of the stuff that UX and product people do. But this is at a sales side kind of focus. And they're, they're trying to figure out, okay, Minneapolis, what's gonna be great? What's gonna do well? What resonates with that customer base? You know, obviously doing some, you know, you've got different climate issues there than you do in Florida than you do in San Francisco. So, you know, you've got these annual cycles on timing. So all this stuff like is all in their heads and it's all in cell files randomly thrown around. So how do I bring that into a product? Um, and so this really is, is less than less of just a design, um, issue. And it's really, we're we're creating a product, right? Which is a, a complex internal operating system.
Melissa:
Yeah. Uh, my <laugh> job at Open Sky actually, which was also a Flash Deal site, but just not for local things, uh, was doing the internal tools. So I oversaw all of that except I had all the buy in the world to do everything when I walked in because they were like, it's breaking and people were quitting and nobody could do their job and it's awful and all those things.
And I always loved it because, um, you know, my customers were sitting right next to me, so I just walk over to them and be like, Hey, you know, what's going on here? And it was funny, some of the, um, <laugh>, some of the, uh, the, the people who would do the sourcing of the products we sold, they'd try to come over and like bribe me with samples to see if I could prioritize the stuff that they wanted. They're like, Do you want this French press? And I'm like, I do want that French press, but we have to do these other things first.
John:
Right? Let me check out the queue. I'll get back to you.
Melissa:
But I always love Yeah, exactly. Check my backlog. Um, maybe we can make some room. Depends how good <laugh> how good of that sample we got. Exactly. <laugh>.
John:
Yeah. How good is this French press, right?
Melissa:
So, uh, but I, I always, um, I always get questions about like, how do you think about internal tools and people don't see them as products, So I, I like your point there where it's just, it's the same product thinking to how we do our internal systems and that's necessary to actually scale. So you're at, uh, living social, you're doing your customer service, uh, part first. What happened next? Where, where were you going after you tackled that? People saw it, they were like, Wow, we're making some progress. Uh, where do you go from there?
John:
So a couple things came outta that project. One, we actually got really good metrics on what this stuff did. And I mean, the project took a lot longer than expected, but that kind of is, I think any low, you know, low definition, broad, uh, mandate project. We're like, go, go fix crazy stuff over there, right? And it's like, I didn't, you know, I should have been a little more like, you know, scope this. But, uh, I mean the, the, the good thing is we changed, you know, by showing these metrics improved, right? Agent SLA went from 20 to 90%. Uh, we dropped call abandonment right from 20% to 4%, and we reduced the time to complete a case by 20%. The other big thing that we did, which made the experience internally so much better, is we unified the ui.
So every CSR had to type in record changes into the Rails backend system. That was our internal admin. And then they'd have to duplicate that content in Salesforce in the case system. So, uh, Dave Bach is a Ruby engineer, and he and Pete, uh, Fenland went and they did this amazing, um, kind of a what's right, I don't know, map object, relation map or ORM between Salesforce and Ruby. So now Ruby could talk to Salesforce as a database and not just an API like this. Crazy, I don't know. I mean, they could tell you what, it was a lot better. It was, it was a little over my head, but it was like, that's cool. So now we from one UI could talk to the Rails admin and Salesforce. So when somebody types something in it, we figured out where that went. They didn't have to worry about that anymore.
They had one, one interface rule them all. And the other stuff is, whenever you shadow customer support, if you, any organization you're in, even if you're not doing internal tools, customer support is like the canary in the coal mine. So there was tons of stuff that came out of this while we're shadowing that we were handing off to other teams. And so the consumer team went and made a self-help site that had like all the frequently asked questions. They were like, What? We get calls nonstop about this thing, which is actually really easy to answer. Or you can even do self-service on it. You don't even have to call us to do it. So they made this self-help site, which helped cut down calls further, right? So being able to find those elements and pull them out, that, that kind of was like, Oh, everyone's starting to get, you know, the benefits of this project.
And from there, um, you know, as we're building this out, Lynn Wallenstein, who was my, uh, my lead front end person, just an amazing, uh, developer. She's, she was a get hope for a long time. And, and now she's over at Cargo Sense as a head of head of engineering. She would go and she was building out stuff in, uh, we kind of started with Bootstrap, like, ah, we don't like all these things. We only need these pieces. We wanna change these pieces. So she started pulling that she liked into a custom, uh, SCSS repo like setup. So, uh, saas, uh, so it's, it's, you know, at the time we didn't have CSS variables, any of that stuff, but, so we could define a color palette, we could define all this stuff as variables, and then go through and use that in any build. And she ended up making it into a Ruby gem at the end of that.
And from, and we called it wild, like Oscar Wilde. And so, you know, high fashion, stylish, great writer. Uh, and we, uh, we, she had gone through and did, um, kss, which is, uh, Kyle Ne was an early GitHub, uh, individual. And he had built this kind of like inline documentation. So you would write the documentation in the, the scss, and then there was a command that would generate your, your docs. So Lynn built this crazy awesome gem that had a generator, so somebody could load this gem up in their Ruby project, the Rails project, type two generator commands. And then their, their application layout, all that stuff was built. And so they loaded up the screen, they had the standard global nav elements that we had determined for, for the company. And it was, you know, this internal tool subset. So it derived from the commercial brand, but it was separate.
And then she, she was able to, to have this, um, the documentation in line. So if you were in development, you'd put, you just went to your, your local host 3000 slash Wilde, and you had all the docs there. So even if you were offline, you were on an airplane, it was built into the gem. It was in, it was in the app you were building. So you always had that, and it was versioned. So if we made changes, we could say, Hey, new versions out with this element. It wouldn't break anybody's app, but that stuff. So that, that stuff she did over about two years, you know, that kind of progression. But once they realized they could apply this to other things, it became a very quick like, Hey, can I put this on this thing? I gotta go build? Like, because at this point they had already really started servicing things out, but there was no, I mean, there were 15, 30, somewhere in that range of Indi just engineers working on internal tools.
And there was me and Lynn, and then we hired Robert Goya, who was just a JavaScript guy who did all, like, all sorts of JavaScript work with like backbone and stuff like that. And we had Kevin Doyle, who was another UX person, he, and so he and I were kind of handling the UX side. Lynn was pretty much the owner of, of the style guide, right? And so she would implement all this stuff and then we would bounce back and forth and being able to have that, and it's like, Oh wait, I have this kit of parts and as a designer, I have this kit of, So you're like, Oh, I need a timeline. Boom, I need this now. This is Photoshop, this is not Figma or Sketch. Or even, I mean, I wish I had used Adobe fireworks at the time, or what Macromedia I think it was.
I don't know. But, um, it was, uh, you know, this is like literally copy that, you know, PSD that almost crashes your computer and, and, and you know, pray it doesn't, you know, pray it opens this time. And so, you know, we did a lot of that. So there was, it wasn't as as beautiful as some kind of like symboled sketch repository, but it got the job done. And we knew that these buttons were these styles. And, and if you look at the, the wild documentation, you're like that, that's the bootstrap buttons with some tweaks. Yeah, exactly. Yes, it is. Because we were like, Yeah, we like the button elements, but I didn't want half of the elements in there. I, and we, we, we scraped a lot of that out. Cause I didn't wanna load in this entire way of doing things. And I have strong opinions about how HTML should be written and thousands of classes tacked into HTML is bad <laugh>.
So being, being the opinionated, uh, jerk sometimes, you know, that's like, we kind of built the system the way we thought it should be. Uh, but that once we said, here's the gem that the Ruby Gem, which is a library, it's like Bower, we even eventually, she made a Bower package for the JavaScript apps, and, and they even put it on a scale app for some something. I don't remember. It was some financial tool, which is a Java derivative. But once, once it was like, Hey, we can distribute this. It became really powerful. And I think the craziest thing they did, she and two of our Apex engineers, which is the sales force, like heavy lifting stuff, they went in and applied it to the sales tools. So when sales logged into their sales tools, it looked just like the deal quality tools. And that was kind of like the whoa, crazy cool. Um, so that was called Launchpad. That was a really cool setup. So they had their daily calendar and their deals and I mean, it was all, we pulled all these things together from different parts of Salesforce, so they had a better interface to, to start their day out of. Really,
Melissa:
So you built this, uh, style guide and uh, I've seen it called design system for other people who might not, who might know that. So it also called Design System for, uh, people who don't know style guide. Uh, I feel like you can use it interchangeably, but I've, when I've been in organizations and we've done this, it's been a huge game changer for allowing us to scale.
Um, when I was at Athena Health, our, we had a team build a design system like that, similar to what you talked about. And we had 350 product teams who were all creating their own buttons at one point. So we had something like 10,000 Okay. Buttons, <laugh> that were all different colors and shapes. Yeah. And then you look across the app and you're like, Why does it look so bad? Um, so I know that is such a concern. You're just like duplicating efforts there. You're reinventing the wheel. Um, one issue that we also had that I thought this solved really nicely was we didn't have enough UX designers at the time. Um, we were training up the product managers there too. Uh, we didn't have, uh, tons of UX designers to go around. We didn't have one per team, so a lot of teams were like pigeonholed in what they could do, uh, because we were waiting on design and talent to come over and help. But once we made the style guide, a product manager with a little bit of design sense could, you know, mock something up and at least bring it to the UX designer and get halfway there and make sure it looked right, you know, bring it to the director of UX for advice instead of weeding on somebody to go. And that made such a huge difference for us being able to, to scale all that.
John:
Oh, for sure. And I think you have, I mean there's, there's four kind of big use cases in my mind around design system, and you just hit one really hard. Uh, but like, I mean, first of off, it's a scalability factor, right? So, you know, you never have enough resources to do this work. It's always, we always need more people. So this lets the developers focus on function and gets things to 80%. And then, oh, I have this weird interaction. Oh, I, I've got two hours to help you on that. I don't have two weeks, right? Um, the versioning of it too, you know, this is, you know, where you can, you have, this is the source of truth on this date. Um, and that, that third one being a source of truth, right? So, you know, onboarding new engineers, onboarding new designers, it's not, the designers all have very strong opinions.
We, and they all like to do their own thing. And when you say, Look, this is the language we work in here, this is the visual style we work in here, It's not a, you have a little less friction of the oh i like this way and then the maintainability, right? You wanna make changes in 30 apps or 350 apps or whatever. You change it once and, and hit deploy as opposed to saying, Oh, we gotta <laugh>, let's get a project going to just change this color, you know, four shades that way. Um, and that, you know, that having that really helps. I think. And if you look at the, the nature of like style guide versus design system, I know that, you know, you touched on that too. The, um, coming from the print world, we always call them style guides or brand guidelines, right?
And that they, they are different products in the end, like a style guide or a brand guide type color. You know, you have some lockups, but I mean, we're typically in the print world. So this is a business card, this is a one pager, right? Um, but you have overall visual rules and there's often a voice component we do often, which is, you know, one of those things that I don't, I think people forget that, you know, we've always had content and tone and we're always, at the end of the day, we're always presenting content. Um, and so that's always been part of it. But now design systems where they've evolved, like that term came out, what, I don't know, 2015 maybe. So it was like a little after we did this work. Um, but you end up start talking about design principles. Um, global accessibility becomes something great that you can now really, uh, influence.
So you can actually say, Hey, that contrast doesn't work, and we're gonna change that on every app. Um, nowadays we're getting into stuff like, you know, animation styles. So we can start globally saying, Hey, here's how things slide in and slide out and here's the code to do it. Um, and it's real code, right? So it's, it's um, like stor react, storybook or one of these tools, right? So this is an actual thing. You literally drag and drop in your app and you're done. Your button is perfect and it will never need to change. Cuz if we change it, we'll change it at the component level. You don't have to worry about the button, you just put the text on it and good to go. As opposed to the, you know, I've seen React apps where you've got the button was literally copied and pasted and then they, you know, because it's componentized, you've got 15 definitions for that button that were copied and pasted and drifted.
So <laugh>, that's, you've got all that stuff. So I, I mean the design system is taken a brand guide, which is this PDF that we pray that you read to a little more of a, a, you know, enforcer maybe is the right word. But, uh, you know, it's definitely the, like, this is how we do it and here's here's the code to do it. And that's where I see, you know, this UX engineering role starting to happen, right? It's a front end developer is primarily focused on look and feel as opposed to functionality in React or something like that. And they kind of are the bridge between development and design and really making, cuz I mean a a, this, this product of a design system is not something that can live in one or the other. It really is a shared piece. A shared product is a better way to think about it.
Um, and having that, that interaction and the UX engineer or whatever term people would like to call it, that really helps unify that together. It's a person with the design sensibility who can also speak code and help implement, but they're not doing the implementation. They say, Here's the thing, here's how you run it. And then they come in and say, Oh, let me fix that for you. Same way with the design. Oh, you need com, you need this component. Well that's, we're gonna go work on that and see how this could be used in other products and make sure we cover it and then we'll roll it out in the next version.
Melissa:
I think that's a really good point. Um, the style guide versus the, uh, design system. So yeah, I remember, uh, I did a big redesign of this platform back in like 2014 and we didn't have Figma or anything there, and I do not do front end code. I can tweak front end code, but I do not write it. Uh, so I had to literally document everything in a PDF report and it was like 250 pages long and it killed my soul. And now we have Figma and I'm like, uh, <affirmative>. Mm-hmm. <affirmative>.
John:
Yeah. Figma or Mirror or like UI audits, right? You know, that's, that's where you start this. Like you were talking about the, the thousands of buttons, you know, everyone's favorite, you know, you, it's very easy to to to see those. Cuz you're like, why is that orange? Why is this purple? What's going on here? That doesn't make sense. You know, our primary buttons are all over the map and they exist in different places. And, and, and it's literally a, like a screenshot safari. So you're just going through a screenshot screenshot, you know, and, and it's cool when you can throw that into a sketch Figma, and then you, you've got different pages and other people can be, you're like, you go handle whatever part of the app or your job is to find every modal good luck call us if you get stuck, right? <laugh> and, and here's your, you know, here's your area of the file, you know, as it were to, to, to save those.
And then we can come back and say, Okay, let's look at MOS today and let's try and figure out the, the common patterns, the the other things like that. Um, but yeah, starting with the screen grabs and you'll get past the, you know, you very quickly will identify it and that helps sell it too. Honestly. If you have, if you have a shared experience across platforms, for example, mobile desktop, that's where you see a lot of drift happen really fast because they're, the, the tools usually don't come together. And that's where you can sit there and say, Look, mobile app doesn't feel like our company. Or you could argue that if the mobile app is the primary way things work for people, that our desktop app doesn't feel like it's part of that experience as you can come back and then it's, you know, from there it's, it's more of a, um, it's kind of just the heavy lifting aspect of this work, right?
You know, if you, you gotta decide on a system, Are you gonna use atomic design like Brad Frosting? Are you gonna use bem? Which block element module? Like all those technical decisions you start having to make. But like, you know, that's why I like to refer to it as a product because it's never, once you start this, it's never done. And it's like a product, if you're gonna stop using it, you have to figure out a way to spin it down and it's, you can't just say we're, it's, it's done and that's it. I mean, I guess you could, but that is a really bad internal developer experience, right? <laugh>, wait, what do you mean? We've gotta copy all this across and now manually maintain it. Mm-hmm. <affirmative>
Melissa:
Yeah. So if you are, um, somebody new, let's say today we've got all these different systems, we mentioned a couple of them, Figma, you know, sketch a lot of stuff out there and you wanted to build a design system for your team, uh, what would you start with? How do you get started with it? Who do you involve and then what types of tools are you gonna be using along the way to do this?
John:
Well definitely start regardless of your tool set with that UI audit. Um, you know, there are, I do, I do like the collaborative toolkits, um, and, and Sketch, Figma and mur all have like Miros a whiteboarding collaborative whiteboarding tool. Uh, and, and I've really come to love that recently. Um, and it's, it's cool because you just, you can start really truly collaborating on something virtually. It is the virtual whiteboard that we never had, you know, a decade ago. And so, you know, you used to have people pile into a room with the whiteboard and somebody scribble on it and everyone on the phone couldn't really see it. And that miro breaks that. And, and I, I mean I guess you could do this in Figma as well, but, um, you, you need to go out and find those people. So usually product has to be heavily involved.
I would ideally have a person who this was their product or one of their products. Um, so if you have a, uh, you know, if you have a, a, a head of, of, um, consumer, and then you have three product people under them, one of them would also own the, uh, the style guide or the, the design system for consumer. Um, and, and it needs to have that level of equity with those other products. Um, from there, you know, you do need buy in from engineers. Cuz at the end of the day they have to put it in there. So, and, and, and if you think about it, your actual customer on the design system is the engineer. Um, they are so, so interviewing them, what's a pain in the butt? What's really hard to do? Why is this so miserable? What are things that you've run into?
You know, And, and a lot of this stuff you'll hear from engineers is, I just want this to look good, right? And, and they don't like to release stuff that doesn't look good. I mean, they want it to function too, but as you know, after we get past the, does it pass the test? Like, well, you know, this, it works, but it's not really something I'd want to show anybody. Like, so how do we, you know, is it something that needs to look good too, right? That's the other option. Not every tool needs to be consumer grade, but there's a, I kind of gonna contradict myself and that everyone is now used to a mobile phone. So this is my experience regardless of where I'm working. So 20 years ago people didn't have tons of experience with software. Now everyone has experience with software, right?
So I'm going to subconsciously compare you to Facebook, Instagram, email, Google, whatever. Like that's, I'm going to compare it no matter what I do. Um, but you know, government sites I think is probably one of the places we have a lot of opportunity to fix <laugh>. That's, that's probably something where most of our, our software and internal tools are, are at parody, if not better than. But um, there are some places that are doing U sds and 18 f are doing some really cool stuff there, and at least on the US side, um, but, you know, getting that team and buy in, so from product, from engineering and, you know, and then being able to sit there and start working through your standard product flow. I mean this, it's not, this isn't some mystical thing really. It's, it is product development. Um, and, and I think it's, it's, um, it's from an architecture perspective, at a point you do just kind of say, we're gonna put a pause on this, or we're not gonna keep, I'm not gonna go through and reiterate all this stuff.
Um, that, that, I can't remember who said it. There's a famous quote that great buildings are never finished or simply abandoned. But if you then think about it after that, right? Somebody moves in. So it's still curated, it's still kept up, it's still, you know, but, but from the architect's perspective, I've, I've passed that project on, right? So, you know, there's still, you still need to have a, a custodian and that this is honestly one of the failure points that we, we had when, so I ended up leaving to go to Cargo Sense and Lynn ended up leaving to go to GitHub within six months of each other probably. And we didn't really have anybody who was replaced Lynn. And she was really the, the kind of the source of truth and the, the, the, how this works was all up here. And, you know, while we had documentation in there and people could use it still, there was not that, that resource and that reference. So making sure that there is a handoff, like right, Like who's the new product owner? Who's the whatever, you know? And, um, as opposed to project man, product manager, right? So who's gonna own this and who's gonna be the responsible for it and, and be the source of truth internally. That's one of those things that, that we failed on, you know, early on there. But having that team buy in and then making sure you think about it as a long term product, I think will, will make it successful.
Melissa:
Okay, so we've got the system that we're actually developing in the, um, css, CML that shows you, you know, each one of these elements has this type of code behind it, right? We've got the team around it that's setting it up, that's managing it. What other elements do you need? Um, you know, your, you talked about mural for whiteboarding. What other things would you need to put together or should these people be managing like a product to make sure this is scaling, it's in the hands of the right people. Um, like how do people use Figma today? And, and stuff like that too with like a design system
John:
I mean, part of it's documentation, which you could do in Figma, but this is this kind of points to stuff you've talked about recently and, and stuff I've heard about like research ops and product ops, right? Like how do we have this documentation that lives on? Um, that's not, cuz that something, um, something I have in, in, in the, the talk that I did back on, on the day on this was Dave Bach had a great quote where, um, we were, and I mean very little has changed, right? We were lamenting the lack of permanence in and the la the difficulty to find things in Slack <laugh>. So people still today complaining about that, right? So making sure you have like, what are the artifacts? How did you get here? And so I think, you know, research op products ops, design ops, all that kind of stuff, having a source of truth and a record of that that is available.
So if your team uses Figma, and I mean that means products in Figma too. Not just your designers. Like if they can all work in Figma together, let Figma be your source of truth, that's cool. Uh, if it's Google Docs, let Google Docs be your source of truth. That works too, right? I mean, but like everyone needs access. It can't be that design has this wonderful, uh, you know, clandestine mega file that only designers get in and it has everything in it. Like you need, everyone needs to be able to see what's going on there. So doesn't matter what the tool is in there, but like, I mean, that's why I like things like Miro, I feel they're more approachable. Figma and Sketch to a certain extent really are kind of these, like, you open it up and you're like, What am I looking at? <laugh>, you know, mirror's a little easier cause you go, Oh, I got buttons to click. Oh, I can do this. Oh, okay. It's, it seems to be a, a, a simpler, uh, flow. And so, you know, it, you can invite people in and it's, you know, it's kind of more about that whiteboarding vibe, um, as opposed to like the prototyping tools and stuff. I think people just get overwhelmed. It's kinda like opening Photoshop for the first time. It's just like, um,
Melissa:
So when you do, when you do the, the mural boards, are you putting all of the elements that you typically would have in like a sketch or anything like that in there? Like throwing it in there and letting people drag and drop them? Like how are you collaborating around
John:
You can, I mean that's like really at the end of the day, from a design perspective, like you're gonna have a design kit that's gonna be used by your designers, right? So you're gonna build that in your design tool, Figma Sketch and being, and these integrate different ways with different platforms. So Sketch and Envisions dsm for example, integrate well together. But the Sketch file itself is not the, it's not the design system. It's, it's a kit parts, it's, it's, it's a UI kit, arguably, right. You know, for building that stuff out. And then when you take it to the next level, it's like, okay, what are these elements? Okay, I can look at my documentation file and that's where I'm going to have, and you could use GitBook for this. There's all sorts of like, you know, off the shelf things you could use. You don't have to go build a custom documentation system, but you can go in and say, Hey, all right, here's, here's our buttons, here's our button states and here's the CSS name for these states or whatever, you know, uh, or the React component name.
A lot of this is really dependent on your, your, uh, your stack and what you're building in at the end of the day, uh, for the best practices. But, um, what I like about say, Miro or Freehand or one of those tools is you can put final mocks in there. So from Figma you can drop in your mockups in, in a separate area. So when you're working through a project, you can, you can have all this stuff in there and it's more about understanding and review as opposed to the source to pull it from. It's kind of the artifact of how we here and where, where, where the snapshot of where we are today.
Melissa:
Cool. That's nice. I like that, that collaboration around those things too. And it's nice when everybody can like pile in and, you know, move things around or copy and paste stuff and show people different versions of what it actually looks like, uh, just like you were doing on a whiteboard, but in real time. Um, that's pretty cool. We did, uh, I had, uh, Athena Health, we made like sketch libraries with all of the UI components in there. And like I was talking about when we didn't have enough UX designers, we were trying to hire them, we just didn't have enough. Um, we had this huge push from the CEO who had just learned about rapid prototyping and he was pushing everybody to do rapid prototyping for better or for worse. I mean, we had a lot of issues with that mandate to begin with. I was like, I don't need to review 50 prototypes of something that we don't understand the problem of first.
Like, let's, let's do this all correctly. But when the teams did actually need, you know, narrow down on their research and figured out what to do and they wanted to go forward, um, they could all just jump in sketch. And some of the problems were, you know, like small, they didn't require like a huge redesign of something. It was like, no, we just gotta move some stuff around the page or create a new page to solve this. And it was nice cuz they had that whole library in sketch to do that and the design system that the engineers were working with as well, so they could put it together, like I said before, like bring it to UX director, bring it to a different UX designer, just be like, am I on the right path with this? Which required, you know, maybe an our meaning instead of 20 hours of work of them putting it together and then implement it really fast. And I think we take for granted how important some of these things are for when you're in a high growth organization or in any organization that's trying to move fast. Like if you can't enable your team to do that, you're not gonna get the results that you actually wanna see. It's not just about coding quickly, it's about making the whole process quicker.
John:
Yeah, exactly. Right. And I, this is where I think the collaboration aspect is crucial, right? I mean, there's, there's some stuff we did like that where it was literally Ben, myself, and an engineer in a room on a whiteboard scribbled a component. I mean, it's illegible to anyone walking by, but we all knew what it was. And then we're like, All right, let's go build it. Boom. And, and that's the, that's the power. Cuz we didn't have to say, Well what does this button look like? What does this dropdown look like? It was all defined. Um, so it was just, yeah, this is a, this is a select, this is this, this is that. Okay, I can go write that. So you solved the problem and the engineer got right to it.
Melissa:
So, um, so it's, it's it's amazing. It's just like magic when I see this actually work. Uh, one of the questions I do get from people is like, where should the team live? Uh, who does the design systems? Like, you know, who does it report up to? Who, who's got this purview, right? Is it under the UX team? Is it under the product ops team? Is it just under the internal tools team? Like what, what have you seen Work
John:
Oh bless. Um, so at Living Social, we'll start there, I reported to the head of internal tools engineering, Glen Vanderberg. And um, but that was more of a legacy of me stomping my foot and saying, I wanna be in the engineering uh, org. So, um, I don't know if that was really the best place, but the benefit was that engineering, I was one of the engineers, right? So they were like, yeah, sure, yeah, we let's, you know, it wasn't, wasn't designed coming over with, you know, Cause I mean some of, some, I mean at the time still Design was doing , They they were beautiful and there were these like 30 page PDF speck files and you're just like, that's really awesome and it is all specked out as to what to build. But you know, it's, I, they, they, they consumer and merchant built their own systems pretty soon after we kind of had, had deployed.
So I, I think that they all kind of saw the benefits of moving faster like that. But you know, I still just remember this, this amazing PDF of joy and wonder and it's just like, oh wow, okay. Uh, how long, you know, could you have coded that in the time it took you to build that in, in design? Probably. But, um, yeah, <laugh>, I think, you know, if I'm a big fan of design in general living under product, um, not everybody agrees with that. Um, but I think that, and I also think that design should be cross org. I don't like marketing and, and product design being split. I don't like hardware design being split. I think they should all be together because all of these things have heavy interactions with each other. If you are a company that is, uh, let's, let's throw Elon Musk under the bus for a minute.
Like Tesla, you know, you're building a massive piece of hardware that has a massive software component. If the hardware and software design teams aren't working very closely together, that's gonna really be a problem. So, and then, you know, I, I always feel that that, uh, you know, Peter Holtz, um, does kind of broke it up as communication design versus product design, right? In his design org book, um, that he did with, I'm blanking on her name, the lady from Capital One, but, um, that the, um, it's all the adaptive path alumnus, crew, the, uh, but they, they, um, they kind of talk about this how like everything, you know, you have these kind of, these groupings and, and having these splits is weird because then you get these back and forth. So the product is defining the pricing, all these things, you know, typically in an organization, the product is defining what we're doing, the go to market strategy, all this stuff, and then it's marketing gonna duplicate all that effort. I mean, I, you could, I, I don't know, I'm, I'm, maybe this is the, the, the product coming our ball, right? Where we, we absorb everything, but I do kind of feel that that stuff does belong under, under the product leader
Melissa:
So you're preaching to the choir over here. Although I know there's a lot of people out there who do not agree with us, but I've seen that be successful. We had, um, yeah, when we, when we did this at Athena Health, uh, we had the chief experience officer reporting into our CPO across the whole area. So they oversaw like the entire platform was really big.
We had had like 5,000, it was a 5,000 person team. So, um, and then the under the, uh, chief experience officer, we had, um, head of design, um, systems and insights and uh, she was in design ops too. They did a bunch of design ops stuff, but her name was Jen Cardello and she was in charge of kind of ushering that through and putting all the design systems together and we stood up product teams around her and the teams to do that. So, uh, it was nice because it was a good product. They, they, they were great product thinkers in addition to UX designers. So lots of product mindsets went into building out all the design systems and the things that everybody used, but, uh, it was nice to be able to stand up teams around them and have developers dedicated to actually building these things out too.
John:
Oh, for sure. Yeah. Getting and getting that buy in, like at the C level and having that come down, I think is, that's huge. So if you've got the CTO and this so being like, make it so right <laugh>, uh, that, that's gonna, that's gonna move the ball forward a lot faster.
Melissa:
Oh, for sure. Well, thank you so much for sharing all of this with us, John. Um, if people are interested in more about your work or to learn what you're up to, uh, where can they connect with you?
John:
Uh, two best places are probably, uh, LinkedIn in Twitter, John Athayde, and I'll spell that. Alpha Tango Hotel, Alpha Yankee, Delta Echo, all one word, um, j o h n. And um, you can get me on both of those there. And then, um, john@aade.com for email. Uh, and then if you are interested in random farm stuff, uh, I do live on a farm outside of Charlottesville, and so you've got sfumato.com very rarely updated, but there's, there's always a picture or two up there of antics with lots of young children.
Melissa:
Love that. I have actually a friend who probably is very interested in that <laugh>. I'm gonna tell him. Um, he, he lives in a farm in, uh, like outside of Cleveland, Ohio. So a lot of, a lot of product people getting into that, into the farming. Um, so thank you so much and if you are listening to this and you enjoyed, uh, this episode, we're gonna have all those links that John just mentioned on our website@productthinkingpodcast.com. Uh, so make sure you go there and we will also link to his presentation from Living Social so you can see those design mockups too. Uh, we will be back next Wednesday with another episode of Dear Melissa, If you have any questions for me, please submit them to dear melissa.com and I will answer them every Wednesday. And if you enjoyed this podcast, please subscribe. Uh, wherever you're listening to this, whether it's Apple or Spotify, it doesn't matter, hit that subscribe button so that you don't miss us every Wednesday with a new episode. And we'll see you next time.