July 31, 2019 | Day 3, Session 1
VP of Design Communication at InVision
He has a lot of experience with teams and helping those teams talk to o
Has anybody ever used a microscope? He remembers 8th grade biology class using a microscope. And what he remembers is it was a little bit frustrating because we had to look in the microscope at a specific thing and then draw it, but it was frustrating because the thing you’re looking at moves around and its easy to lose it because you have such a small view-port into that space.
Work is like that – his viewport is often pretty narrow and he can’t see everything going on in the organization and he can’t see the problems that he feels the symptom of but doesn’t know how to address it.
That makes him feel frustrated and disenfranchised in his work.
He felt that way when he was leading teams at Mailchimp. He knew there were things he could do better but he just didn’t know what.
He’s got kind of a weird role at InVision – his job is to look through a telescope at the big picture. He looks at a lot of teams at a lot of different kinds of companies to see what they’re doing and what leads to success.
The challenges he faced as a design leader weren’t specific to Mailchimp, turns out everybody had the same problems.
Turns out the grass is not greener anywhere. Nobody has it figured out.
There are common breakpoints they’ve found as they studied these teams, and there are certain things they’ve found we can use to move us forward to success, and certain common frustrations.
It often boils down to people stuff.
Mo’ people, Mo’ problems.
It’s all exponential! If we can’t talk well about our work, if we can’t talk well to other people about what we do it’s really hard to do good work and feel satisfied with what we’re doing.
Words are very important and the words we choose to talk about our work and talk to others about it are very important.
What he’s noticed is that as teams grow there’s a ton of investment in design teams – Google has 3600 designers now. IBM has 2200+… we’re seeing lots of big big design teams says a lot.
That’s why we need Design Ops – we’re getting bigger teams.
When we get bigger teams we’re getting more specifications. Everyone has a specific language around their work.
And then there are layers around that – like we have to talk to lots of different engineers.
So language starts to fragment and we’re experiencing day to day the tower of Babel. Collaboration is no longer possible when we don’t speak a common language.
language shapes our work and our work is part of our culture.
Language shapes the Culture. We feel it when the environment feels toxic.
Language Shapes Partnerships
Let’s find how to speak the language of good design. Here’s our point of departure for today. Let’s talk about:
How should we talk about our work more effectively?
He studied painting in design school and they’d always talk about ‘the work’ not ‘my work.’ So it’s objective not subjective.
Think about the visibility of your work. Do people see your work? Are they aware of the types of projects you’re working on?
When his team visits companies, it often looks something like big open offices with computers right next to each other, cool murals on the wall, etc. But all these people have their headphones on and trying to focus on their work…
A couple years ago he gave a talk at Stanford in the D school and it looked totally different – it looked a bit like chaos. There was stuff everywhere, all the furniture was on casters, there were movable boards everywhere covered in writing and post-it notes.
These spaces are so different.
Where we work today is super polished and it has a message.
“Consciously or not, we feel and internalize what the space feels us about how to work. When you walk into most offices, the space tells you that it’s meant for a group of people to work alone. ‘ Kelli
The people in the ‘normal office’ environment definitely don’t appear to be working together –
Communication flows best when the work is visible.
At the D School, the work was out in the open.
He works at a totally remote company, 900 employees around the world, so they don’t have a space they can do stuff like this. But they built tools to help with it.
When people see the work they can have awareness, share ideas, challenge each other, etc. It allows people avoid duplication, avoid chaos, and harness collaboration.
When design isn’t visible, it can’t be valued.
There’s a great book out of the Stanford D School called ‘Make Space’
How o Set the Stage for Creative Collaboration
Making work visible is important and part of that is design reviews.
These are the life blood of any design team – it’s where debate happens and there are a lot of pieces to this.
Bob Baxley – former Apple guy, “Forget everything else. Design reviews are teh heart of any high-functioning design team.”
If you’re going to start in one place and level up your communication and design team, this is where you do it.
One way you can make your design reviews better is think about who is included. Is it all designers? Are there engineers there? Are there executives? Product people? Marketing, sales? Experts you need to work with directly? Inviting the right people is crucial to get there right results. Don’t just invite designers.
Laura Martini, Google – “I often united influential people in the company to my team’s design reviews so our work remained visible.” Executives that were key to the success of the project were included in the design reviews. This was super scary for her often, but more often than not there was awareness, good conversation, good debate, and it was productive.
HOWEVER, limit attendees to 5-6 people to be productive. After that point it becomes less productive.
How To Run A Design Review:
Don’t just put work on the wall and say ‘what do you think?’
Start by having a facilitator. If you’re the designer, you’re not the facilitator. If the designer stands up and explains it, he or she robs everyone in the room of their fresh eyes. A facilitator helps guide people in a productive direction.
From Google Ventures :
When running a Design Review, Set the Stage:
1. Review business goals: “Thanks so much for coming to our design review. We’re here today because we’re trying to reach a specific goal (and list the business goal(s)).”
2. Review the customer’s goals (“we’ve talked to our customers and we found out some of the language we have has turned them off or confused them so we’re trying to address those”).
3. Review constraints – we’re just focusing on this one area because that fits into our time frame.
4. Review the schedule – we have to be pencils down on design so engineering has 2 weeks to complete that, then QA has a week and then we ship.
5. Set expectations on fidelity – “we’re excited to show you what we have but it’s a starting point, know that there are a lot of things that aren’t fleshed out.” Direct the feedback – “the feedback we’d like from you should tie back to these goals.”
How to GIVE feedback:
1. Be candid
2. Be specific
3. Tie everything back to the business goal(s)
4. Affirm what’s working
5. Try to discuss the problems before jumping into solutions, this makes it more productive than just jumping into solutions
6. Make suggestions, not mandates – if you’re a higher ranking think about how giving a directive is really what you want to do. Making suggestions and giving the designer the agency to make decisions for herself is key.
When he worked on a product design and he polished it like crazy, and then showed it to someone that involved in the project it hasn’t made for a good process.
Form our perspective when we take that much time to polish our product, we accidentally communicate to others ‘you’re not part of this process.’
If you show someone a sketch, it says ‘I’m still figuring this out’ and it creates an open space – more opportunity for partnership. The fidelity and polish of our work is key to when we choose to present that.
Geoff Teehan, Facebook – “In order for the design team to have a reputation and have good work, having them present their work is important but methinks it is important to feel comfortable showing work in progress because oftentimes in this industry we value the highly polished artifact and that’s great, but there should be room and we should have a comfort as a design industry to share some stuff that’s not quite though through even at some higher levels so they can have a part in helping shape it.” – paraphrased.
His team used to present highly polished presentations to high level folks and they decided to start showing stuff that was not polished, and execs became way more involved in conversation in the unpolished stuff. And the execs reported that was their favorite meeting all week because there was a space for them to talk and explore things and be part of the creative process.
When we do things, it makes sense to pause afterwards and review things that we did and see how we could do it better next time.
People that do this sort of thing tend to grow faster, and it’s a learning process together. It’s a way to learn from every success and failure and build into our process all the time.
Matt Spiel, Lyft – “ Retrospectives are a valuable tool to use because they help teams identify strengths and weaknesses. They help provide an opportunity to give feedback on our processes in order to grow and improve.”
Matt schedules a retrospective on a specific time and send out a survey to the team that worked on the project before the meeting and ask questions like:
- Rate the team’s performance on the project
- Rate individual performance (how did you do?)
- Open field questions like did we have enough time? were the goals clear along the way? did you get the stakeholder support and involvement along the way?
You’ll get a lot of helpful feedback from people. Then collating that to find patterns is useful.
Asking for this feedback ahead of time and it helps avoid groupthink bias.
He does this with a Google Form and then collates the results into a Google Doc and then shares it with everyone.
As part of Matt’s retro they go through a Start, stop, keep process.
Next time we want to Start doing this based on what we’ve learned. We want to Stop doing these because they didn’t work well. We want to Keep this process because it worked really well.
Then, the Google Doc that results in this Start Stop Keep process she shares with other people even outside of the team that worked on the project.
He sees a lot of designers end up on ‘agile islands’ and this is a language problem. There ends up being teams with 1 designer and 11 engineers. It’s a bit like being an expatriate, you’re a bit out of your element. In these islands, the focus is often too narrow
Paired Design approach:
Diogenes Brito, Slack – they have cross functional teams and agile teams. They have problems – they have designers that are frustrated because they’re the only designer on the team.
“ Here, the designers are assigned to groups and paired, so there’s always a lead designer but they’re always working with another designer who is also assigned to that project. It means that it gives the other designer to say ‘this is one of my real projects, I need to dedicate time to it,’ but also it helps avoid not being able to see the forest for the trees by being the primary designer on a project. The paired designer has some distance from it and understands the project and the team. It’s nice because there’s low friction to collaboration between two designers that both understand the project. The designer can turn around and say ‘hey what do you think about this’?”
There’s really just one designer on each project but there’s a buddy system so those designers aren’t alone and can schedule
This is easy because it’s not even lobbying for additional headcount or restructuring. It’s just an idea that can help you do your work better and build connectivity between teams in the company. It’s an easy hack to try and address the stranger in a strange land problem.
He found 8 people with Design Operations in their titles on LinkedIn about 9 months ago. It’s a lot more than that now.
This goes back to what he said at the beginning – all of this comes back to people problems. Generally when you hit 20 people, operations become very important.
His team worked with people like Dave Maloof, Meredith Black who is the former head of Design Ops at Pinterest, and Kate Battles from FitBit, and Colin Whitehead from Dropbox and published the first book on DeisgnOps: DesignOps Handbook
There is also a podcast
Design Operations as we learned yesterday is really a way for us to work more efficiently to address a lot of the entropy that happens in our teams. This happens at multiple levels. It may start where there’s a design operations head as a chief of staff, but there’s also something called a program manager assigned to a project and help push that through.
Josh Ulm, Wells Fargo – “I think it’s incredibly important to have an operation function as part of the design team. I’ve found that as design is figuring out its process it’s often trying to mesh that into the rest of the product dev process like engineering. And engineering has a process that manages the process of development. But often design doesn’t mesh with that process. What may take a sprint for engineering to develop may take 3 sprints. And so if design often relies on the development function to get the design process, it isn’t right. He’s learned to have a role that is responsible for coordinating this.
I want to make sure the designers are designing and not worried about is their computer working, do they know what they’re delivering, how do they communicate that and deliver it. Designer operators are responsible for all the things that makes design happen. One part is the human resources part of this, and the other part is the ‘how does design release its product to mesh into another process ie engineers.’ So then you have program managers tracking the delivery design and making sure that process matches the process of engineering and helping those come together.”
Collin Whitehead, Dropbox – he came up with this term to mean protecting a designer from things like ‘swoop & poop.’
Swoop & poop – it’s when you have a person of influence who comes in midway through a project without a lot of context and says ‘hey we should do this a totally different way and still deliver on the same timeline, good luck!’
Design Operations is a way that can avoid this.
“If a team knows when to expect feedback from specific people they can tailor the presentation of their work to reflect how it addresses things like revenue goals, product goals, etc. What’s more is a design producer can set expectations and explain to stakeholders what type of feedback is needed at each particular stage in the design process.” – Collin Whitehead
Operations helps us address pain-points.
Let’s look at THE ORGANIZATION
Most design teams that are successful know how to translate. It avoids things like ‘people don’t understand what I do, or I’m never involved in strategy.’ People can’t bring you into strategy if they don’t see that you understand how the business operates. So you have to have some business acumen so you can translate how design is influencing the business. If you can connect the dots to people, you’ll start to get invitations to those meetings, and people will start thinking about your work a different way.
Let’s talk about what the business is trying to achieve and how design helps us get there.
We can talk about Design debt – this is going to result in slower time to market! Execs like this!
We can talk about UX crashes – there’s a UX crash when people try to log in, when they try to reset their password they get a UX crash and they can’t reset it. We’ve gotta fix this today – execs get that!
We can talk about how UX crashes reduce retention.
We need to start listening very carefully to hear how our colleagues and other team members talk. We need to listen to goals being discussed by execs or people in charge.
We also need to think about how we measure our work.
HEART: a reference point – a starting stack of measurement.
We need to speak the language of business through numbers.
It’s easy to translate these measurements into business success. This thinking helps shape our work too and help us make informed decisions to help us with what we’re working on.
Think about what your business really cares about, listen to that,
Jehad Affoneh, VMWare – He was trying to get a design system off the ground and it fell off a cliff at one point, but then he brought it back and it happened. He basically got away from his desk and talked to a lot of people about the design system and made sure they knew what it was and that it was happening.
He learned that he’s not a design leader he’s a business leader. He has people reporting to him – he was an individual designer and now is head of design. His career growth is the fastest Aaron has seen in the industry. And it all came from this language translation.
“When people come to me to report their progress on a project I always ask, “Have you made stickers? Do executives know this project by name? If no, then your work isn’t done.”
It’s not enough to just do the work. We’re doing work in the context of a larger organization.
Getting multiple people involved in the process.
Design centricity in a company develops by inviting participation in design.
Scott Yim, Northwestern Mutual – “We did run into some obstacles particularly with the design sprint. You don’t have to be a designer to con tribute something valuable. Hey, bad ideas are not a think in this room, it’s a safe space, and the good ideas can come from anywhere. When we’re brainstorming, making sure that everyone knows that you have something valuable to offer, and that it’s not expected that you can hop into Sketch and then you have this extensive background ind design. It’s not necessary. It’s open, whether you can use words, sketch, draw boxes, get it on paper, and then there’s an opportunity to share that in a meeting. It works best when they’re able to get participation from all stakeholders and it takes more time sometimes that way but it’s worth it.
They’ve flow own to some financial offices across the countries, and getting them involved in a design sprint-esque kind of meeting or day has been extremely valuable to us.” – paraphrased
BOOK: Enterprise Design Sprints
Meetings can be called a design thinking workshop, or something that doesn’t smack of design to make others feel welcome.
Northwestern Mutual, Home Depot, Nationwide Insurance, CISCO – this workshopping idea is happening here, and it helps with design being infused in the rest of the organization.
Abigail Grey, Google – used to be Scott Yim’s boss at Northwestern. “Workshops are good for getting people’s buy-in and if they’re part of the process you’re also making use of that valuable knowledge that’s stuck in their heads which designers may not know.”
There are a lot of our colleagues who have strong understandings of the problems we’re trying to solve that we don’t have. Workshopping is a way of bringing that in. Then those other people understand that design is strategy! This is what starts to change hearts and minds.
In this process you are also to co-create a shared language and process around design.
This shared language is important for us to do our best work. It fuels a culture of feedback, where we get the feedback we need to do more informed work and create a better experience for our clients.
Ideally it’s supported by infrastructure that help us focus, avoid swoop & poop, and aligned with business.
Partnerships is the most important word.
This is where he screwed up in his career, when early in his career he said ‘me’ instead of ‘we.’
It was only through the school of hard knocks that he learned he doesn’t actually know anything and there are a lot of smart people who have perspectives that conflict with mine and I need to hear those things to broaden my understanding and to grow. And he only gets those perspectives when he actively builds partnerships and involves other people.
He hopes we can find ways to build partnerships and use language to do our best work.