Klare is moving on from design at CodePen to design at GitHub. Huge congrats Klare! If you didn’t know Klare was our one and only dedicated designer here at CodePen and left a massive mark here in the design and UX of CodePen, the app, as well as internally in our organization practices. I’m talking with Klare here just a few days before her last day to reflect on her years here.
Time Jumps
- 00:25 Klare’s announcement
- 01:40 What are some of your work highlights?
- 04:01 Accessing your work
- 05:26 Following social feeds on CodePen
- 08:00 Designing at CodePen
- 11:27 Leaving behind a design system
- 14:06 Making incremental changes
- 16:08 Sidebar nav for an app
- 18:02 Homepage updates
- 21:26 Using a common language for code design system
- 25:35 Documentation and project management
- 29:08 New job description
Transcript
[Radio channel adjustment]
Announcer: Today, on CodePen Radio.
Chris Coyier: What's up, everybody? CodePen Radio 365. This is a sad one for me, perhaps bittersweet for Klare. I have Klare with me. What's up, Klare?
Klare Frank: Hey, Chris.
Chris: As you all are listening to this, Klare is already gone because there's a delay in podcasting releasing and recording. Klare, you've taken a job at GitHub. This is the end at CodePen.
Klare: That's right. Almost four years at CodePen.
Chris: Woo! That's great. Part of this is me just--
I thought we'd just live conduct the exit interview. [Laughter] No, just kidding.
Klare: [Laughter]
Chris: More like just thank you for all the work you did here. It was a long time. You've done so much at CodePen, so it was just awesome to have you here, and I thought we'd grab you for the podcast and just talk about what some of that work was, just celebrate it a little bit, and wish you well before that move over to GitHub, which we could talk a little bit, too. Although, you haven't actually started yet, so it'll hard to know.
Klare: True. [Laughter]
Chris: It was almost four years ago, just speaking of four-year chunks, that we did this for Mr. Jake when he moved on. He left right as you were starting. He had one week of overlap, or something weird like that. Maybe not even.
Klare: Oh, it was more than that. It was a few months, I think.
Chris: Oh, okay. Yeah. Right on. It's just a tradition we have now, apparently. [Laughter]
Yeah, what's up? What do you think of as some of the big moments of work at CodePen?
Klare: Yeah, it was interesting. I was thinking back today of when I first started and the things that I was working on. Looking back and seeing what CodePen looked like when I first joined four years ago versus what it looks like now, and it's crazy just to think about the difference between the two because we have changed a lot.
We changed how the homepage, the entire logged-out homepage, changed. The logged-in homepage changed.
Chris: Mm-hmm.
Klare: We updated all the social feeds. It's now easier to access all your work and people are using what we previously called the dashboard much more frequently now.
Chris: Yeah! Those are some of the first ones I thought of too. The logged-out homepage is one thing because it's very present and a lot of people see it and all that. But it's kind of funny. Once you're a member, and for us who work on CodePen, I feel like we don't even see it that often.
Klare: Exactly. Once you're a member, you're not seeing that anymore. [Laughter]
Chris: Yeah, you're just in, and that's kind of just a choice we made. It's funny how other apps don't always do that. Even this app we're using to record this podcast, Riverside, or maybe this is one. But have you ever seen that where the base URL just is always the homepage, whether you're logged in or out? Then whatever the application is it's sometimes at app.application.com - or something - so you always can see what the homepage is, even if you're logged in. Anyway, I feel like it's a weird choice.
Klare: Yeah, but it makes sense because the things that you want, the information that you're wanting to know (as somebody who has already joined a site) is far, far different than the information you need to join, so it makes sense to me.
Chris: Yeah. Also, there's so little value there once you're logged in.
Klare: Mm-hmm.
Chris: Because we serve developers, if anybody wants to see that page, they know darn well how to make a new incognito window in two seconds.
Klare: Oh, yeah.
[Laughter]
Chris: But anyway, that was a big deal. The new homepage was big but, of course, the login homepage, we're all way more excited about.
We used to get -- I'm sure you remember -- constantly people were like, "It's impossible to get to my own work!" which we never hear ever anymore.
Klare: Exactly.
Chris: Nobody ever has that feedback anymore.
Klare: People just had no clue. They had no clue how to access their work. They just were like, "I was working on this thing and I don't know where it is anymore."
Chris: Yeah.
Klare: One of the big changes that we did was so small. It was a change of renaming dashboard to "Your Work."
Chris: Your Work. That's amazing!
Klare: It had such great impact.
Chris: It did.
Klare: It's one of the few cases of, okay, we can change this immediately, and the impact just far outweighs the amount of work that you put into it.
Chris: Yeah, totally. But of course, architecturally, there's always more work than you want it to be, you know, picking up an area of the site and moving it to somewhere else, because we're always rearchitecting things, yadda-yadda.
It's not like it's at odds, but I feel like that's pretty common is it almost slows down a design process. We can make those decisions, like, "Oh, we'll put it here." Then, of course, four months later, it ships. [Laughter] You wish we could move a little quicker, but we're not that slow. In our old age, we're a little slow.
Klare: It just kind of gives you the time to make sure that you're making the right decision, I think, and to anticipate how things are going and make sure that the things that we're working on are the right things instead of just deciding to do something and immediately doing it.
Chris: The logged-in homepage has that following, trending, and that's what you mean by social feeds. Those are all kind of new.
Klare: Yeah, exactly.
Chris: Were rethought, and they have new technology behind them. Think of what's involved there. There was a bunch of design work and then the way that it slides and preloads content is a whole other thing. The way that machine learning powers it is a whole other piece of technology. A lot of stuff has to come together to make these things happen.
Klare: Exactly.
Chris: It's a big deal when they get done.
Klare: Before we redid all of that, people were not using following. I was looking back at some of the research that I had done for that project. I had surveyed people on what sort of content they were looking for on CodePen. There were three options. One of the options was, "I like to follow people," and nobody chose that option, which is just crazy to think about.
Chris: Hmm.
Klare: Then I was looking at some of the data that Marie had pulled. The amount of people who follow other people and the following connections basically exploded overnight once we improved that feed. That also had giant impacts.
Chris: Yeah, it did. It did. Now it's my favorite. For real. I'm just one user of CodePen, but I have invested enough time in following people on CodePen and know how this feed works. There are pretty much just advantages to following people whose work you like. Feel free to smash that follow button. No need to keep those numbers low because you're just going to be rewarded with great work the more you do it, and it's great.
Also, that interesting people to follow thing is also powered by cool, secret, back-end technology that suggests other users. You're right. That's one of the most hockey sticky things at CodePen that's ever happened--
Klare: Right.
Chris: --is the rocket ship of people following each other, which is very satisfying.
Klare: The numbers just completely change, and it's just crazy to see.
Chris: Mm-hmm. To make this stuff happen, we aren't just like, "Oh, let's redesign the grid." It's almost like a composition of componentry that comes together to do this, too. There's a card, essentially, an item card and a collection card and a user card and all that stuff that we're all redesigned to come together in the grid. There are different kinds of grids and all that stuff. That's a design system, and you really are in charge of that.
In fact, sometimes it's a little -- especially because you never got that team of designers here at CodePen. You were kind of alone on team design a lot of times. It's not as obvious to everyone what it takes to make that stuff happen. You use Figma as a design tool, or at least that's just what we chose early on and so far so good, right?
We just had a meeting about it this week to make sure knowledge transfer stuff happens before you go. That design, it really is a system. All that stuff is expressed in Figma very eloquently as componentry in Figma. It's like you designed and essentially coded that to make it go. I don't know. I just felt like talking about that. That design work doesn't just happen.
Klare: That's true, and you have to be really intentional about that as well because you have to know what are the tradeoffs between investing into a system of components or a design system versus the work, the actual product work that you're going to be doing. There are tradeoffs that you have to make there.
Investing more into design infrastructure is going to take you away from the product stuff, especially the designer at CodePen. But investing in design infrastructure is also going to speed things up in some ways. There has to be some sort of tradeoff. I feel like the biggest lesson that I learned while at CodePen was understanding the opportunity cost of all the things that I had to work on.
Chris: Hmm. Yeah, everybody here has to face that battle a lot. There is a lot of, like, "If I work on this, then this is being sacrificed," kind of thing.
Klare: Right.
Chris: It comes up in a lot of conversations because it can tricky. I think we've gotten it wrong so many times in the past that it's brought us -- like every decision leads you to where you are today. How many long, drawn-out conversations have we had about perhaps some little feature that then it bears out that so few people ever use and it has hurt our technical debt, yadda-yadda? Yet, we don't have some other core feature that obviously people want. Which just means that you've squandered your opportunity cost - or whatever.
Klare: Right. A lot of times, you can feel that pull of, "Oh, I really want to work on this one feature because I feel like it's going to have a lot of impact," but without really knowing or understanding the numbers behind it, it's only going off your intuition.
I feel like we did make a lot of progress in the past four years as well in trying to research more, pull in more data. I did a bunch of qualitative interviews and user research.
Chris: Mm-hmm.
Klare: Marie has pulled in a bunch of quantitative data, and we've added way more testing to actually get those numbers so that we can make much more informed decisions instead of just going by our gut, too.
Chris: Right. Yeah, we've got dashboards. We've got click chart stuff.
We just did a podcast the other week with Shaw who put in this ability to make a fork in a new tab, which seems like the world's smallest little feature, and it kind of is. But in the past, we maybe would have just done it. But this time, we did it and are tracking it too because we are adults now and we make sure that the features that we work on have data associated with them, so we know if it matters or it doesn't. Yeah, pretty great.
You're leaving us behind a pretty robust system of design such that - I don't know - it's just like that's nice. That's a nice leave behind is something that's that codified. If somebody wanted to mock out some new page on CodePen, they couldn't possibly be in better hands with the system that's sitting there now. You can pretty much just drag around components to build anything.
Klare: Yeah. It feels good, too, to leave behind something. I feel pretty confident in the work that I am leaving behind that the future of CodePen is in a really good place. I feel really confident in that future, even without me.
Chris: Hmm. Nice. It was cool to see some of that componentry. There are long periods of sprinkling, like we redesigned modals or something.
Klare: Yeah.
Chris: It's like there's still--
Klare: That's true.
Chris: CodePen is in this long transition. Not drawn out. It's just the nature of it how some of CodePen was classically Ruby on Rails, and we've slowly started sprinkling React into the site. Then some areas were totally rewritten, and that work is literally still not done.
Klare: Mm-hmm.
Chris: There are still some areas, notably the Pen editor and stuff, which is such a big one that's still kind of a Rails rendered app. Do you think we have a plan for that? Yeah, we sure do. It's just that that's such a big one. It's one of the last to fall down.
Probably no surprise. I think we've mentioned it many times on the show. That editor is a huge target for us. It's been the result of a lot of work, most of which we just can't talk about yet. Not because we're trying to be squirrely, weird, or anything. I just don't want to set any expectations of this new editor without getting a little closer to knowing what the final product is going to be like.
But you've done a ton of work on that, and that involves a whole slew of componentry and such, too. That's pretty cool.
Klare: Yeah. Thinking about that, too, even when I first started, it was sort of intentional to go bit by bit through the site and improve instead of just improving all at once. I always think about--
I don't even know how many years ago. Probably like two decades ago when eBay changed their background from yellow to white, and if they did it immediately, all of their users freaked out about it, but they did it really gradually and nobody cared. [Laughter]
Chris: You mean like different areas of the site, or they slowly tinted the yellow down?
Klare: They slowly tinted it.
Chris: [Laughter]
Klare: It's not as extreme as that, or gradual as that, but I did want to make it intentional of improving different parts of the site as we went on instead of just doing one big improvement all at once.
Chris: Mm-hmm.
Klare: A lot of that is just you add improvements as you go along to familiarize users with the new things, all them to adapt, and then also just be able to reevaluate it as you go on. It's such a huge risk to release an entire redesign. Even if you do testing, you're not testing it against your whole user base, so it's a huge risk.
Chris: Settings was a big one.
Klare: Hmm.
Chris: Not only just the user settings of the site, but settings are so dense and complicated that there were a lot of patterns that were birthed in settings that then sprinkled around the rest of the site too. Then Pen settings are different but related and benefited from those patterns.
Klare: Right.
Chris: Any time you're changing inputs, select menus, radio buttons, and stuff, that was a bunch of work that was pretty satisfying to get out.
Klare: I feel like I redesigned Pen settings a few times. [Laughter]
Chris: Yeah. [Laughter] Yeah. Settings is just....
Klare: But it was really the global settings that really influenced Pen settings overall.
Chris: Yeah. Yeah, they're connected despite how different they are and stuff.
Klare: Mm-hmm.
Chris: It was cool. Remember even the sidebar of the entire website was a whole new journey that we went on.
Klare: Yeah.
Chris: That was pretty big. Then that -- okay, stuff on the left vibe was not just a trend in design but has just become that's just how apps work now - kind of. Every app has these controls on the left.
Klare: Yeah. I guess it differentiates just something that is much more website content, like a content-based website versus an app - I think.
Chris: Yeah. You're probably right. I'm just looking across my doc. It's like, "Well, Spotify, of course, it's like that. My Git client is like that. Notion is like that. Front, our email client, is like that."
Klare: Even Twitter is like that.
Chris: Yeah. [Laughter] Anyway, that's satisfying. Then we ended up using it more, so the whole site bar is like that. But then you go into settings, and it has a tabs on the left thing going on. That's what ended up in Pen settings too. Yeah, controls on the left. Yo, it's the way to go. Not dogmatically, but for something.
Klare: Yeah, I think it's important to have this overarching grasp on, I guess, how different parts of the site are designed and how that influences other parts.
Chris: Mm-hmm.
Klare: Because you can just go and redesign different components. But unless you have a graph over the whole thing and how it influences each other, then it's not going to be as cohesive.
Chris: Yeah. CodePen is a sprawling place, believe it or not. If you think it's simple, just work here for one week and we'll show you how not simple it is.
Klare: [Laughter]
Chris: [Laughter] We mentioned the new homepage was kind of in this. It's a little unique because the homepage at any site is just a one-off weird beast. It's hard to fit it into any system, but I guess conceptually it's closest to our landing pages, which that was a big job we did at one point. We had this idea to make sure that we could manage the content in more like a CMS rather than having to hand-code our landing pages. Overall, a pretty big success, I think.
We do them all in WordPress and its block editor and such, but then you put together a system for those pages that are like, "Here's the big header," and there are different kinds of headers. Then sometimes there's a row of cards. They follow a pretty traditional-ish landing page-like structure where there's lots of information on the page and it's full of calls to action and stuff. The homepage is a little bit in that category, but there are also ten landing pages of sorts that are education-specific or team specific or feature-specific.
Klare: Mm-hmm, just drawing on all of my days, my early days, working for agencies where I would do those types of websites over and over again. [Laughter]
Chris: Landing pages all day. That worked out pretty well for us, too, and we'll continue to make them and refine them as we need to talk about different things. But now we have a system - you know!
Klare: Exactly.
Chris: It's good to have that system. The Figma stuff really is a system. It's so advanced. I called them props yesterday. I don't even know what Figma is, but you have a zillion components in there. It's pretty much every component we have available on CodePen anyway. But when we work with them in the codebase, they're React components.
Klare: Mm-hmm.
Chris: They have props, and you send in variations and stuff like that. It's not like 1:1 in Figma. I don't think you had any desire to match what was happening in React, necessarily. You just invented variations for yourself such that if you used an icon or - I don't know - a button component, you can say icon on left or icon on right. Rather than having to drag that crap around, you got it ready, so you just do a little dropdown menu in Figma. It would just swap them for you.
Klare: Yeah, and I guess that speaks to also how the workflow of designing something in Figma is different than designing something in code. The ways that you might be approaching it might be slightly different, so you might want to make things more efficient in Figma in different ways.
Chris: Yeah. I have no desire to try to force those things to be the same. I don't think there's a lot of value there. I could see people having pressure to do that, to have, "Well, they're the same system, so they should have the same props and the same variations."
No, but one is serving the explorative nature of a designer and one of them is just how we express designs in code. They just don't have to be one-to-one.
Klare: Right.
Chris: That feels like a losing battle.
Klare: Yeah, and I definitely agree with that. There was one point where I thought, "Oh, this would be great if the single source of truth was the code, but it's exactly like you said. It should be exploratory. You should be able to break out of some patterns if you need to, and you should be able to have the freedom to explore new ideas and new concepts.
Chris: Yeah. It never seemed like you were too holy about whatever was happening in Figma anyway. It's not like you busted that out in meetings and was like, "Look at Figma!" or anything like that.
What actually matters is what goes into the code design system because that's what users actually see and interact with.
Klare: Yeah.
Chris: At the end of the day, that's what matters. We don't really have Storybook or anything. We never really invested. A couple of false starts on having a place where everybody puts the components. I don't know what we'd even call that. [Laughter] One of them we used early was the one from Clearleft. I can't even remember the name.
Klare: Fractal.
Chris: Yeah. Yeah, we tried Fractal, and we kind of set it up, but then nobody used it.
Klare: Yeah, and I think that's the point of having some sort of design system, too, is that it has to be referenced in places that people look. If it is just off on its own that nobody is using it and it's not being referenced, then it's just going to be forgotten about, especially if you don't have a team of people working on that and updating it.
Chris: Yeah, right. Yeah, it was kind of after the fact, and it just more like seemed like a good idea than really was. I don't know.
Klare: Yeah, and I feel like a lot of companies, too, they started off with their design systems not as a way to make things more consistent, but as a way to have public perception of their design teams be better. Most of their design systems were public as a way to bring in, I guess, more leadership into the overall design community there.
Chris: I think that's exactly right. Isn't that part of the discussion around design systems? If you can be public about it, it's like your way of telling, showcasing to the world, and new potential employees, "Look how seriously we take design here at Widget Corp."
Klare: Right. That percept has kind of shifted in the past few years, too, where design systems are becoming much more about being consistent and being useful, overall, and trying to tie into the overall design and product philosophy and lifecycles that companies go through instead of being a marketing tool for a design team.
I like the way that that's trending.
Chris: I was confused by it all along because I'm like, if you already did it then why do you need me. Now I get to just be the janitor for your already existing design system?
Klare: [Laughter]
Chris: Oh, what a cool job. I can't wait to do that. You know?
Klare: Some people love design infrastructure, but I am not one of those people. [Laughter]
Chris: [Laughter] The one we actually use is one Shaw put together. I don't even know how it works exactly, but it just loops over our folder of what we call library components and spits out these little examples of usage of each component. Nobody has to maintain it. There's no file really that represents usage of that component. I think he wrote it so if you want to put an example file in a component you can. That's a little opportunity to showcase variations of itself, but you don't have to. It's kind of neat because where he put it is in our admin app, which we use for all kinds of crap. So, locationally, it's in a spot that spins up with the rest of the dev environment.
I think that's kind of what you're trying to say, right? If there's some app that you have to spin up that you never look at, you're not going to be there. But because this is sitting alongside everything else in our app, we actually do kind of use it.
Klare: Exactly. It kind of speaks to--
That started off as reference. Then a lot of the stuff that I was doing also had textual documentation along with it so that when you combined those two things together, you have the reference of the component itself -- what should I use -- and then the documentation behind it -- why should I use this and when should I use this?
Chris: Right. There is some degree of that. You're big on documentation, period, kind of, I'd say. You helped us. That was a big part of the work that you did at CodePen was helping us organize our project management and team meeting structure, and all kinds of stuff like that. There's a little bit less of that straight-up design documentation in our Notion only because I don't know that we need it.
Klare: Right. A lot of that exists in Figma. Yeah, I feel like it's just the nature of where we're doing design, and where we're doing design after we talk about concepts is mostly in Figma or code.
Chris: Yeah. Yeah. It's different, people's personalities, in some way. I'm sure if there was robust design documentation in Notion, Dee would veraciously read it, probably.
Klare: [Laughter]
Chris: I probably wouldn't just because we have different personalities, I guess.
Klare: Right.
Chris: Yeah, but you know. I don't know how much it's worth getting into all the Notion stuff but, yeah, we really doubled down on organizing big projects through somewhat complex Kanbanning structure that you largely set up, so project management is certainly in your wheelhouse as well.
Klare: Yeah. I feel like that was a huge thing, too. It's not necessarily a common thing when you think about, "Oh, what are all the responsibilities of a designer?" and that ended up taking a lot of the time that I had, especially in the past few years.
Chris: Yeah. Yeah, maybe it isn't a design thing, but you're also a human being with a brain and fingers and can do more than just move rectangles around - or whatever. Sometimes those rectangles are Kanban cards.
Klare: Yeah, but I think I saw it as an organizational design challenge.
Chris: Mm-hmm.
Klare: It's like, "Oh, I can tell that we're struggling in this area. Okay, now I've identified the problem. How do I use design to fix this?"
Chris: Yeah, the problem was actual employees being like, "What's going on? What's next?"
Klare: Yeah.
Chris: "What's a priority?" and everybody at every level having that same question. And so, what now exists is if anybody -- you're almost not allowed to have that thought because you're like, "Well, then you didn't look at the Kanban, did you? Because it clearly spells that out," because the cards are there, and they're prioritized, and they're in the right slice. You're a part of one of those versions, and yadda-yadda. I think we pretty much solved that, much like we solved "Where is my work when I log in?" for users.
Klare: Yeah.
Chris: We solved the "What's happening right now at CodePen?" through organization, in a way.
Klare: Yeah.
Chris: That user testing stuff is all documented in Notion as well, which is nice. You let up a lot of that stuff, like, what is an interview like? What do we hope to get from it? How do we take notes on it? What's the structure like once we have somebody willing to participate in it? That kind of thing.
Klare: Yeah. I feel like that was definitely an important part about building new concepts that we just weren't very sure about. To get more information surrounding that and to actually talk to people who use CodePen was so important. I loved bringing in you and Dee in order to take notes and actually sit in on the process and hear those things first-hand.
Chris: Nice. What's next? We got to the point where you're leading up a staff. We didn't really have any reports, unfortunately, at CodePen. Is that going to change? It's designed more like a leadership role at GitHub, right?
Klare: I'll be a design manager at GitHub. I haven't started yet, so I don't have that much information. [Laughter] But I'll be leading up a small team.
Chris: Okay. You don't even know one what? I mean it could be a secret. I don't know. But sometimes you're like, I work on--
Klare: I mean I won't know for sure until I start, so--
Chris: Okay. They can tell you whatever. Sometimes, you hear people are like, "I worked on pull requests at GitHub," or something.
Klare: Right.
Chris: They tend to be really specific about what aspects they work on - for whatever reason.
Klare: Yeah, I have a rough idea, but I am not -- until I start, I am not entirely sure that it's set.
Chris: Yeah. I wonder what similarities. It's going to be for coders, so that will be similar.
Klare: Mm-hmm.
Chris: It's going to have a design system, so that's similar. I think it has some Ruby on Rails roots, so that'll be similar. The scale, meh, not so similar, let's say.
Klare: [Laughter]
Chris: A little different. [Laughter]
Klare: Yeah, probably.
Chris: The amount -- in all ways -- like how many people use it, what the processes are, I bet will be super different. I bet the Slack is a little busier.
[Laughter]
Klare: More people.
Chris: Something like thousands, probably.
Klare: Yeah. I think one of the interesting things, especially about the design team at GitHub, is that they are basically doubling in size right now.
Chris: Hmm.
Klare: They stayed the same size for many years and wanted to be small and scrappy. It just came to a point where they knew that they had to expand, and they had to envision what the structure of their design team was going to look like and how they had to hire for those positions. It's definitely an exciting time.
Chris: Yeah. Yeah. Well, congratulations. I hope it's awesome. I'm sure it will be. They famously have very good design and good taste and produce great products that the people of the world love, so you get to make your mark over there. It's very exciting. Congratulations.
Klare: Thanks.
Chris: Yeah. Right on. We'll say goodbye then. I have a few more days with Klare, but it'll probably be the last time on the podcast. Womp-womp. [Laughter] All right. See you later.
Klare: Bye.
[Radio channel adjustment]