Jehad Affoneh: going open source and building community

Featuring

Jehad Affoneh

Director of Design, VMWare

Jehad Affoneh is Director of Design at VMWare. He began his career in tech as a software engineer working on front-end development, and began taking leadership roles as he progressed in his career at VMWare. He currently leads VMWare’s User Experience team, and was one of the driving forces behind the creation of their design system, Clarity.

Eli: Jehad Affoneh, Director of Design at VMWare, welcome to Conversations on Designbetter.co.

Jehad: Thank you. Thanks for having me.

Eli: We’re excited to have you here. Let’s start off with your background. While doing my LinkedIn sleuthing, I noticed that your undergrad degree is actually in computer science. Maybe you can talk a little bit about your journey from that background into design

Jehad: I think I share that background with a lot of designers and developers who stumbled upon design and development as a means to doing something else. I started writing code early when I was a teenager as a way of sharing news. I created a news site, news community, and I learned as much as I needed to. My passion was actually journalism, and coding was my method of getting there. I started enjoying coding more than journalism, and I started enjoying designing websites and fumbling at the systems behind them more than just reporting the news.

The passion grew, so I studied computer science at the University of Washington. Go Huskies! The more I wrote code, and I did UI engineering for a while, the more I realized I actually enjoy solving the user experience problem more than anything else.

I shifted my focus got into design mainly through design systems. So, I started building a design system, Clarity, and from there, it snowballed into spending more and more time on design. That’s the quick version of the journey.

Eli: So although my background is in mechanical engineering and yours is computer science, we both share a base in engineering. My guess is that it has allowed us both to better empathize with our engineering counterparts. Maybe you could talk a little bit about that: What are some of the skills we, as designers, can cultivate that can help us better empathize with the challenges engineers face and also work with them more effectively?

Jehad: Having been an engineer—and in fact, I still write code, although I now do it in my free time versus for production—there are a few things I’ve noticed. One is that, the vast majority of the time, like designers, engineers are just trying to do the right thing for customers. We might disagree on what the right thing is, and we might disagree on how do we get to that right thing, but the reality is that we are all passionately trying to focus a solution for customers.

So to me, there are far more similarities between designers and developers than we usually talk about, and I think we can empathize with the challenges they face, empathize with the responsibilities they have, and empathize with, and keep in the back of our mind, that they’re trying to do the right thing for the customer. And when we disagree on how to do that, maybe we keep these things in mind and try to deliver a better message across the room.

The other thing I think will go a long way is building Clarity. Clarity is a team of designers and developers working together—no design team and development team—just a Clarity team. In my experience with this model, we’ve tried as much as possible for leads on both sides to share decisions. Responsibilities are clear: The design lead obviously makes the final design decision, and the development lead makes the final development decisions, but they have a say across the board. We had designers sitting in architectural meetings for development, and we had developers sitting in design meetings for designers.

The effect was that the responsibility was truly shared between functions. You would see developers arguing passionately for a technologically difficult solution because it was the right experience, and you had designers who might not get the full architecture but at least could say, “Does that really address the use case?” The conversation quickly became about, “How do you build the best design system versus my idea and your idea and this is hard or easy and anything else.”

So I think that the best thing I’ve seen, the best way of seeing to empathize, is to not just collaborate, but to pair.

Eli: That makes a lot of sense. Can you walk us through the story of how Clarity came to be and why it’s a public design system?

Jehad: Yeah, so we created Clarity when we were working on a different project, and we started standardizing some of the stuff within that single product. As the product grew, we started thinking about how we could share beyond that specific product, and we started talking about what used to be called Clear Design. As we started chatting more and more about Clear Design and talking to others, we realized there are similar problems elsewhere.

We pitched to the VP of UI and UX the idea that we needed to build a standard design system across the company. This was early in the design system craze. I know everyone has a design system now, but this was before that. I don’t know if we even called it a design system. I think he took a leap of faith on it. I honestly don’t think the vision was so clear that we thought it was going to succeed and we’d go open source and everything.

We created a team of developers and designers working together called Clarity. There was no mandate across the company to actually use it. So it was kind of this project on the side; we figured give it three to six months and see what happens. I think I promised that we would have products on it within six months or something like that, which definitely didn’t happen. But we started working on it, and we started selling it to the smaller teams within the company, teams who could make their own decisions basically. And it grew from there exponentially. It didn’t happen within six months, but it happened. Within 12 months, we had a few products on it. Within 24 months, we had most products on it, and within the last few months we’ve landed the last out of 100-plus VMware products on Clarity.

We interviewed Jehad at 2018's Design Leadership Camp in Kauai, and he shares some insights about how they created VMWare's Clarity design system.

I think one of the things that worked the best for us was that, because we didn’t have a mandate, it meant we needed to move fast. It kind of felt like a startup where we could lose funding at any point. So at any point, we were trying to make sure we had enough support, enough products on it, enough. So we drove it really fast from the beginning, and we had a working design system on month three or four. It had a few patterns, a couple components, but it was still kind of the basics of what would group look and feel together.

We decided to open source it about a year ago for a few reasons. First, when we started, we tried to find an open source component library to use, and we struggled to find one. Either they didn’t have a community around them or they weren’t strongly supported. They were very limited in the set of what they offered, or they were paid and they had an open source version that’s supposed to get you in the door and then upsell you. Contributing back to the community was the No. 1 goal because we felt like we use open source every single day.

Second, was we felt like there was a very limited amount of risk in sharing our system externally. If we believed in the community as No. 1 the risk and the disadvantages were very limited.

Open sourcing was probably the best thing we’ve done for the internal adoption of Clarity. There was a huge fanfare around it initially, and people started using it externally, equating issues, and people internally noticed. So, kind of that circle of “internal reinforces the external, the external reinforces internal” happened.

And then I think it just made working on Clarity a lot more fun, a lot more engaging, a lot more exciting. There’s a huge community. The team is every day excited to find new areas of investment and new conferences they want to go to. There’s a huge external community that supports it where everyone on the team feels very strongly about it.

Eli: That’s a great story about about how making it a public system really worked to your advantage. You wrote an article on Medium called “2018: The Year of Enterprise Design.” Now we’re about halfway through 2018. How is that stacking up? How are you feeling about that article at this point?

Jehad: At the end of last year, I started leading the VMware design team, and one of the first things we looked at as a team is the fact that if you use VMware software at work, it shouldn’t be crappy software or a crappy user experience.

We spend most of our waking hours at work. I probably care more about my work software working well versus Facebook working well. I spend half an hour on Facebook a day. I probably spend six to eight hours in work software. So if I’m a VMware customer, and I spend most of my day working with VMware software, that’s probably the one piece of software I want to work really well.

But “enterprise software” is kind of a bad word in design; the assumption is that it has a worse user experience. When you talk about enterprise versus consumer, there are a lot of deep discussions around the ideas that the problems are more complex or the expectations are different. Honestly, I think it’s crap. I don’t throw my expectations out the door when I sign my badge in. So we thought, “Okay, as VMware, what do we need to do?” And we came to three different core things we need to change for this be the year of enterprise design at VMware.

Number one was, we needed to build the best team we could. If you want to invest in building better products, you need to invest in people. This means hiring the best people, retaining the best people, making sure we have the best culture.

We’re working really hard internally on all aspects of what that means, and I think it’s one of the areas we’re excelling in. In three to six months, we’ve seen a huge amount of change in attitude within the company that I expected to take 24 months.

The second one was to build infrastructure for design. If you’re going to do great design and you have great people, you need to give them the right infrastructure to execute. That meant a few things. That meant we started investing in design opps. We started working on process.

And the last one, which kind of lumps a few things into it, was that we needed to elevate and extend design within VMware and VMware externally. So that meant improving our ratio of designers to developers, having conversations internally about what does it mean to have a design team, what design is, and how we elevate it. Just having the conversations has changed a lot.

Included in that is that we decided we need to be better members of the community. So traditionally, enterprise companies don’t think of community as much because the impact of community is long term. It’s hard to draw a line between engaging with the community and results; that takes years and years of building. We decided that if we really wanna build a culture for the team, community is really important to us. We truly care about design. We truly care about the design community. We’re all designers. We individually care. So we want to be part of the community.

Eli: So one last quick-fire question for you. Are there any books, blogs, podcasts or other resources that are helping you out either right now or in the past with your career?

Jehad: “Principles: Life and Work” by Ray Dalio was one of the books I read this year that I enjoyed. If there’s one thing I got out of it, it’s the idea of radical transparency—be 100 percent open unless it’s personal information about the team and stuff like that. So that stuck with me, and since then, I push further across the organization in both directions.

Another one is “It’s Your Ship: Management Techniques from the Best Damn Ship in the Navy.” One of my mistakes early on was that I thought that I could do it all on my own. This book drove home that you shouldn’t do it all on your own, even if you can … and you can’t. But also, this book discussed the idea that it’s your ship, this is your team, this is your company. We can’t complain privately about problems; you have to bring them up, and we have to solve them.

Eli: These are great. I haven’t read either, so they are now on my list as well. Thank you so much for taking the time to be with us. We really enjoyed having you in Conversations.

Jehad: Awesome. Thank you so much for having me. I enjoyed it too.

designbetter conversations

July 13, 2018