Engineering A Design Culture

Yvonne So at UXDX Europe. Video: https://youtu.be/Rp-wZ8pxHew

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

The perceived dichotomy between engineers and designers

[00:00:00] I'm Yvonne, I work at Intuit. If you don't know who Intuit is, we make QuickBooks, Mint and TurboTax. We have a pretty strong presence in the US, so in the UK we have an office, in France we have an office, and I think that's about it for the European market. But yeah, so that's what we do at Intuit. I'm a designer and I am here to talk about engineering a design culture.

[00:00:26] I work at a company where it's about eight thousand plus employees, and for designers, at the time there were about 80 designers, now we have 250 designers worldwide, and then we also have a ton of engineers that we work with. So over the years I have been working at Intuit, on the teams that I've been working on, I've been working with a lot of engineers and a lot of different designers.

[00:00:50] So I wanted to firstly tell you that this entire talk is essentially a case study around the teams that I was working on, particularly this team that I was working on. We had about 30 engineers and about six designers, so in my world that's a pretty scrappy team as opposed to the massive company that I work at. And in this team we wanted to talk about really understanding how can the engineers teach us designers, what kind of best practices that they've had that they can teach designers, and then leading your team on the path to happiness based on what we learned.

[00:01:38] So firstly, in this team there was this perceived dichotomy. What we have seen so far in this team that I was working on was, again, there are plenty of engineers I was working with and plenty of designers, but the engineers I'm working with are generally more happy, they're generally more collaborative, they're more actively engaged, they're motivated to solve problems, and productivity seemed really high. Designers on the other hand, the tortured souls that we are, we were pretty stressed out and losing hair. We were pretty much disengaged. There's a lot of passion for design, but there wasn't a lot for the projects that we were working on, and we were also constantly under deadline. So that was a feeling that I was getting from the team that I was working on.

[00:02:29] So I just asked a question: why? Why was this the case? And so I essentially sent out a survey to my team and I had just asked, what's going on? And also I was just talking to the team members on the team, and I learned a lot also from the engineers that I was working with.

What designers said, and what engineers said

[00:02:49] What I learned from the designers is they felt that they have to typically work with a lot of different stakeholders. So that includes business strategists, other designers, other developers, leadership, lots of storytelling to their PM counterparts, to marketers, the data scientists and whatnot. And so to them they just felt, we have to actually collaborate with a lot more people than an engineer might have to collaborate with.

[00:03:18] Designers also felt that we have a lot of deliverables, so we end up having to deliver to our stakeholders conceptual mock-ups, storyboards, personas. All you designers in the crowd, you know what I'm talking about, right, where we have to deliver tons of different types of things, not just a particular piece of code.

[00:03:45] And what I learned from my engineering counterparts is, we at the team worked in agile operations, in agile mode. And so for the engineers, they had mentioned to me, well, we operate agile as a mindset, we operate with specific processes in place, we operate with experimentation and collaboration over deliverables. And so when they talked about the scrum process that they worked in, and the scrum process that I would actually be embedded in, I felt that there are varying processes between the scrum process versus the design process.

[00:04:26] So for instance, for the research and discovery phase in design, that might take two weeks, a month, possibly six months depending on the project, to really research and understand the customers and understand the business goals and values. Versus in a scrum process it's typically more into the iteration, so everything works in sprints, you have iteration after iteration and making sure things are launching after every iteration.

[00:04:59] So I had learned from my designer counterparts they often felt that in an agile development or an agile environment they often become, they're in a constant state of hustle and grind. So imagine you're in an agile setup [?], a designer working in a scrum team, and you're embedded in a scrum team, you attend their daily stand-ups, you attend all their respectives and whatnot, and you just constantly feel like you're in a hustle and grind because you constantly have to deliver for that specific iteration or that specific sprint.

[00:05:36] Designers often felt like they craved more time to think and to create and research and strategize, and they also felt that every release that comes from the iteration just could be better, because as designers we always feel like we want to create great design, we want to create what's best for our customers and our users.

[00:05:59] So after I sent that survey, talked to my customers, talked to my designers, talked to my engineers, I really tried to understand the pain points here in terms of why there was such a dichotomy between the engagement of my engineering counterparts and my design counterparts. And I just really tried to understand, well, what can we learn from our engineering counterparts who were really engaged? What can we do? And so I decided, could we take some of their agile principles or some of the engineering best practices and pour that over into the design world? What would that look like?

Challenge one: individual craft, and partner designing

[00:06:43] So this first challenge that I noticed was that designers were really focused on individual craft, which is really great for designers, it looks great for your portfolio, looks great for designers. And what's interesting here is that when I was learning from my engineering counterparts, I realized there's this principle that they follow around what they call paired programming. And pair programming is two programmers who work together at a single computer focusing on writing quality software code.

[00:07:16] And so I thought, well, they already promoted this culture of quality, so could we do this in the design world? So I tried to make sure we had some sort of partner designing in place, where I paired an interaction and a visual designer, or an art director and a copywriter, or any kind of discipline where I thought there were maybe some different strengths together. I partnered them and somewhat forced them to work together and helped them to clearly identify their roles and their goals and making sure they knew exactly what to do for that particular project, to promote this culture of quality.

[00:08:03] Some examples of partner designing that we've implemented was just ideating on options with not just a designer but perhaps our customer success partners. It could also be partner designing based on just analysis of our competitors. You can also be partner designing not just in the software space, in the digital space, but really into the physical space, which is, we created a particular flag [?] here for one of our field days.

Challenge two: designing in a vacuum, and peer reviews

[00:08:31] Our next challenge was that designers were designing in a vacuum. This meant that designers were kind of working on their own individual projects and making sure that they're delivering the best for their particular team or their scrum team or their project. And as I mentioned, I work in a really large company, and at the time we had 80 designers, we now have 250 designers. So what does this look like when you're designing for a scrum team, but you also want to design so that the rest of the company also knows what you're designing for?

[00:09:08] So here I learned from my engineering counterparts that they often do code reviews. The main purpose of code reviews is to keep code quality and readability high. So I thought, okay, well they do code reviews, what can designers do? So we implemented peer reviews. So we have an op mech where every morning around 9:30 a.m. we have a peer review session for about 30 minutes, and essentially it's just a way for any designers to just sign up for feedback and say, hey, I'm working on this particular piece, I need some feedback around this particular button, help me out. So it's a great way to give and receive feedback, it's a system of checks and balances, you can align on brand and illustration guides and patterns. Just a great way to receive peer review, to create that culture of accountability.

[00:10:09] Some examples of the peer review sessions: we were reviewing iterations, so you could be reviewing the same particular design and really reviewing the iteration in that particular design. You can also be reviewing ideas of solutions in a not so refined form. You can also be reviewing the fit and finish, like to the pixels. So there are multiple ways you could do a peer review. Any kind of idea can show up in a peer review and peers can review the ideas that you are presenting.

Challenge three: shared files, and source file control

[00:10:47] This next one is that designers feel productivity is low when files and projects are shared. So what that means is designers felt, well, if I have to share my file that I worked on with my blood, sweat and tears with someone else who sits in Brazil, the designer there who is going to be working off the same file, that person's not going to know what I was working on. Or if I have to go pull that file, I'm not going to know what that person is working on. It's just really hard and it just seems productivity just drops whenever I have to share files.

[00:11:21] Now a lot of this has been solved by tools like Figma and Mural and a lot of the tools that are used by designers. But it still just feels like, oh yeah, every time I have to share, I have to do a lot of knowledge sharing and whatnot, and so it just seemed really unproductive whenever I have to share a file.

[00:11:46] So I learned from my engineering counterparts that everyone works on the same code base, and I learned this terminology around paying down technical debt, and that it just helps us be more agile. You need to pay down the technical debt, and it really means that if new features needed to be tacked on, the assets will accumulate and whatnot. So I thought, for the engineering partners they had this thing called refactoring, which engineers out there, I think you know what refactoring is of course, but it really is restructuring and cleaning up an existing body of code without altering the structure or changing the functionality.

[00:12:40] So I thought, okay, what is this like in the design world? Maybe you can try some source file control and revisit some of our source files and clean them up before we hand it off to another designer to work on, and really help accelerate the work versus becoming blockers. So revisiting source files, making sure layers are adequately and logically named, getting rid of unnecessary metadata. So it's a great way for creating that culture of efficiency and making sure we can accelerate the work versus becoming a blocker.

[00:13:16] Some examples of source file control, what I mean here is, here are just a couple of examples of the files that I've received from other designers where they would clearly indicate to me which were the explorations that we had reviewed particularly for this date. They clearly named the layers that I was looking at. This right one here is a Figma file where I really understood, oh, this is exactly the cell that we were reviewing, and they clearly named all the titles and all the artboards that we were going to be presenting.

Challenge four: no op mech for regular communication, and the design sync

[00:13:49] Next challenge was there was no op mech in place for open and regular communication. I felt like we were communicating as designers, we were definitely talking about our passions and our projects, but there was not really a clear sense of understanding how we could communicate, not just about our projects in general but around how we can connect to the entire ecosystem of our products.

[00:14:23] So I learned from my engineering counterparts, and because I was also embedded into their scrum teams, I learned that we, me as part of their team, would be part of a daily stand-up. At every workday at a specified time the team meets for a daily stand-up. I think I was at a talk earlier this morning and he had asked, how many of you guys do daily standup, and I think almost all of you raised your hand, so which is great. But at the same time it's like, well, how many of you do a daily stand-up with designers that you work with?

[00:14:58] So I learned from my engineering counterparts that we do a daily stand-up with our scrum teams, but for our design teams, I think that we should do a stand-up as well. Maybe not so much in a daily fashion, because we can't be just talking about the same button color for five days, but maybe we could have some sort of design sync where we could talk about our projects and really understand how we could collaborate and make sure that we are all on the same page on the projects that connect our ecosystem of products.

[00:15:36] So a design sync, a regularly scheduled stand-up, so everyone has visibility into each other's work streams. We can easily share out our statuses, we can have feedback, we can have quick sketch sessions, ideation sessions, brainstorming sessions. We could have these all in our design syncs.

[00:15:56] Some examples of what we've done so far in our design syncs: we document deadlines and progress. So oftentimes in the design sync I will show, okay, great, here's what we've done so far this past week, what should we be doing this next week, really making sure that we are holding ourselves accountable and understanding how we could move on for the next week. We share out our status updates, similar to our engineering stand-ups. We can also do deep dives in our design syncs where we can deep dive holistically into one particular project, again connecting to the ecosystem of products and making sure that we are all aligned into our work streams and our projects and our deadlines, and making sure that we know what to do next for the following months, for the following year. So I think this is a great way to continue to get designers in sync with each other on our projects.

Challenge five: designers don't know what other designers are doing, and show and tells

[00:16:53] Sixth, designers don't know what other designers are working on. And again, this is, you work in a really large company, lots of people, lots of projects, lots of things that connect the ecosystem. So I work on the product QuickBooks and there are a couple of different business units within QuickBooks. We have payments, invoicing, we have accountant, we have payroll, and we have consumer tax and whatnot. And so oftentimes, I work in the payroll product, oftentimes I wouldn't know what's going on in the consumer tax world, and so that's kind of hard. I just don't know what's happening in that world.

[00:17:41] So I asked my engineering counterparts. They typically kind of know what's happening in the other realm, because either it's the same shared codebase, or either it's that they're talking to their other designers or the other engineers. But there seems to be this great culture of transparency with my engineering counterparts, and I think that's because they often do sprint demos. So every time after a sprint there's always a sprint demo, there's always a feature demo, and there's always some sort of demo in terms of just trying to keep stakeholders and executives up to speed with their progress and their development.

[00:18:19] And so I thought, well, as designers we don't really have a feature demo or sprint demo. I mean, we're part of that scrum team, but we don't typically have some sort of demo specifically within our design teams. So I thought, well, what if we can just continue to do show-and-tell, we can have op mechs in place for show and tells. And really a show-and-tell is just to visually show our prototypes, our demos, our visions, our intended functionality and features. And really this helps allow our leaders and stakeholders to understand what we've been up to, so that they can continue to gain insight and also avoid duplication of work.

[00:19:03] Some examples of show and tell is really just showing, we can demo the prototype or the product and the feature that we've been working on and showcase the innovation and the work in progress, or we could share vision and provocations and the what-ifs of what we want to have for the future vision.

Challenge six: non-stop hustle, and the design retrospective

[00:19:23] This last challenge is that the designers are feeling like they're constantly in a mode of non-stop hustle and grind. And what this means is that designers felt, I've got to deliver for this scrum team, I also got this other scrum team that's looking for the same feature, I also have to deliver for this MIS [?] and I have to deliver for this leader, I had to do a storyboard for this. It just seems like so many different deliverables for so many different types of things. They constantly feel like they constantly have to deliver and there's just non-stop hustle and grind, and they just want to stop. That's basically some of the feedback I've gotten there from designers, they're like, I just want some time to just think and think about what's next, or just stop, really.

[00:20:14] And so I thought, all right, well, my engineering counterparts, every sprint they have a sprint retrospective. Right after every sprint they go through a retrospective, they always talk about the improvements and the thoughts around, okay, what happened in this last sprint, what can we do to improve for our next sprint. And I thought that was really great, just being embedded in the scrum team, to understand, wow, we are reflecting upon this previous sprint so that we can continue for our next sprint.

[00:20:50] How do we do this in the design world? Because designers don't really talk to each other about reflections around what happened in the past and what we can improve to do better. They're just constantly feeling like, man, I've got to deliver for this next thing and I'm on a deadline here. So for designers I really tried to figure out a way where we can create an op mech for reflection, and really, could we create some kind of design retrospective, create some kind of op mech around retrospection, just trying to think of new ways to improve and really think about the accomplishments that we've done for the year.

[00:21:26] So I implemented a quarterly design retrospective. So through the year we basically had four different major retrospectives, where I included our cross-functional partners. So I included our PM partners as well, our engineering partners and our data scientists that we were working with. Really understanding, okay, from a design perspective, from a holistic visioning and ideation perspective, what could we do better, what have we done in the past, what have we done that's been great for this past year that we can be really, really proud about.

[00:22:04] And then the next one is really just not just thinking about the past, we're really thinking about the future, and understanding what are my hopes and fears for this next project that we're about to embark on, or this next semester, school year, this next quarter. And really understanding how can we improve upon ourselves, and really reflecting upon, man, I did a lot this past quarter or this past year and we should be really proud about that.

[00:22:31] This next one is really encouraging the team to write down our thoughts. I think I was listening to a talk earlier about the importance of writing and understanding how to reflect upon the work that you've done, and also just the way you design. So maybe reflect upon the process that went on within your design processes and understanding what have you done in the past year that will help improve you for this next project or this next role. So I encourage my design team to really write down our thoughts, and we also have a Medium magazine, I guess is what they call it, where we could submit and post within our Intuit magazine.

The outcomes

[00:23:16] So all this happened within the year. I actually sent out another survey at the end of the year, and as part of my design retrospective, as part of my reflection, I tried to understand, okay, well, what happened, what's the engagement like now versus from one year ago, what do you think has changed, what are some of the outcomes now.

[00:23:44] So the NPS score was plus three points, which was, okay, that's pretty solid. So we figured, okay, there was some improved collaboration, there's more increased in-person communication, there was more willingness to give feedback and help others within our design circle, there's more sharing of files without complaints, there were more shared goals, there's increased engagement, there were daily lunches happening, more ad hoc one-on-ones, sketch fests are happening every time during lunch or post-lunch. And just more talking, more increased collaboration and engagement.

[00:24:28] There's also boosted productivity. There's more cleaned up files, so again, I was showing the files that I was getting from my other designers. We were aligning to roadmaps and reducing duplication of work as well.

[00:24:42] Our culture and morale also visibly improved. So these are just some examples of some pictures I had taken around, someone had started a post-it icon type thing, and then this was actually in a different building, that kind of influenced the other building across to start a post-it board kind of thing. And it was really fun and really exciting to see, because this didn't happen before, and I've been at Intuit for almost seven years and this is like one of the first times I had seen that.

[00:25:20] We also had potlucks, we had a Thanksgiving box, you know, what are you thankful for, just encouraging more people to be more engaged with their teams and design counterparts, and really showcasing our designers, showcasing the passion that we have not just for software development and for making products and services, but really just the passion around design and design thinking and art and typography and colors, and just the whole reason why we got into design in the first place.

Recap and what next

[00:25:56] This next one is just a recap of the from and to. So again, just to recap what we've done. From how it was, we were all focused on individual craft, we tried to port over some engineering principles to the design world, and then we were able to promote a culture of quality, accountability, efficiency, regular communication, transparency and reflection. And really, again, this all comes with design retrospectives, doing more show and tells, creating a design stand-up or design sync, creating more source file control and peer reviews, as well as partner designing. Getting people more engaged with each other and making sure that we are collectively part of our ecosystem of products, versus the scrum team that we're working with.

[00:27:01] So what next? I hope that you've learned some of the six challenges and principles that we can take from taking the engineering principles and porting them over to the design world, and see if that can apply to your team. And I would encourage you to start today so that you can be surprised tomorrow. Just really minor tweaks and some op mechs in your current processes can really make a huge difference in understanding how we can collaborate better for the future.

[00:27:28] I'd also say that I learned to just stick with it. So oftentimes I got a lot of complaints from my design counterparts or engineering counterparts that's like, oh, do we really need another meeting? And I thought to myself, man, I should probably just give up because nobody really wants another meeting or another op mech. But it definitely pays off in the end.

[00:27:51] And then the last thing I learned was that anyone can sow culture. Culture can be created from scratch, it can also be influenced, and you don't have to be somebody from organizational, somebody who specialized in organizational change, you don't have to be a leader, you don't have to be anybody special. You can be on a team and you can influence that culture, and you be you. So the question I asked, really, to end this talk, is what will you bring to your own teams and how will you influence your culture? Thank you very much.