Scaling Design Through Collaboration Using Adobe XD with Elaine Chao | Adobe Creative Cloud


(light music) – So let me introduce myself. My name is Elaine Chao. I’m a Product Manager on Adobe XD. And I have been focusing on
the area of collaboration for the past two years. And it just so happens, I am also one of the original
team members on Adobe XD. It’s been quite a ride. And actually a fun fact, I was the first woman on the team as well. So yeah, I don’t know. It’s funny, I always
get applause for that. I don’t why. But we have a lot of women on the team now and it’s a fantastic place to work. So I am really active on social media. I know I pointed this out earlier but I also do a daily pro tip on Adobe XD. So if you’re interested in
learning more about the product, feel free to give me a follow. My DMs are also open. And so I really encourage
conversation afterwards. And so if you are interested
in having more of conversation about collaboration or
any kind of challenges that you’re hitting or if you
just wanna give me feedback, feel free to send me a DM. That’s actually the best
way to get a hold of me more actually than my own
email because this actually is a side channel that I reserve specifically for people who are interested in XD. So when I was tasked to
think about this topic, it was really just about
how designers work together. But really, the way that we
think about collaboration within a design environment
on Adobe XD is really about an ecosystem because there are a lot of different types of
relationships that a designer has. And this thinking is fueled by a ton of engagement and research. Now, I as a member of the
product team have the privilege of going out into the world. And we also have extensions
of our product team in our business development organization. And between our group and the business development organization, we have traveled all over the world, literally 1,000s of organizations, multiply that by however many
conversations that we’ve had and we’ve had a lot of
conversations about how teams work. So this information has all gone in to inform XD’s collaboration features and how we think about
collaboration in general. So that brings us into this
class, which is entitled how the open design leads to
better decisions and products. But really I think it should
be why collaboration is hard because this is a really tough problem. Chances are, you are here because you have hit some
collaboration challenges. And it was funny, I was looking at who signed up for the class. It doesn’t give me names, it just gives me titles and organizations. And I was surprised to find out that a lot of big name companies are represented here in this room. And there’s also a lot of people
who are in management on up type of roles, not just
individual contributors. So I was just trying
to figure out why is it that this particular
segment of MAX would come and sign up for this class. And I came to the
realization or the conclusion that it’s not that the
challenges don’t exist on this individual contributor level but they are more obvious and more painful the larger your scale. The larger your organization
is, the more painful this whole thing of collaboration is. So what I hope to share in this class in this next 55 minutes or so is some of the learnings
that we’ve had along the way in talking with these organizations. But more than that, I wanted to pull in
some academic research. I wanted to pull in research
from the business world to help us inform how our
organization should be run. And part of the reason
I decided to do this was because the academic world
really takes an outside view on an entire system. And so this kind of unbiased
view of organizations helps us to inform how we should
better structure ourselves and how we can harness
these best practices for our own benefit. So I’m gonna start out with a somewhat controversial statement, especially as someone who’s entire job is making a collaboration tool, which is that collaboration
is not about tools, all right. This talk isn’t gonna focus on Adobe XD until the very end. I’m gonna talk about XD a little bit for about five minutes or so. And the reason is that collaboration is
ultimately about people. It is a people problem. It is a human problem. And in their discussions around the world with all these organizations,
we discover that no matter what set of tools they use,
they could be using Adobe tools, they could be using
whatever else is out there and there’s a lot out there, the problems they are trying to solve are actually relatively universal. And ultimately, people are
trying to solve the problem of self organization and the
process of decision making, both of which can be very, very difficult. So as any other design
problem, ’cause most of us are designers in here, in order
to understand the solution, we have to think about the problem first. So I wanted to start out
with the fundamental reasons why people collaborate at all. Why do you bother? So I think especially from a
large organization perspective, the concept of scaling is
actually really important to think about. You start with one person. As your organization
grows, as your demands on your throughput as
you’re scaling up engineers or scaling your business,
you just add more people. You’re just like, oh, I’m
just gonna add more head count to increase your throughput. And the problem is that I
think all of us know this that scaling is nonlinear. There’s a certain amount of overhead that comes with adding more people. And this overhead only increases the larger your organization gets. So you build infrastructure to keep your organization working and to keep your front line team small. And this comes from
additional research as well where they’ve identified the
special number is less than 10. So in design work, the
real reason to scale is to accelerate the amount of output. I talked a little bit about engineers and about this whole production process, but also what happens if
you have more clients, if you’re in an agency setting and you just wanna add more clients because you wanna build your business? Hey, you wanna accelerate your work. So these are valid reasons to scale. Now, as you’re scaling, some of the things that you can do are parallelization. You’re gonna work on this work stream, this other person’s gonna
work on another work stream and they will never meet. They will never work on the same thing. So you can also dogpile. We’ve talked to some
organizations who do this. They are in such urgent, oh my goodness, we need to deliver this to the client that they have three designers
working on the work stream. They have people working
on different documents, bringing them back in, reserving a day so that all of that goes
into one deliverable for the client. And yes, I recognize the irony
of using a puddle of cats for a dogpile, but hey, thematic. But in design organizations,
I think we all see that there are significant challenges the larger your organization gets. And one of them that we come across is this concept of visual consistency. And we’ve talked about this in the design world as solutions. We talk about design systems a lot. But really what you’re trying
to do is design consistency. So you have for instance
in a single application or experience, you want
that entire experience to be consistent. And if you were like Adobe, we have a whole family of applications. And I’ve lost count of how
many exact apps we have, but as we have this
family of applications, how do you keep that consistent
across your entire brand? So you begin thinking
about design patterns and brand identity and colors and character styles, relative spacing. All of this stuff goes
into this whole thing of maintaining a consistent system. But it goes beyond that
where we’re beginning to get into things like
communication patterns. We’re talking about voice
and tone, consistent lingo, how do you speak to your
customer within your application, is there a location where all
of these messages come up, do you have it just on the bottom, do you have a little pop-up on the top, do you have a side car or a little column where all of your messages come in? So all of these things fit
into the kinds of problems that happen once you scale. And so entire teams spin up to support these consistency goals. Yesterday, we were talking about Spectrum, which is Adobe’s design system. And we actually have an
entire team that was built up to ensure design consistency
across Adobe’s products. So that’s one thing. We were just talking about scaling. But the second thing
that I wanted to get into is the concept of inspiration. So sometimes magic
happens in collaboration where it’s not just one person. But really when you have someone else who perceives the world slightly
differently than you do, you start to be able to have
a little bit of give and take. And we have this concept
in the design world of diversity of thought is
really popular right now where you’re talking
about gender diversity, cultural diversity,
socioeconomic diversity but also neurodiversity. But simply by providing
a second set of eyes that is not the same person
as the first set of eyes, you can ideate more deeply. So one such concept that
I’ve been integrating a lot into my life recently is
introduced through improv. Now, I’m not a great improv person but I’ve taken some public speaking stuff and this actually came up multiple times. One concept in improv if you
have been in improv itself is called yes-and, all right. So as you’re building a scene, if I say, today we are in Los Angeles and you say, no, actually today we are in New York, you don’t have a scene at all. You just have a conflict. And you have people who
have different ideas of what reality is. But if I say, today, we are in Los Angeles and you say, yes, and we’re at Adobe MAX, we begin to have a story. We’re building something together. So this brings us to a
concept that’s pair design. Last year, I was introduced
to a couple of designers who are interesting in
co-editing, which is the feature that was in beta that was
introduced yesterday in Adobe XD. And they were doing this
thing called pair design, which is a concept they were
introduced to at Pivotal Labs. And the way that they
worked this out was that there was one physical
machine, a hardware switch, two keyboards, two mice, one monitor. And one person would
design and the other person would actually actively watch. And so as a part of that,
they would offer suggestions, they would offer solutions
maybe but they could not, their keyboard mouse did nothing. And after that concept was finished, the artboard was finished, they would switch over
into the other person. And then that person would take
an artboard right next to it and they would design for a little while and switch roles. So that first person
would become the observer and the commentator. And this worked really
well for the ideation. And it was just fascinating to me as someone who is working on co-editing. So I’m just gonna let
these quotes pass on by. This is from Penske, which
is a big trucking company here in the US. And this actually gave
them the opportunity to begin to ideate on a much deeper level. So that is the second thing that we’re talking about collaboration. But we on XD think about a
broader sense of collaboration as well because as you are making things, there are more people
that you collaborate with. Great example of this are
developers and clients. These are two people
that you work very close or two groups of people that
you work very closely with in making a product or experience. You might have to hand something off, you might have to get something approved. And so as we were digging into what people were looking at in terms of
feature requests or whatever, but really what the fundamental need was when they were dealing with
these two different groups. It boiled down to two things. One of them is trust. They would say, we trust these groups but we wanna prevent accidents
or misunderstandings. So there was something in
there about that trust. Do we trust these groups of people? The second thing was context. We wanna make sure that
my client only sees what I give them access to. Do they really need to see
all of my ideation work before I give them something to sign off? Do my developers need to
see all of my scratch work before I hand something off to them? Giving them the context of
what they need to work on or what they need to review, that was really important to people. Also, whether or not
you wanted to comment. So the second one was control
and showing them that people were focused on exactly what they need and given opportunities to only have access to what they needed. So an example of this was
a subset of artboards, can you comment on this or not. I would like to control whether
or not someone can comment on my presentation because
if I’m making a presentation for my executive, I don’t
want my coworker to be able to comment on it and just talk
about some of the conflicts that we’ve been having. So there’s this concept
of context and control when sharing with fellow makers. So when I take a look at collaboration, this is a summary of what
we’ve just talked about. Collaboration’s for scaling,
we talked a little bit about inspiration and that pair design and then about the concept
of context and control when working with fellow makers. So that brings us to I think
the bulk of this conversation that we’re having about collaboration and that is the best practices. When I was looking at academic research, a lot of what I found was actually from business to business. But when I thought a little
bit more deeply about it, this business to business model actually applies really deeply
to design organizations. So what I’m gonna do is go
through three different articles. The first two are more
business to business and the last one’s much more pragmatic for design organizations. So as design leaders,
hopefully these are all really applicable to you and your teams. So Harvard business professor Gary Pisano and Professor of Leadership
of Technology, Politecnico in Milano, big word, Roberto
Verganti presented the concept of collaboration architecture
in their 2008 paper. By the way, as a side note, I’m planning to provide speaker notes
without the cat photos and so just expect an
email if you have signed up for this class with something to download. And so in their 2008
paper, Professor Pisano and Professor Verganti talked a little bit about collaboration
architecture as a concept. And I thought this was
interesting because fundamentally, what it describes is this intentionality. You have to be intentional
about setting the framework in which you collaborate. And that’s because we know humans. In an organizational vacuum, people are just gonna make stuff up. And when you have multiple
people making stuff up, that’s when chaos happens. Humans wanna make order out of chaos. And when people are
trying to organize things, without a mutual understanding
at the very beginning, you end up adding chaos
to your own product cycle. It increases that overhead. So they described two different spectrums of ways that you can organize things. I’m gonna go through these and
then show you a little chart at the end that helps you
visualize it a little bit more. So they described one spectrum
is open versus closed. All right, so an open system
is anyone can contribute in any time. So an example of this is open source. We talked about open systems, open source. Another type is where a community
might choose popularity. So for example a vanity t-shirt press or the type of jewelry
presses that you can go and someone designs it and they put it up on the site and then other
people can just buy it if they like the design. But and also a little bit
closer to home I think for those of us who are working
in corporations is maybe a design garage week where
you all sit down and you just do whatever you want
for two weeks to help us as a design organization and
just open it up to anyone. And at the end, you evaluate which ones you actually wanna integrate. So the key concept here is
that you have to be able to evaluate the proposal really cheaply and people have to be able
to participate very cheaply. So those the two things that
you need to keep in mind with an open framework. But most of us are in closed environments. Most of us work for companies. And so you actually get to
choose who you collaborate with because you hire them. And so they’re within the
doors of your corporation, they’re insiders only but
you’re making two implicit bets. So these two professors
said that one thing is that you have made the bet that
inside of your organization you have the knowledge domain to be able to make the decision and also that you have chosen
the right collaborators. Okay, we spend a lot of time hiring and we are very careful about that. That’s the difference
between open and closed. It’s an entire spectrum. So the other spectrum
that we’re talking about is hierarchical versus flat. And this is something that we are probably a lot more familiar with
working at companies in any kind of organization because this is a tension
that we are very used to. We have the tension between hierarchical
and flat organizations. So hierarchical is exactly
what it sounds like. It’s either an individual or
an entity that has final say or has the authority to make a decision. So the fundamental assumption
here is that person has enough context to be
able to make that decision. Example, if you have a
client, you have to assume that if the client is the
one that’s accepting it, they have the business
knowledge to be able to know whether or not
something’s applicable. So flat, on the other end,
it means that the decisions are either decentralized or
made jointly by collaborators. So in a business perspective,
this is more like we can share costs, we can share risks, the investment is shared
among the organizations. But it works best when
no single organization has enough resources
to do it on their own. Maybe they don’t have enough breadths of perspectives or capabilities. This is where this
partnership really works out. So that brings us to this chart that these two professors brought up. And the working model that
you have and basically, the way that the
organization’s work together or two designers work together or two design organizations work together are gonna depend on where you are, open or closed, hierarchical or flat. And when it comes down to it,
it’s who makes the decisions and who is ultimately responsible. So they do point out and I
do wanna give this caveat that none of them are inherently better. And this is partially
because in the late 2000s, open source, it’s the be all and end all, it’s gonna be the best thing ever! But sometimes there are disadvantages to these types of open groups. For instance, you can make
decisions a lot faster in a closed environment. Case in point, if you have two people or let’s say you have 30
people going out to lunch and you have 30 different opinions of where people wanna go to lunch. How do you make that negotiation so that you finally go
out to lunch before 3 PM? Versus maybe it’s one
person making a decision for all 30 people or two
people making a decision for all 30 people. These are the trade-offs that you get. 30 people making a decision
together, very painful. So another thing that
I’m gonna point out is that if you’re in a
hierarchical structure, the elite circle versus
down here on the flat thing, could describe operating models at different points of your organization. So for example, maybe you have
more of this consortium thing that’s lower right hand corner if you have peers on the front line level. So your front line designers
are working together, collaborating very deeply
on this flat level, your peers, to provide some
kind of outcome for your client or maybe outcome for a product
manager or a VP of some kind for approval and feedback. It could also describe
models at different times in your design cycle. So for instance, maybe an ideation in the early ideation
phase, you’re very flat. Everyone’s ideas are equal. But maybe closer to the end
of it, your product manager’s gonna make a decision or
someone is gonna make a decision about what is finally out produced. So no matter where you are in
the spectrum, the key point to remember here is setting
clarity of expectations. Just making sure that
those expectations are set, this is the phase that we’re
in, this is how we’re operating as an organization. Let’s do this together. So that’s the first article
that I was talking about. The second one is pretty interesting. It addresses about whether or not collaboration is actually the solution. We talked a lot about the model. So this professor at
both Berkeley and INSEAD, which is actually a
management MBA kind of thing, it’s an international organization. So Professor Hansen had a
pretty interesting article that was entitled, “When internal collaboration
is bad for your company.” And this was on Harvard Business Review. So it was a clickbaity
article because I read this and I’m like oh, when is it bad. And it really talked about,
it’s like a brief case study on how a Norwegian risk management firm and the British beef industry
was trying to collaborate on addressing the mad
cow scare in the mid ’90s and how that failed. And so Hansen came up with this formula, which I’m gonna put up to help you decide when to collaborate and
when to just do it yourself. Again, this is context
of business to business but I think it applies to our
design organizations as well. So he introduced a concept
of a collaboration premium or collaboration penalty. That stuff on the bottom right there. Basically net win or loss. Okay, and it’s a very simple thing. I’m gonna talk about all of these different lines right here. So the projected return is
how much are you getting, how much are you getting
from completing the project or the cash from a project. And then opportunity costs
is what is it gonna cost you in maybe parts or labor. And generally people
just stop right there. And they’re just like, okay, that is ROI. I had to ask like seven
years ago what that stood for but return on investment. Here’s my return on investment,
here’s how much I get minus the cost of that. But Hansen introduces one
other line right here, which is the collaboration cost. And that is a cost you incur in working across
organizational boundaries. So examples of this
include maybe more travel, maybe more overhead for
coordination, more meetings, negotiations over objectives. So it’s both time and money, and an entire organization spin up around this program
management, project management to handle these negotiations. I don’t know about you guys,
but I work obviously at Adobe, we’re an international company. Adobe XD is actually located in at least five different offices in four different time
zones across 12 time zones. The worse that we have is
probably 11 1/2 to 12 1/2 hours depending on daylight savings time. So now instead of ROI, we have
this thing at the very bottom where it’s collaboration
premium or penalty. And we now have a different
kind of bar there. So it’s not just what
you think is the cost but this additional overhead. So one of the caveats that I
wanna give, especially being as a person who works at a
large company is that sometimes there are intangible wins,
things that you can’t necessarily put money on that might
make this worth it, that might make a penalty worth it. So an example of this is,
hey, does this set you up for a future win by building
relationships across teams or does it change the culture
of a partner organization so that further engagements
with them aren’t as painful? So these are non tangible wins
that could be very helpful for you down the line. So another thing to talk about is does it give you
downstream cost savings ’cause this is very
contained within a project. But one of the things that
we’ve been talking about a lot is the cost of design systems. And I know that this is a
very hot topic right now in the design world, design systems. And the number one question
that I get about design systems from people are, so
how do you get started? My management will not give
me the time or the resources to do what Adobe did which
is to spin up an entire team. Spectrum, I don’t know how
many people, seven to 12 people or so at Adobe who are
focused on design systems. And there are people who
come up to me and say, “Hey, we are working at
like 1,000 miles a minute, “we have client deliverables “and I don’t have headcount for this. “How do you start?” So this is really what it comes down to. Are you gonna have
downstream cost savings? So while this model
right here, this formula doesn’t hold up completely,
it’s a fascinating thing to think about, fascinating
trade-off to think about, especially when you’re thinking long term. And hopefully this will help
you decide whether or not to invest in collaboration. So that is a second article. And that brings me I think
to the third article, which is a very recent article. The last two were written a decade ago. This one was written this month,
all right, it was released this month also in the
Harvard Business Review. And this was a professor
at Harvard, Francesca Gino and the article is called “Cracking the Code of
Sustained Collaboration”. Again, I will write all of this out and you will have access,
not necessarily access to the periodical but at
least know where it is. Now, this article really
describes the attitudes of successful collaboration
and dug into the ways that creative collaborators work together, which I thought was very
applicable to design organizations. They’re really focused on Pixar
as one of the organizations that works on creative collaboration. As you guys know, Pixar is a
very successful film studio with Disney. And the key concept that she highlights at the very beginning is that all six of these
attitudes can be taught and inculcated into your
design organization. So I’m just gonna go over these six. It’s gonna take a little
while, but I think these will be very useful because
you can begin to bring this into your design organizations. So the first concept is
listening and not talking. So Professor Gino broke this down in to some additional concepts, which I’m just gonna breeze through. One of them was asking expansive questions like an open-ended like
what or how question, which prompts people to give
a little bit more information, also it helps them to feel heard and reflect on their situations. So instead of problem solving
’cause I think a lot of us are, oh hey, I have this problem
and you’re like, oh well, this is how you fix it, A, B, C and D. You go directly into
this problem solving mode instead of helping the
other person to be able to maybe come up with their own solution which might not be the same as yours. And that begins to have a conversation. So for instance, hey,
can you talk me through what happens if a user does X? And this is something
that I’ve personally used in design reviews and design
crits just to help them to further think about
some of these edge cases that they might not have considered that. So the second was focusing
on the speaker, not yourself because it’s very easy to be like, oh hey, I have this
problem and you’re like, oh yeah, well, I have this problem, too. And oh man, I felt so awful about this. And you just keep on rambling and it makes it all about yourself and not about the other person who might want to just
process a little bit. So the third one was,
okay, you’ve been through this whole a reflecting
on a person, et cetera but helping to teach people
how to engage in self checks. If you have a poor habit in
communication to be able to stop and say, oh wait, I did that wrong. And then to reframe things
or maybe restate things or just practice self
reflection like am I improving, am I getting better on this? And in terms of being
intentional about changing to more of a listener, less of a talker. And the fourth one, which I think at least
I’m guilty of this a lot is just can you be
comfortable with silence and teaching that silence is okay ’cause some people like myself I like to process a little
bit before I say something. And so how do you encourage that internal processing as well? And so teaching an organization
to be okay with silence. Those of us who are nervous
talkers will probably try to fill that silence with
whatever is on our heads and dominate a conversation. So that’s the first thing, the second one is teaching how empathy works
within the design organization or within a creative context. So it frames every statement
that your collaborator is talking with you under this thought that every person involved has
good intent, is intelligent and is fully invested. Now, speaking as someone who
collaborates across geos, across organizations and
actually outside of XD, I will fully confess that
at times, I have thought the opposite of one of these
about one of my partners. You’re just like, oh my goodness, I can’t believe you suggested that. Oh, what a dumb idea. Or oh my goodness, I can’t
believe you suggested that. Are you even on my side? So those are the things that cross my mind when I’m frustrated and I don’t hold these
three things in my head. So once again, every person
has good intent, every person is intelligent and every
person is fully invested in a solution. So a second practice that she
suggested in this whole area is being able to reframe without adding your own opinion to it. And so teaching the skill of summarizing what someone is saying
without skewing it in any way. And so this opens up an
opportunity for the other person to begin sharing more in-depth
about their own thinking. Another practice is trying to clarify the speaker’s state of mind. So if someone is sharing something and they sound a little bit
hesitant, you could say, hey, I noticed that you might
be a little bit hesitant about this statement. Can you point out some
of the pros and cons? Help me to explore your thinking. And this actually begins to surface some of that maybe internal conflict
that they might be having and help them to express a little bit more so you understand where
they’re coming from. And hold onto that thought because it’s gonna be important later. So the third element
in her recommendations is getting people
comfortable with feedback. And all of us have been in design crits and for those of you who
have been in art school, I hear that it’s particularly
brutal where people… You have design professors
who are just telling you that your stuff is crap. But we in our design organizations can have more healthy
patterns of behavior. And so this is a big part of it, getting people comfortable with feedback. And so I know that I am
also one of these people where it’s like people can
often feel that feedback is attacking, maybe confrontational. She gives a lot of suggestions here. I’m only going to do three of them. One of them is to talk very frankly about this feedback avoidance. And I will fully say I’m
avoidant personality. So feedback avoidance is a
thing and just recognizing that it is a thing and talking
about how we might be able to frame feedback whether
it’s in the design crit or even as a management type of situation where you’re managing someone and helping them to be more successful. We as people who give feedback
as well as receive feedback, we have this tension in here
because we want to improve but at the same time we want
to be accepted for who we are. So how does feedback fit
within this whole thing? So the way that we give
feedback is important in this process. And so she describes how
do you give feedback. For those of you who have been
through management practice or management training, this
is probably very familiar. It’s give feedback that’s direct, it’s specific and it’s actionable. And the reason she mentions
this is that apparently in the world a lot of
feedback that is given is very general. Just like, oh well, you should just give better presentations. Well, how? And so as someone who might
be an individual contributor just like, I don’t know. You say it looks sketchy,
how do I fix sketchy? And so being able to
give very direct feedback about those types of things
helps an individual to grow but it also helps your collaboration because it no longer becomes
about your thinking is weird and more about, hey, you know I’ve noticed that our user research has pointed out that this call to action
shouldn’t be at the top. Maybe we should bring it on the bottom or give them feedback like that. So another possibility that she surfaces is giving feedback on feedback. And I think I have
definitely received feedback and criticism that I have not
been able to handle very well, especially from a creative side. And when it came down to it, years later, I was able to boil it
down to, you know what? That was not stated in a
way that I could handle it. But I’ve also received feedback
from people who are very, very good at giving feedback that helped me feel like
they were on my side and that they had my
best interest in mind. And so in talking to someone
who gives me feedback, I can tell them that and say, hey, right now, it’s not framed in a way that I can really handle. I want to feel that you’re on my side and what kinds of things
can I do to improve? So this is a frank
conversation that you can have with someone who is receiving
feedback about what ways you can actually receive the feedback best and be able to action on it. So this next one, teaching
people to lead and follow I found was fascinating. The example that she gave was
about the Thai soccer team that was trapped in the cave last year. I don’t know if you guys
remember this particular one. She brought in a description
of what happened. I’m gonna read the list of
people that were involved. Hydraulic engineers,
geologists, divers, SEAL teams, NASA experts, doctors
and local politicians. And how they all came together
to rescue the soccer team. And what I found really
fascinating was that they were only successful
because each one of them was only able to flex between
leading and following. No one group out of that
that I read out right there was fully in charge. And in fact, this meant
that they were open to ideas from maybe more nonstandard people. So there was an inexperienced
engineer who suggested a path that led to a solution
that kept the kids alive by diverting rainwater. And it was because it’s
an inexperienced engineer, didn’t know any better. He was just like, why don’t we do this? They’re like, that might
actually work and it did. So teaching people how to lead
and follow, teaching people to lead in their expertise but
also to follow in their areas of inexpertise to be able to grow but also so that the projects can succeed. So that brings about the fifth
one, speaking with clarity and avoiding abstractions. I think this was very linked
to what I was talking about before when it was like give
direct and actionable feedback. If you create a culture
in which this is the way that you communicate
becomes much less personal. I find that when I’m giving
feedback to my fellow PMs or designers, developers, et cetera, if it becomes more
specifically about the problem that we have to solve together, it changes the tenor of the conversation. All of the sudden, we
are on the same side. And that’s because I’m
speaking with clarity and avoiding this, oh well, this stinks. Oh man, I can’t believe
this is poor quality. Oh, I can’t believe what happened here. Those are generalizations but
if I can point to something very specific where it’s
just like, hey, we’re getting a lot of these errors, these
specific type of errors, can we talk about a way
that we can address this? That becomes a problem
that we can all dogpile on. So that brings us to the sixth point. And I think this is the
most important point, and actually they’re
all fully interrelated. What you wanna do is to train people to have win-win conversations
because it’s not a, I don’t know if you guys have
read Deborah Tannen’s work, she’s a social linguist and I’m totally deviating
from the script right now. But she talks about one
up, one down conversations where it’s like, oh,
in order for me to win, I’m gonna push you down. Instead of conversations that say, hey, we have
something to do together. I remember one of my
early career conversations where we had hit a point
where our project team was in really, really big trouble. And our product manager sat down and said, “Okay, what are
we gonna do to solve this?” And afterwards our project
manager was like, you know what? I really respected what he did. And what he did, which
is very subtly said, what are we going to do to solve this? And just by framing it that
way, we all of the sudden aligned from people who are
all trying to kill each other to people who are all trying to solve the same problem together. And so I think in having
win-win conversations, another thing that she mentions
is have we fully explored what everyone wants out
of this interaction. Do we know what the other person wants in this maybe tense negotiation? She gave this really interesting
study that someone had done about two people
negotiating over an orange. And one person had the goal
of getting the orange rind or the zest and the other
person needed the juice from the orange but you couldn’t say what your eventual goal
was, you just came in and you had an orange
between the two of you. And so it was studying the
role of negotiation in here. And the people who are the
most successful were the ones who actually talked about what
their fundamental goal was. So you found it’s like,
oh well, first I can juice the orange and then I can get
the zest, so we can both win. As opposed to, well,
maybe we divide the orange and so everyone kind of gets
it, it sounds like it’s even but no one really wins. So training people to have
these win-win conversations is another part of collaboration. So I’m just gonna put this up
so that you can take a photo. Again, I will post this
out to you but I know that summarizing all of that in
one slide was important. I do wanna emphasize that
all six of these attitudes can be taught and all six of
these attitudes can be included in your design organizations
and all six of these attitudes can be worked on. And it’s not something that
people will adopt immediately. It’s something that you
will need to grow into. All right, are we good? Are we? Good, okay. So we’ve talked about
these three main concepts when it comes to best practices. And so that leads me to
my last little segment, which is where does technology fit in? And as a member of the Adobe
XD team, specifically focusing on collaboration, we’ve
done a lot of thinking about these original
problems that we identified and how we as technology
help this process along. So let’s talk a little bit about scaling. All right, so we’ve
talked about the process that design organizations have scaled because we have more
deliverables, et cetera, but we have problems with that. So one of them is design systems. So we have been investing in
design systems on Adobe XD. We started out by being
able to copy components from one document to another. Now we have linked assets
where you can actually bring an entire asset
panel, all of your colors, character styles, et
cetera, and your components into another document and
have one source for that. This is just the beginning of
our design systems road map. And I do wanna say that
what we have right now is not what we’re gonna end up with. We do have monthly releases. This is something that we’re
investing very deeply in. So the second thing that
we were talking about is this concept of ideation and dogpiling and parallelization, how do people work together. And as I mentioned earlier,
we have introduced a new beta of co-editing where two people or more can be working on the
document at the same time. So you can imagine that
in a world maybe even a remote world, you could be
doing the same pair design that Penske was doing. Or in a world where you have
to dogpile on something, you don’t have to reserve that last day to integrate five different files into one final deliverable. You can actually just be working on this maybe around the clock if
you have distributed teams to be able to deliver
something at the very end. So just this one
technology I think opens up a whole lot of ways of working. So when we talk about context
and control, we’re talking about developers and
stakeholders, project managers, those types of roles. We have a couple of areas as well. One of them is called design specs. And design specs which is in
the new share tab under share for development gives you a
view into all of your screens, so you can do all of your
interactive prototyping so that the developer understands
this is how things move from one place to another. But also to be able to get
colors, character styles, measurements in a format
that they understand that they can copy directly
from and they don’t have to wade through 50 different
screens just to get the five that they really need for
that particular feature. So this is very powerful. We also have these shared
prototypes, which is also a share for review under the share
menu, sorry, the new share mode. And there are lots of
different options in here because there are lots of different ways that people wanna share for review. Some of them, they want
comments on, some of them, you might want hot spots on or
off if you’re doing testing. So these are all different
configurable controls. We have some presets in there
and then you can use custom to be able to configure exactly
what you want, password, invite only, those types of things. But this is a continuing conversation. This is not where we are ending. If you’re using Adobe XD right now, you know that we release every month. And we are constantly in the
community talking with people trying to figure out what the problems are that we wanna solve. Now, I do wanna talk a little
bit about the relationship between technology and
process because we’ve noticed as an industry things like
Slack and video conference have really transformed
the way that we work, but also they were originally
built because of a problem. And so there is this whole thing of just there’s an ecosystem I think. There’s the cycle of tools
informing the way that we work and the way that we work informing the way that the tools work. And so it’s this push and
pull, which is why we need to continue in talking with people. So part of the way that we
do this is in conversations with you and we’ve visited
all over the place, we have community events
that we talk with people on social media all the time. My DM as I mentioned is open. All the way up to our senior
director of product management, we have both of them on social
media listening to people, reading people’s feeds. I’m thinking between our
product management team, we cover every single tweet that has the word Adobe XD in it, but we also have this, a
system called User Voice. So if you haven’t heard of
User Voice, User Voice is a way that we’ve as a system
that we put together to take user feedback, a feature feedback whether it’s on something
that we’ve already released or something that you really
wish were in the product, go ahead and stick in User Voice. My only caveat because
I am one of those people who looks at User Voice all the time, is to please insert one feature per ticket ’cause sometimes we get
these things where it’s like here’s an entire essay with
20 different feature requests. I’m like, I don’t know what to do with it ’cause part of the power
of User Voice is being able to combine them together
so that we can get a sense of what the design
industry is looking for. So that brings us to a point where we’re about 20 minutes out. I do wanna mention survey,
please fill that out. It actually helps me as a speaker as well as Adobe as a whole to be able to manage
content in future MAXs. So your feedback is really important, again, not only for me but
also for future content. I did mention I will email out, so if you have actually signed
up to be a part of this class as opposed to walking in, you should get an email
from me I’m hoping tomorrow with something for you to download. Of course I downloaded
all of these cat photos off of the internet and so I
can’t put them in something that I can send out to
you, but all the content should be available in
these downloadable notes. And once again, my DMs are
open, please contact me. Which leads us to the last 20 minutes. I wanna make sure that
you have an opportunity to ask questions of me
or maybe surface anything that sparked as a part of this class. Do we have a mic in the room
or should I just repeat? I’ll just repeat questions. All right, so any questions? Yes, sir. (participant commenting) (laughs) Yeah, so the question has to
do with naming conventions and saving document
conventions, so basically ways of working together because
these are types of things that if you’re working quickly,
no one names their layers, but naming layers is one of those things that helps to communicate what
the purpose of an object is. And so the question was
in this kind of ecosystem where no one can agree,
what’s a best practice? And my answer for you is I don’t have one. (laughs) Part of the reason I say that
is because naming conventions like many other things are
very personal and they are very specific to the lingo
of a particular organization. So I think that ultimately it is something that a team has to come
together and agree upon. And I also know that
designers are particular and they’re just like, well,
I don’t think that way. And so the question is
can you find something that people can conform to or if not, how do you deal with it? And I think that those are our challenges that I think every
design organization has. If you’re working on the same
thing, how do you make sure that that same thing is tenable? So yeah, so I don’t have a good answer. All right, any other questions? Yeah, over here in front. (participant commenting) Yeah, so the question,
I’m gonna repeat this for the recording, has to do
with how do you align goals from different people with
different opinions maybe even from different roles and how
do we handle this at Adobe. Is that a good summary, okay. And this is something that
I feel is kind of an art in terms of I will say that on Adobe XD, I don’t think we have as
much conflict about that because we as an organization
are very user centered. And so when you pivot to focus
on the customer, you begin to have a very different
perspective about things. The arguments that you have
are very, very different. It’s not like, oh, I think this is better. It’s more of a, okay, if
we think this is better for the customer, can we
get more data to ensure that this is better for the customer. Or if it’s like we gotta do this this way because we’ve run out of time and we just need to implement something, those are different forcing functions. One of the things that we do
do is to focus a lot on data and whether that is hard data that we get or it’s experiential data
that we get through research. We also have a research arm
of our design organization that goes ahead and one
of our primary researchers that we work with most closely
has a PhD in anthropology. And so for her, it’s a lot more like, okay, let’s look at this systemically, let’s look at it culturally
and what are the problems that you’re truly trying to solve. And so once you’ve aligned on those, I think the conversation
shifts a little bit. Definitely because we work on software, there’s always a push-pull. There is a, hey, this is optimal. And then, hey, this is
what we can accomplish. And so knowing what we do, we’re also a very PM and
design-led organization, and so that becomes a negotiation as well. So let me give a caveat on that. We are a PM, design and engineering. We often work as a triad. And so those conversations happen I think on a smaller scale. Yeah, I think hopefully
that answers your question. Yeah, it just reframes it a
little bit and it takes a lot of the ego and personality
out of it because the more that everyone understands
the problem and the more that everyone understands the user’s need, it puts some more focus
on the actual problem. Yeah, so just to summarize,
it changes the conversation when you all have the same rough goal. One thing that was surfaced
a couple of days ago in our US Leader Summit,
I asked a question, how many people have engineers
along on usability studies ’cause we were talking
about some of the conflicts that people were having with engineering and development organizations. And that was something that we do on XD. I don’t know if you’ve been
to our booth, but we actually have a lot of engineers
and developers at our booth in the Community Pavilion and that’s partially to
give us that experience. When I was, my background’s
actually as a developer and I worked on XD as a
developer for two years. I remember when we have repeat grid and we have a usability
lab in San Francisco. And we had three of us
developers in the back and someone was using repeat grid and just trying to figure it out. And it’s not fully soundproof, it’s only partially soundproof and so it was like (grumbling). And so when developers, not only designers and product managers,
but when developers have that visceral sense of we
want the customer to succeed, something isn’t working, we
need to solve this together, it changes that entire conversation because they’ve had that experience and because they have
this pride in their work. Okay, in the middle here. (participant commenting) Yeah, so the conversation has to do with how many people is too
many people in collaboration. The study that I read that was
probably the most influential to me, there are actually
two different things. One of them was a study
that I read that said that over 10 people, you
start to get loafers. You start to get people
who hang onto everyone else and so you start getting dominating, people who are dominating
the conversation, people who are really quiet. So that’s one thing to note. The second thing is that
in the Agile training that I’ve had before, that
special number is even lower. It’s like seven to eight where
it’s like when you get larger than that, then you begin
to have controlled chaos. I have found that we’ve definitely broken the seven to eight
prescribed model at Adobe. Sometimes it’s worked
and sometimes it hasn’t. On Adobe XD product
management, we actually at our last off site, we
had 20 people in the room and not everyone was there. And so how does that begin to break up? We’ve actually broken our
product management team and thus our engineering teams in some way to align around themes. And so those themes work together
and then we come together as a larger group to share ideas and to give feedback, et cetera. But ultimately a smaller group
is driving each initiative and those are less than seven, the groups are less than seven. So I would recommend just
based on the research and the teaching and just
practical experience, once you get past about seven to 10, the group dynamic starts
fracturing a little bit. My magic number in a
lot of group discussions has been eight. So if you get more than eight people, if you get less than eight people, then everyone has an opportunity
and feels safe enough to talk, especially those
who might be a little bit more hesitant to speak
and you can invite them, make space for them in a
group of less than eight. If you get to 15 in a room, then you definitely have one
person lecturing to another or three people having a
conversation over others, unless you’re very intentional about it. Okay, in the back there. (participant commenting) That’s a really good question. The question is on these six,
so I’m just gonna back up over here in to these six over here. Which do I feel are more
important for remote teams versus co-located teams. You know when I was
looking at this article, one of the things that was
emphasized was that all six of them are interrelated
and there’s no one thing that is more important than the other. It’s just like these are
six characteristics of teams that work very well together. I find in remote teams because
we do have certain teams and one of my teams is very remote, actually both of my
teams are fairly remote, and spread between people
who are local and remote. That relationship is really
important and relationship is really key to the way
that we work together. And so as I’m thinking about what is it about these six things that is important. And fundamentally, I
think it’s recognizing that people are actual humans
and that the conversations and the problems that
we’re solving together are made more special because
there are other humans with different perspectives
and different capabilities, complementary capabilities. And so coming in with a
sense of humility and a sense of really a hunger for
everyone to contribute to the best of their
ability and recognizing that we built this team
to be complementary is most important. I think it’s less about
time zone and location, sometimes culture does play a part in it. We try to have an in-person
meeting among our team at least twice a year,
sometimes once a quarter. I have two developers who
are based out of Texas who will come in twice a year. And that face time just
sharing a meal together, having a casual conversation goes a really long way in
humanizing the other person, so they’re not just a head
on a video conference. But then you can begin to
have real conversations and begin to really
solve problems together. So I know that that was a
non-answer to your question. Hopefully, it’s more of a guideline of where I see these six
things, these attitudes really having the
foundation of relationship. Okay, in the back here. (participant commenting) Yeah, so the question has
to do with design feedback and how do you make it actionable,
especially in the context of too many cooks in the kitchen. And we actually hit this as well because we almost have a
one-to-one relationship between our product managers
and designers, which means that we have a whole
lot of designers working on XD at the same time. The way that we handle it
is that we have design crits that are much more based
on those smaller pods that I was talking about,
the smaller initiatives. And so you have a group of five designers who are coming together and
actually revving on things, coming up with ideas, giving feedback. And then the feature
owner that the person, that the designer is working with generally weighs in as well. And so there’s a one-on-one presentation where that feature owner has
an opportunity to give feedback that is much more actionable
based on what they know about the industry, et cetera. And then once it’s in a more
final situation that’s I’d say it’s less crit and more
socialization with a larger design, the larger design and PM organization. So those tend to be weekly and
it’s more of a sign off kind of thing, it’s generally
been socialized beforehand. But I think it tends to
control some of the chaos that happens when you have
a lot of people in the room. It also helps that we’re not a
completely flat organization. Sometimes that hierarchy works
for us where it’s like, okay, it hasn’t made it out of your
smaller design organization, your design pod in some way, so that we’re all comfortable with it. Now when you surface it to
some of our senior directors, maybe the feedback that they
have is much more directional, if that makes sense and much less about specific interactions. It also helps in general that
we have a very well understood design system and design
paradigms, interaction paradigms. And so a lot of our
conversations have to do more with workflow and less
about specific interactions. Okay, I have two minutes left,
so I have one more question. Yes, actually, how about in the front? (participant commenting) Yeah, so that’s a really great question. It has to do with design
education and what would work best in terms of preparing designers
and maybe after the class out in the hallway, those
of you who have opinions can go and speak to our
design educator in the room and give your opinions. I think it’s a both-and, and having my background
primarily as a developer before product management, but working with designers all the time is that the experience
of working in a group in that parallel perspective,
everyone’s a peer is important for learning
just like social skills. And learning how to negotiate
through some of the things that we’re talking about
over here like leading and following, like do you
have win-win interactions. These are the types of things
that I think work very well in these peer environments. But I do also know that in
certain university programs that I’m familiar with,
they have specific classes that are more like let’s
build you like a startup. Where you have someone
from the business major and someone from the design
major and a couple of engineers coming together to
pitch a problem together and then your roles are very well defined. And so you have someone who is practicing the project management and
the product management. You have someone who is, you have people who are working together
to actually make this into reality or someone who is testing. And so these types of classes
I think are really important to work out how these
different roles work together in a very structured environment. But I don’t think any
one should be exclusive because we all, I think
we’ve all been in situations, where you had to flex. We were talking about
leading and following. People who are most
successful are able to flex from leader to follower. And so having that opportunity
to practice those skills in different capacities
I think is important. So with that, we’re gonna finish. I will be here for another
five minutes and then out in the hallway because I get
kicked out for the next class. So yeah, thank you very much for coming. Don’t forget to fill out
the survey, thank you. (class applauding) (light music)

Leave a Reply

Your email address will not be published. Required fields are marked *