Mike Aparicio — Senior User Interface Engineer, Design System at Groupon
I’m Mike Aparicio. I am a Senior UI Engineer at Groupon. I work on our product design team. I’m essentially the only engineer in design, and to my knowledge, I’m the only UI engineer at Groupon. When I say engineer, imagine me doing air quotes around engineer. My background is primarily a self-trained web guy, like a Jack of all trades type deal and ended up going to Groupon to be in a situation where I was collaborating with people with complimentary skills.
At my old job I would mention something about CSS and their eyes would glaze over because they didn’t know what I was talking about. It’s nice being in an environment where there’s other people with those skills that I can have a conversation with and learn from.
Currently, I’m working on our design system. Prior to that I had helped build our CSS frameworks that we have for our internal tools, our consumer facing product, and also our merchant products as well.
All right, let’s get right into it, Mike, you’ve mentioned you work on the design system now, what’s the most difficult thing that you’re facing in relation to design systems? Get it out of your system.
For me, it all comes down to communication. The way that I pitch our design system is that it’s a common language between design, engineering and product that describes how we make digital products at Groupon. It’s really not like a design solution or an engineering solution. It’s more about people and process and how do we talk to each other?
I think there’s this disconnect in a lot of organizations between design and engineering. A lot of that stems from, we’re delivering pictures of websites. I equate it to, it’s like a painter. It’s like DaVinci giving the Mona Lisa to a sculptor and saying, “Here, make me a statue of this.” The sculptor is looking at this painting and he’s like, “Okay, well how big is this supposed to be? What does the back look like? What’s all this stuff in the background, I can’t sculpt that.” The sculptor is left to make these interpretations of the painting and the finished product doesn’t always end up matching the designer’s intent, and there’s a lot of disconnect there.
It sounds like you’re talking about... It sounds like you’re saying there are two different languages that designers and engineers speak. The design system is the bridge between those or maybe is the common language. Maybe you could talk a little bit about what are the languages that designers speak and engineer’s speak and what’s common between them but also what’s different between them?
Definitely, we have different tools that we work in. Our design tools are things like Sketch and Figma, they are people that... We’re using them to build web products, but they’re not necessarily designed to output web friendly stuff. We’re also designing for multi-platform.
Not only is there this difference between design and engineering, there’s also a difference between web and iOS and Android. Not just how we make these things, but what do we call these things? Is this thing of toast? Is this thing a modal? Is this a pop-over?
A lot of times we’re talking about the same thing, but we’re using different words and there’s something lost there in the translation, but then we’re also... Designer might be talking about a font size in points and on web they’re talking about pixels and is that the same thing? Maybe on Android they’re using SP, they’re using different colors, we’re using hex values or RGBA or whatever. Things have a tendency to get lost in translation there.
How do you solve that at Groupon? Is it a matter of one discipline just has to roll over and do it the way that the other one is, or is there some compromise? How do you bridge that gap?
We’re actually working on that now. That’s something we’re trying to develop this taxonomy of what do we call these things? Really, I think for me the big key factor is boiling those all into design tokens. That’s something that I’ve really advocated for, given a lot of thought to. Taking those design decisions, separating out the visual style of things, which would be, like in web, all of the CSS properties, versus the actual components themselves. Things like buttons and form inputs and things like that, that are... Where the HTML and Java script would come in. What is it and how does it work versus what does it look like?
For some reason, Brad Frost just popped into my head. Atomic design. A lot of people are familiar with Brad’s atomic design. If you think of a button as an add-on, then these tokens, these visual styles are essentially like subatomic particles. I think Brad posted something about this, something to that effect, because every button has all of these visual styles. It has a background color, a text color, a font size, a padding, border radius, things like that. This all combines to make what this button looks like.
When we redesign our site, we’re not changing what markup we’re using for a button or how a button works, we’re just changing those visual properties. We can codify all of those in these design tokens, these variables that store what all of these values are, and we can control those in one place without having to make a lot of updates on the engineering side. We don’t have to find every instance of a button in our code base and manually change the background color.
I’m so glad that you brought up design tokens because they’re such a great example of how you have a tool that both disciplines feel ownership over, but still is a way to communicate between the two. A lot of times when I talk about design systems, I talk about design systems are generally for developers. If you look at any design system component detail page, there are words like API and Booleans and strings and stuff like that. Designers are like, “I don’t know what those are.”
I would say yes and no. There’s what I described as expressions of the design system. The UI kit it’s like an expression or an implementation of the system for designers to create. Then you have things like CSS frameworks that are an implementation of that system for the developers. The tokens are that shared thing, that’s the single source of truth, that stores all of those things.
But yeah, definitely... That’s part of the problem, we have all of these different implementations of the system, a lot of the challenge comes when those things aren’t in sync. The designers are updating the UI kit but then it doesn’t get updated in the framework. There’s this disconnect there, the developer gets this picture of a website and he sees this new thing in the UI kit, but it’s not in the framework. So, then he has to make a one off, and maybe that one off doesn’t get put back into the UI kit.
Then the next time somebody needs that pattern, they’re making a one off and now you’ve got like 10 modals on your site. That’s another part of the communication process is how do we collaborate in a way where we have this process that we can design a new thing, make sure that it’s reflected in the developers tools so that it gets into production the way we have designed it originally?
Yeah. Can you think of an example of when that’s gone well and when that’s gone poorly? How do you keep tooling in sync? How do you keep assets in sync? Maybe you can share a couple of stories about that if you have some.
Honestly, we haven’t really figured it out. Particularly having worked across every part of the company, working on internal tools, working on consumer, working on merchant stuff, it’s not connected. We’re solving those problems in different areas of the company and then also within those areas. Everything is so siloed that without these systems, you have these teams who are essentially trying to solve similar problems if not the exact same problem, but without communicating with each other.
You end up with five teams making five different modals and they’re slightly different or not even remotely the same. These systems help get everyone on the same page and provide a consistent look and feel across the product.
A lot of the stuff that you talked about so far is like, the tools themselves serve as a communication vehicle. The tokens, the system itself, are there other things that you all do for communication? Is there a shared Slack channel or an email newsletter or what kind of stuff do you have like that?
We actually relatively recently switched over to Slack from... We were on HipChat before. Not that Slack provides a great deal of additional features. But, it’s been an adjustment, I would say, how people are using that and using the... I don’t know what would you call them, the plugins or stuff like that to automatically post stuff to Slack and things like that. It can be hard, particularly when... Again, having a bunch of siloed teams.
For example, I work on our merchant CSS framework and we were just talking today about how we don’t know what teams use the framework. We built it with a few teams in mind, but there are other teams that are like, we need CSS. Hey, let’s use this. We don’t even know, they use it like bootstrap essentially, but it’s more branded to Twitter.
At Groupon it’s been challenging because I think we tend to prioritize hiring for computer science fundamentals, “Hey, can you whiteboard this change making problem.” Versus, what’s a block element versus an inline element.
If you’re not asking those questions, you end up with a lot of developers who have the same skillset and then you can’t vet people for those other skills if you don’t have people with those skills. It perpetuates itself. I have this whole talk I did equating this... I have a beef with the term, full stack developer.
I have this gif that’s like Dr. Evil doing air quotes and it says, full stack developer. But hey, if you’re a full stack developer, more power to you, but I feel like people are more.... It’s not a stack, it’s a spectrum. While you have people who have those skills. Take Brad for example, he knows a lot of things about a lot of different things, but his area of expertise or the thing that he focuses on are design systems or atomic design, or you might have someone who’s really a good designer but they’re into... Typography is their strong suit or something like that.
Yeah, that makes a lot of sense. It’s interesting that... It’s almost counterintuitive that full stack developer is being more and more valued, but really a crucial role for design system, especially a really good tech agnostic design system is HTML and CSS. Is that being more and more important as we pass through the flavors of the week, whether that’s React, Review or Svelte or whatever it is.
It’s going to be some new thing in two years. I’ve been at Groupon now for eight years and we’ve gone from Rails to Node to Angular, now we’re on React and then Preact and in two years it’s going to be something else. Then our design tools as well, we’re moving from Photoshop to Sketch to Figma, to whatever the next thing is, we’re still just delivering a picture of a website, but maybe we’ll get there someday.
I equate the whole full stack developer to companies are looking for these... They’re essentially looking for the LeBron James of web design, who can fill the box score. He can score, he can pass, he can rebound, he can play defense. That guy is, or girl is working at Facebook or something. They’re not working for Joe Startup over here. You’re not going to be able to field a team of five LeBrons. You got to get yourself like a Steph Curry that just shoots threes, but he’s really good at it, or a Dennis Rodman, who he just plays defense and rebounds. You have to have this synergy of people with complimentary skills and not just a bunch of people who can do one thing okay.
Yeah, that’s right. LeBron can do it all, but the Lakers are still clamoring for a real point guard.
I totally get the analogy and see how it fits with design systems. Well, Michael, let’s wrap it up. What advice do you have for people that are working on design systems that could use some help in communication? Maybe they’re just not communicating well. Any tips that you have for where they could start or things that they can continue?
Really, I think just like getting everybody in the same room. There’s a lot of articles about selling a design system, but I don’t... In my experience, it sells itself the problems that it solves. You shouldn’t have to... It’s like responsive, you shouldn’t have to sell responsive, just make that the way you do things. Make the design system the way you do things.
It’s all about what is your process and getting everyone on the same page. It’s not about whether we use Sketch or Figma or whether we’re using web components versus some other thing. Really just trying to get everybody on the same page, figure out what everybody’s pain points are and looking at how various things in a design system can help alleviate that.
There you have it. The most difficult thing Mike’s up against regarding design systems is communication. Mike, thanks for getting it out of your system, and I’m sure you’re not the only one facing this. I’m Dan Mall from SuperFriendly, and thanks for listening to this episode of Get It Out of Your System.
Joanna Kirtley — Design System Lead at Liberty Mutual