Effective Collaboration Between Designers and Engineers

00:38:31
https://www.youtube.com/watch?v=M5VQNPfyi1w

Resumo

TLDRThe talk emphasizes the importance of collaboration between design and engineering teams, particularly at Slack. Key challenges include the disconnects that often occur due to miscommunication and differing priorities. Four main strategies are outlined to improve this collaboration: building strong relationships between teams, involving engineers early in the design process, conducting parallel explorations of technical and design concepts, and effectively communicating design specifications. By employing these strategies, teams can enhance their workflows, produce higher-quality products, and foster a collaborative culture that bridges the gap between design and engineering.

Conclusรตes

  • ๐Ÿค Build strong relationships between design and engineering.
  • ๐Ÿ•’ Involve engineers early in the design process for better alignment.
  • ๐Ÿ“Š Conduct parallel explorations to speed up the discovery phase.
  • ๐Ÿ“ Create a shared language for design specifications instead of exact pixel measures.
  • ๐Ÿ” Identify which parts of the design are critical to discuss and finalize.
  • โœจ Design sprints can help in getting everyone aligned early on.
  • ๐ŸŽจ Look for engineering advocates who can support and refine design ideas.
  • ๐Ÿ”„ Regularly check in with team members to foster ongoing communication.
  • ๐Ÿ“– Collaborate on documentation to ensure both designers and engineers are aligned.
  • ๐Ÿ‘€ Keep track of design changes and their impacts on engineering work.

Linha do tempo

  • 00:00:00 - 00:05:00

    The speakers discuss the importance of collaboration between design and engineering, highlighting common challenges faced during the process. Tina Chen introduces herself as a Product Manager at Slack, emphasizing the platform team's unique responsibilities in managing apps and integrations. They aim to address how both design and engineering can effectively communicate and streamline their workflows.

  • 00:05:00 - 00:10:00

    Tina lists the main challenges in collaboration, including designs not being feasible, miscommunication in specifications, late identification of edge cases, and insufficient polish on final releases. She invites the audience to relate their experiences with these common issues, emphasizing the need for better strategies to overcome such challenges.

  • 00:10:00 - 00:15:00

    Tina proposes four strategies to enhance collaboration: 1) Building strong relationships between design and engineering teams, which aids in communication and understanding workflow dynamics; 2) Bringing engineering into the design process early, allowing for shared context and feedback; 3) Conducting parallel explorations for design and technical feasibility; and 4) Effectively communicating design specifications and ensuring consistent documentation practices.

  • 00:15:00 - 00:20:00

    The discussion on building strong relationships focuses on team structure, reduced overhead communication, and establishing a clear workflow and rhythm. By creating smaller, stable teams, members can focus on building robust partnerships through regular check-ins and open discussions about project progress and designs.

  • 00:20:00 - 00:25:00

    Tina emphasizes the importance of early inclusion of engineers in the design process. This strategy benefits both parties by avoiding potential misunderstandings and making alignment easier. Early involvement allows engineers to share technical concerns that can affect design decisions and overall project feasibility.

  • 00:25:00 - 00:30:00

    Parallel design and technical explorations are introduced as a way to streamline the development process. By allowing both teams to work simultaneously on various aspects of the project, they can accelerate decision-making and product development, ultimately resulting in quicker iterations and updates based on real-time feedback.

  • 00:30:00 - 00:38:31

    Lastly, the communication of design specifications should be focused on building a shared language and understanding of components rather than rigid specifications. Collaborative documentation across design and engineering establishes a unified approach, fostering better maintenance and implementation of design systems, thus addressing the challenges faced earlier.

Mostrar mais

Mapa mental

Vรญdeo de perguntas e respostas

  • What are the common challenges in design and engineering collaboration?

    Common challenges include feasibility issues post-design approval, miscommunication on specifications, edge cases impacting final designs, and inadequate polish in final releases.

  • What is the first strategy for improving collaboration?

    The first strategy is to build strong relationships between design and engineering teams.

  • How does bringing engineering in early benefit the design process?

    It allows for shared understanding of the problem and can highlight potential technical challenges early on.

  • What does parallel design and technical exploration mean?

    It refers to designers and engineers exploring solutions simultaneously, which speeds up the problem-solving process.

  • What is emphasized in communicating design specs?

    The focus should be on creating a shared language and understanding rather than just providing exact measurements and details.

  • Who should designers look for within the engineering team to aid their processes?

    Designers should find their engineering advocates who are willing to collaborate and support design decisions.

Ver mais resumos de vรญdeos

Obtenha acesso instantรขneo a resumos gratuitos de vรญdeos do YouTube com tecnologia de IA!
Legendas
en
Rolagem automรกtica:
  • 00:00:09
    um so we're here to talk about building
  • 00:00:12
    together how to collaborate between
  • 00:00:15
    design and engineering and the benefits
  • 00:00:17
    of that and how some specific strategies
  • 00:00:20
    for how you can do that your teams
  • 00:00:22
    so like Julie mentioned I'm Tina Chen
  • 00:00:25
    I'm a produce I'm manager at slack on
  • 00:00:27
    the platform team and the platform team
  • 00:00:29
    is responsible for all of the apps and
  • 00:00:33
    integrations that you see in slack so
  • 00:00:35
    that means everything that end user sees
  • 00:00:37
    when they use an app integration
  • 00:00:39
    everything that admin needs to
  • 00:00:41
    administrate apps on their team and
  • 00:00:42
    everything developers need to build
  • 00:00:44
    awesome apps and integrations and before
  • 00:00:46
    slack I was a top designer at media and
  • 00:00:48
    at Google with silence Lou can you hear
  • 00:00:52
    me hi going to the other side here so
  • 00:00:56
    I'm just gonna quickly introduce myself
  • 00:00:58
    and then sit down until the end of the
  • 00:00:59
    talk but my name is Garret I have been
  • 00:01:02
    at slack for a few years working with
  • 00:01:03
    Tina on the platform team and slack is
  • 00:01:05
    one big thing so we touched a lot of
  • 00:01:07
    different parts there before slack I was
  • 00:01:09
    at mat box doing labs and kind of
  • 00:01:11
    explain map spit so I'm gonna sit down
  • 00:01:13
    now and let Tina take over so we split
  • 00:01:18
    the talk up so I was gonna talk about a
  • 00:01:20
    bunch of the strategies from a design
  • 00:01:21
    perspective and then Gera is gonna come
  • 00:01:23
    in at the end to recap some strategies
  • 00:01:25
    and add some color from the engineering
  • 00:01:26
    perspective so I thought we would start
  • 00:01:30
    with talking about some of the common
  • 00:01:32
    challenges that we face in day-to-day
  • 00:01:35
    work so here are the four that resonate
  • 00:01:37
    the most with me
  • 00:01:39
    the first one is that you spent all this
  • 00:01:41
    time making an awesome design you've got
  • 00:01:44
    all this feedback you've gotten the
  • 00:01:45
    final set of approvals from all the
  • 00:01:46
    stakeholders you are ready to go
  • 00:01:48
    you had it over to engineering and guess
  • 00:01:50
    what turns out a lot of things are not
  • 00:01:52
    feasible a lot of things are going to
  • 00:01:53
    take way longer than anybody really
  • 00:01:55
    wants to spend on it and you have to go
  • 00:01:57
    back and revise a significant part of
  • 00:01:59
    your designs that is something that has
  • 00:02:02
    to happen to me many times over my
  • 00:02:04
    career the second one is that you write
  • 00:02:08
    even really good specs hand them over to
  • 00:02:10
    engineering and then you know a month or
  • 00:02:12
    so later you take a look and you turn it
  • 00:02:14
    turns out like things are built very
  • 00:02:16
    differently than what you expect out or
  • 00:02:18
    there's a lot of like you know
  • 00:02:20
    miscommunication in some of the details
  • 00:02:22
    they need to go back in
  • 00:02:23
    them up and we communicate rebuild some
  • 00:02:25
    of those things the third one is coming
  • 00:02:29
    up with all these edge cases near the
  • 00:02:31
    end of when your feature is supposed to
  • 00:02:33
    go out so you you know you your design
  • 00:02:35
    is super polished but it turns out hey
  • 00:02:38
    there's like a lot of educators are
  • 00:02:39
    gonna add a lot of time and you don't
  • 00:02:41
    end up either capturing all of those
  • 00:02:42
    before the feature goes out or you have
  • 00:02:45
    to end up revising your designs because
  • 00:02:46
    the edge cases mean that you want to
  • 00:02:48
    adjust something so it's a little
  • 00:02:49
    simpler at the end and then lastly your
  • 00:02:52
    release feature doesn't quite have the
  • 00:02:55
    level of polishing craftsmanship that
  • 00:02:56
    you were hoping for or even your
  • 00:02:57
    engineering partners are hoping for
  • 00:02:58
    because you know you want to hit a
  • 00:03:00
    deadline and sometimes you sacrifice a
  • 00:03:02
    little of that polish to get it on time
  • 00:03:03
    and some is even like the 1.1 release
  • 00:03:05
    doesn't ever really happen because
  • 00:03:06
    everyone has moved on to something else
  • 00:03:08
    so these are the things that have
  • 00:03:09
    happened to me many times over my career
  • 00:03:11
    and I would like to show hands at any of
  • 00:03:13
    this resonates if you're like oh this
  • 00:03:15
    has happened to me before at least once
  • 00:03:17
    okay so a lot of hands so um we want to
  • 00:03:22
    talk about four specific strategies and
  • 00:03:24
    that we've done we've worked on at slack
  • 00:03:28
    and just in general I think throughout
  • 00:03:30
    my product design career these are the
  • 00:03:33
    four things that I've tried to do and I
  • 00:03:35
    think they've helped with a lot of these
  • 00:03:36
    challenges so we'll go through these one
  • 00:03:37
    by one
  • 00:03:37
    again I'll talk about them from the
  • 00:03:39
    design point of view and then Garrett at
  • 00:03:40
    the end will talk about the format
  • 00:03:41
    engineering point of view so the first
  • 00:03:45
    thing is building strong design and
  • 00:03:48
    engineering relationships and I think
  • 00:03:49
    really this is the foundation and
  • 00:03:51
    something that if you do this right
  • 00:03:53
    everything gets way easier and what I
  • 00:03:56
    mean by this is to think about even like
  • 00:03:59
    the structure of your team's so for
  • 00:04:01
    example having a smaller team a more
  • 00:04:03
    stable team really helps in this regard
  • 00:04:06
    on the platform we used to be you know
  • 00:04:10
    there's a couple of designers a couple
  • 00:04:11
    of PM's a good number of Engineers and
  • 00:04:13
    it would happen that a designer might
  • 00:04:16
    work on like three different features at
  • 00:04:17
    a time with two to three different PMS
  • 00:04:20
    with like two to three different
  • 00:04:22
    engineering teams entirely and so you
  • 00:04:23
    spend a lot of time keeping people
  • 00:04:25
    up-to-date telling like oh I won't get
  • 00:04:27
    to this by this time but next week I'll
  • 00:04:29
    get to this at that time and keeping
  • 00:04:31
    everybody up-to-date with like any
  • 00:04:33
    design changes and it's a lot of
  • 00:04:34
    overhead it is a lot to keep straight
  • 00:04:37
    so we've actually in the last three
  • 00:04:40
    quarters or so form smaller stable teams
  • 00:04:43
    three sub teams within a platform and
  • 00:04:46
    each team has one signer one p.m. one
  • 00:04:49
    end manager and like six to eight
  • 00:04:51
    engineers and it become it just like
  • 00:04:53
    reduces by like a half earth but it
  • 00:04:58
    reduces it your overhead of
  • 00:05:00
    communication by a lot so you only
  • 00:05:02
    really have like a smaller number of
  • 00:05:03
    people to talk to and then you can
  • 00:05:04
    really focus on building good
  • 00:05:06
    relationships with that smaller group
  • 00:05:07
    and talk about how you're gonna work
  • 00:05:09
    together and your rhythm so this is a
  • 00:05:10
    photo of the discovery sub team that
  • 00:05:13
    Gary and I both work on and this is kind
  • 00:05:16
    of the size of the team and it's allowed
  • 00:05:18
    us to move much faster and to be able to
  • 00:05:20
    make decisions much faster so some of
  • 00:05:24
    the things that I do when I first work
  • 00:05:27
    with the engineer either like I'm new to
  • 00:05:29
    the team or it's somebody that I haven't
  • 00:05:31
    worked with a lot I like to make sure we
  • 00:05:33
    talk about how we're gonna work together
  • 00:05:34
    and not just about the future and just
  • 00:05:36
    the designs and establish a good rhythm
  • 00:05:38
    so that means questions like you see
  • 00:05:41
    might seem really obvious but there's a
  • 00:05:42
    lot of interesting things that come out
  • 00:05:44
    of these discussions like how and when
  • 00:05:45
    do you want me to share design work with
  • 00:05:47
    you do you like to run things through in
  • 00:05:48
    person do you want to like get a
  • 00:05:50
    document so you can think more deeply
  • 00:05:51
    about it I also establish the fact that
  • 00:05:54
    I'm gonna share designs really early if
  • 00:05:55
    that's okay but they're gonna be really
  • 00:05:57
    rough and form like conversation around
  • 00:06:00
    like the kind of feedback that I want I
  • 00:06:03
    also really like to flag this is the
  • 00:06:04
    thing where I'm like I'm not going to
  • 00:06:06
    try to get all the design decisions done
  • 00:06:08
    actually package them up into this
  • 00:06:11
    perfect bundle and hand it off to you
  • 00:06:12
    like that is not gonna happen I'm gonna
  • 00:06:14
    try to make as many decisions in
  • 00:06:16
    parallel with you as possible but I want
  • 00:06:18
    to make the decisions that impact the
  • 00:06:20
    things that you want to do first
  • 00:06:22
    so to unblock engineering so you can
  • 00:06:24
    start you know thinking about how it's
  • 00:06:27
    going to be built while I can defer
  • 00:06:28
    something to design decisions later on
  • 00:06:30
    because feedback always comes in you
  • 00:06:32
    know even if you have really good design
  • 00:06:33
    you really adjust that as you can work
  • 00:06:35
    back to other people on your team and
  • 00:06:36
    just making sure that that's something
  • 00:06:38
    that they expect and something that I
  • 00:06:41
    also know as I work on the designs and
  • 00:06:45
    then lastly I really want to know what
  • 00:06:48
    design decisions are really hard to
  • 00:06:50
    change later
  • 00:06:50
    because this can bite you in the butt if
  • 00:06:52
    you don't do this right and sometimes
  • 00:06:56
    like the things that can be really
  • 00:06:57
    unexpected even if you know how to code
  • 00:06:59
    like the nuances of your particular
  • 00:07:01
    product or legacy can impact this and
  • 00:07:04
    engineer notes is way better than you do
  • 00:07:05
    so being able to make sure that like
  • 00:07:07
    these important decisions that are hard
  • 00:07:09
    to change I will make sure that we get
  • 00:07:11
    all the feedback so this is the right
  • 00:07:12
    thing to do we're not gonna change them
  • 00:07:13
    but all the other things are easy to
  • 00:07:15
    change we're gonna try them out we're
  • 00:07:17
    gonna get more feedback we're gonna
  • 00:07:18
    adapt we're gonna iterate quickly and
  • 00:07:19
    just making sure that you know what
  • 00:07:21
    these things are ahead of time makes it
  • 00:07:23
    really a lot easier work later on and
  • 00:07:26
    then I also like to make sure that I
  • 00:07:30
    have talked to the engineer about how
  • 00:07:31
    I'm gonna give them feedback so I'm
  • 00:07:34
    gonna give you a lot of polish and craft
  • 00:07:35
    feedback as we work along because I care
  • 00:07:37
    and I want to know when you want that at
  • 00:07:40
    the right time for you and not actually
  • 00:07:42
    Admiral overhead what they have to do I
  • 00:07:44
    want to know when early builds are
  • 00:07:45
    available so I can kind of take a look
  • 00:07:47
    even if you don't do anything about it
  • 00:07:49
    maybe I won't give you giving you any
  • 00:07:50
    feedback but I like to keep tabs on when
  • 00:07:53
    work is being done because if I can spot
  • 00:07:56
    something early and say oh this is not
  • 00:07:58
    quite what we want or like hey seeing
  • 00:08:00
    this live that actually there's a better
  • 00:08:03
    way to do this if I catch it the right
  • 00:08:05
    time we can fix it and make something
  • 00:08:07
    way better but if I catch a really late
  • 00:08:09
    no one's gonna want to like it's gonna
  • 00:08:11
    you're gonna fight some battles like
  • 00:08:13
    undo a lot of work so the earlier you
  • 00:08:15
    can identify these the better your
  • 00:08:16
    product will be and then lastly I want
  • 00:08:20
    to know how you file and track bugs and
  • 00:08:22
    this sometimes is talking to more you be
  • 00:08:23
    like an end manager for like how their
  • 00:08:25
    team works but having having all your
  • 00:08:30
    bugs go directly into an engineer's like
  • 00:08:32
    to-do list makes it's so much more
  • 00:08:35
    likely that all the crap all of the
  • 00:08:37
    craft and polish is gonna get done as
  • 00:08:40
    opposed to like me imposing another
  • 00:08:41
    document that you have to remember to
  • 00:08:43
    check it makes it much harder for an
  • 00:08:45
    engineer even a very well-intentioned
  • 00:08:46
    engineer to remember to do that and so
  • 00:08:48
    you know having making it just like
  • 00:08:51
    parlo the flow is really really helpful
  • 00:08:54
    and also along the notion of sharing
  • 00:08:58
    designs this is something that like has
  • 00:09:00
    stood out to me and maybe it's obvious
  • 00:09:02
    maybe it's not but I'm gonna say it
  • 00:09:03
    anyway because I think is
  • 00:09:04
    pretty important is that when you share
  • 00:09:06
    designs make sure you talk about them
  • 00:09:07
    and that could be in person it could be
  • 00:09:10
    over BC it could be you know even a chat
  • 00:09:13
    in slack it's all great if you're not
  • 00:09:16
    having a deep discussion about designs
  • 00:09:17
    it means you're not actually getting to
  • 00:09:19
    a shared understanding and what I've
  • 00:09:21
    also found is that engineers buy
  • 00:09:22
    sometimes be like yeah that looks great
  • 00:09:24
    done and they're like okay well it turns
  • 00:09:28
    out like hey they just didn't ask all
  • 00:09:30
    the questions that they had they just
  • 00:09:31
    that they're like mom 80% sure that's
  • 00:09:33
    what they meant done um but if you
  • 00:09:36
    actually like are talking to somebody in
  • 00:09:38
    person and discussing it and like really
  • 00:09:41
    highlighting they're like yeah this is
  • 00:09:42
    the design I think it's this way and I'm
  • 00:09:43
    pretty sure but not completely do you
  • 00:09:45
    have any questions you will get all
  • 00:09:46
    those questions early and that really
  • 00:09:49
    like once you get all those questions
  • 00:09:50
    out you'll actually have a shared
  • 00:09:51
    understanding of your design work if you
  • 00:09:53
    don't do that it's really like a one-way
  • 00:09:55
    communication and it's you should have
  • 00:09:58
    lower confidence that you've actually
  • 00:09:59
    communicated the intentions really well
  • 00:10:02
    and lastly on this first point I think
  • 00:10:06
    it's really important to put in the
  • 00:10:08
    effort to check in regularly when you're
  • 00:10:11
    when you're working with somebody for
  • 00:10:12
    the first time right because not all
  • 00:10:14
    engineers are really used to working
  • 00:10:16
    really closely with designers and just
  • 00:10:19
    taking that extra burden upon yourself
  • 00:10:21
    to be like hey it's been a couple of
  • 00:10:23
    days it's been a week like you know to
  • 00:10:24
    have you started working on this or like
  • 00:10:26
    do have any additional questions or like
  • 00:10:28
    I know you've finished like like this
  • 00:10:30
    part of the future you moving on those
  • 00:10:31
    next part you probably don't remember
  • 00:10:32
    any of the things we talked to
  • 00:10:34
    conscience the nuances let's talk about
  • 00:10:35
    them again really pays off and what
  • 00:10:37
    happens is that um you don't have to do
  • 00:10:41
    this for everything you do it like once
  • 00:10:43
    and this magic thing happens where your
  • 00:10:45
    engineer is like oh I have a new build
  • 00:10:47
    usually I'm a new build Tina asked me to
  • 00:10:49
    share that with her I'll just share it
  • 00:10:50
    with her and then I don't do it anymore
  • 00:10:52
    they just reach out to me and it's like
  • 00:10:54
    a really nice cycle and have it to get
  • 00:10:56
    into so definitely get worried it's too
  • 00:10:59
    quiet and just don't be afraid of
  • 00:11:00
    reaching out and a knife not annoying
  • 00:11:02
    way like you guys some engineers don't
  • 00:11:04
    like it if you just you know tapping the
  • 00:11:05
    shoulders I usually just message them
  • 00:11:07
    and clack so find the right way about
  • 00:11:08
    how to you know poke a engineer a little
  • 00:11:11
    bit until they like start reaching out
  • 00:11:13
    to you regularly and then some specific
  • 00:11:16
    examples that I have around this
  • 00:11:18
    I just took some screenshots and slack
  • 00:11:20
    it's nice to have everything tracked in
  • 00:11:22
    slack it's very helpful for this talk
  • 00:11:24
    jamie is a friend and engineer on the
  • 00:11:27
    platform team and this is like maybe
  • 00:11:28
    midway through our first week here
  • 00:11:30
    together and she started just reaching
  • 00:11:32
    out with things like hey these tabs I've
  • 00:11:34
    discovered that we use them in more
  • 00:11:35
    places than you thought which I truly
  • 00:11:36
    didn't know and they don't necessarily
  • 00:11:39
    work here are two links that you'd like
  • 00:11:41
    just live builds that you can look at
  • 00:11:43
    and see how they work and so I looked at
  • 00:11:45
    it and gave her like a quick
  • 00:11:47
    modification knowing that this is now
  • 00:11:49
    all the places she gave feedback on it
  • 00:11:51
    she like implemented it and then later
  • 00:11:53
    like this is like half an hour later
  • 00:11:55
    she's very fast
  • 00:11:56
    I got like additional dev links to see
  • 00:11:59
    the the new adjusted designs in dev and
  • 00:12:02
    I could look at them and have really
  • 00:12:04
    clear confidence we've communicated well
  • 00:12:05
    because it's good to go it's like super
  • 00:12:07
    polished another example this is with
  • 00:12:10
    Garrett is near the end of this
  • 00:12:12
    particular project which is a very like
  • 00:12:14
    tight tight deadline so a lot of pieces
  • 00:12:17
    are in flight and so like we would often
  • 00:12:19
    have these conversations I'm like I
  • 00:12:20
    don't know it's just are you done with
  • 00:12:21
    this feature yet can add design feedback
  • 00:12:23
    this is helpful for you or is this like
  • 00:12:25
    stuff that you all already know because
  • 00:12:27
    you haven't implemented yet and this is
  • 00:12:28
    like the type of conversation that we
  • 00:12:30
    have pretty regularly so I would say
  • 00:12:32
    like if you're having these
  • 00:12:33
    conversations you're really good on the
  • 00:12:36
    communication spectrum if you're not
  • 00:12:37
    having them super often I bet having
  • 00:12:39
    more of this type of interaction will
  • 00:12:42
    make like all your design dreams come
  • 00:12:44
    more true or at least faster at least
  • 00:12:45
    like you will be less frustrated about
  • 00:12:47
    it the second point is to bring
  • 00:12:51
    engineering in early and the question
  • 00:12:54
    that I think some people ask is what if
  • 00:12:56
    it is too early and I have also asked
  • 00:12:59
    myself this and the answer is always no
  • 00:13:01
    the answer is like there is no such
  • 00:13:03
    thing as too early having shared context
  • 00:13:08
    and understanding and alignment
  • 00:13:10
    unlike why what and how super useful
  • 00:13:15
    even if you're only talking about the
  • 00:13:16
    why because if you bring somebody in at
  • 00:13:19
    the end of a project the first thing
  • 00:13:20
    they're going to want to do is to
  • 00:13:21
    understand like what we're doing this
  • 00:13:22
    what are we doing and how are we doing
  • 00:13:24
    it and if you start even just the Y
  • 00:13:26
    conversation earlier you don't have to
  • 00:13:28
    have that conversation later on and that
  • 00:13:29
    person feels
  • 00:13:30
    bested what you're doing together they
  • 00:13:32
    get a chance to influence the Y if they
  • 00:13:34
    strongly disagree with it or have you
  • 00:13:36
    know a perspective that you haven't
  • 00:13:38
    thought about it's really nice and it
  • 00:13:40
    can just be like half our conversation
  • 00:13:42
    you don't have to like say oh you're
  • 00:13:43
    gonna work on this full-time it can just
  • 00:13:44
    be like a hey you're probably going to
  • 00:13:46
    be the tech lead on this you're not
  • 00:13:48
    gonna start it for a while but we're
  • 00:13:49
    starting to define the problem
  • 00:13:51
    come brainstorm with us or like you know
  • 00:13:53
    I have some really early designs they're
  • 00:13:55
    super rough I want to get a sense of
  • 00:13:57
    like you know is this the right
  • 00:13:58
    direction what engineering you know
  • 00:14:00
    technical concerns that you have stuff
  • 00:14:03
    like that and I think like I've kept
  • 00:14:06
    pushing this more more earlier for
  • 00:14:07
    sounds like okay well bring them in when
  • 00:14:09
    I have like wireframes I'll bring them
  • 00:14:11
    in when I have like flows I'll bring
  • 00:14:12
    them in when like I know this project is
  • 00:14:14
    happening exactly what the design
  • 00:14:16
    direction is but no I keep pushing it
  • 00:14:18
    further further towards the beginning
  • 00:14:19
    and it's so far it's always helped
  • 00:14:22
    essentially as long as you frame you
  • 00:14:24
    frame like the problem well so you don't
  • 00:14:25
    want to be like oh we're gonna do this
  • 00:14:26
    right away you you have to be like
  • 00:14:28
    here's a problem and here's where we're
  • 00:14:30
    at and here's what we're going so
  • 00:14:35
    another thing that's kind of a fallout
  • 00:14:36
    from bringing people in early it's as
  • 00:14:37
    sometimes nobody knows what's going on
  • 00:14:39
    like you actually don't know you're
  • 00:14:40
    gonna do yeah you have like the area
  • 00:14:43
    that you want to like make progress you
  • 00:14:45
    know you have a specific problem you
  • 00:14:46
    want to solve you really don't know how
  • 00:14:48
    now you have a lot of people who will
  • 00:14:49
    want to help figure that out but no one
  • 00:14:51
    really knows the answer yet
  • 00:14:52
    so how do you align the team on
  • 00:14:56
    something super super early so one of
  • 00:14:57
    the things that we've done at slack I'm
  • 00:14:59
    sure many of you have done this in your
  • 00:15:01
    own day-to-day jobs is to have a design
  • 00:15:04
    sprint and who has actually run or
  • 00:15:06
    participated in design sprint point all
  • 00:15:09
    right so a good number of people and I
  • 00:15:12
    actually find that if you do if you do
  • 00:15:13
    this well it's super helpful at
  • 00:15:15
    unblocking some of the nebulous problems
  • 00:15:17
    and also makes like bringing people like
  • 00:15:19
    less scary in the beginning so an
  • 00:15:22
    example of how we run design sprints at
  • 00:15:25
    slack is this workflows and slack sprint
  • 00:15:29
    that we did I think almost a year ago at
  • 00:15:31
    this point so we really wanted to
  • 00:15:35
    explore the notion of workflows I got a
  • 00:15:36
    lot of conversations about it in various
  • 00:15:40
    combinations of people on the platform
  • 00:15:42
    team but like we were
  • 00:15:43
    having a really hard time getting to
  • 00:15:45
    something tangible that we can move
  • 00:15:46
    forward so when I run design Sprint's I
  • 00:15:49
    really like to have two things one is
  • 00:15:51
    like what are we trying to answer and
  • 00:15:52
    make that very very precise like what is
  • 00:15:53
    the thing we actually want to answer at
  • 00:15:55
    the end of this design sprint and also
  • 00:15:57
    what we have at the end of this design
  • 00:15:58
    sprint to make sure that like everybody
  • 00:16:00
    is on the same page in terms of like
  • 00:16:01
    what we want from it and then we run
  • 00:16:05
    them in this in the style like you know
  • 00:16:07
    like Google Ventures has like a
  • 00:16:08
    wonderful book called sprint that goes
  • 00:16:10
    through this similar to I think how I do
  • 00:16:11
    runs um I'm sure a lot of this will be
  • 00:16:13
    familiar but like you know we start with
  • 00:16:15
    a bunch of presentations around like you
  • 00:16:18
    know what do we know about the problem
  • 00:16:20
    what are the type of like workflows that
  • 00:16:21
    people use today what kind of software
  • 00:16:23
    they use just to get people all brought
  • 00:16:26
    up to speed on it pre-existing knowledge
  • 00:16:28
    so we were starting from like a level
  • 00:16:30
    playing field and then we do a bunch of
  • 00:16:32
    brainstorming on sticky notes for like
  • 00:16:34
    how might we we group them into the
  • 00:16:36
    types of problems and features that we
  • 00:16:38
    might want to build we split a small
  • 00:16:41
    groups and do this like kind of one to
  • 00:16:43
    three step flows around like one way
  • 00:16:46
    like type of feature that we might want
  • 00:16:48
    to build solve one of these things um
  • 00:16:50
    and then because this is like a three
  • 00:16:52
    day sprint we spend a bunch more time
  • 00:16:54
    I'm kind of individually working on some
  • 00:16:56
    of these concepts so like the designers
  • 00:16:58
    did a bunch of mocks that Illustrated
  • 00:17:01
    like you know what are the components at
  • 00:17:03
    work those could be some of the PM's
  • 00:17:05
    wrote like system diagrams around like
  • 00:17:09
    what they thought like the semantic
  • 00:17:10
    system of work was we had some designers
  • 00:17:13
    actually do some deep technical
  • 00:17:15
    exploration into like oh we wanted to do
  • 00:17:17
    something like federated search where
  • 00:17:19
    you could search anything it's like
  • 00:17:20
    anything connected to slack you could
  • 00:17:21
    search like you know your Google Docs or
  • 00:17:24
    Dropbox paper things anything that you
  • 00:17:27
    had like what would that mean
  • 00:17:28
    technically and that was for helpful
  • 00:17:30
    even though it was very broad at the end
  • 00:17:32
    of this like we were able to say like
  • 00:17:33
    okay here's some of the concepts have
  • 00:17:36
    emerged from it and then when we talked
  • 00:17:38
    about like we could build a or B first
  • 00:17:40
    everyone kind of knows what a is and
  • 00:17:41
    kind of would be it's as a post like
  • 00:17:42
    this amorphous blob of like ideas so
  • 00:17:46
    this has been really helpful and we kind
  • 00:17:48
    of try to do this at the beginning of
  • 00:17:50
    any project that's that we want to do a
  • 00:17:52
    lot of like open exploration on
  • 00:17:55
    the third strategy is parallel design
  • 00:17:58
    and technical explorations so this is
  • 00:18:01
    something that I think is a little newer
  • 00:18:02
    to me at least I think we've done this
  • 00:18:04
    more at slack than previous places but
  • 00:18:07
    it's been really useful for exploring a
  • 00:18:09
    problem space quickly so instead of like
  • 00:18:10
    design doing explorations and being like
  • 00:18:13
    okay we've gotten to like as far as we
  • 00:18:15
    can now we can of Engineering and they
  • 00:18:17
    like look at whether it's possible or
  • 00:18:19
    not and then after they've decided
  • 00:18:20
    what's possible or not the hand of
  • 00:18:22
    actual design designs like okay now I
  • 00:18:23
    know it's possible I'm gonna like narrow
  • 00:18:25
    this down and when it's done I'm gonna
  • 00:18:26
    head it back engineering and they're
  • 00:18:27
    gonna be like okay this Hollow it's
  • 00:18:29
    gonna take that's a lot of back and
  • 00:18:32
    forth so we try to like intermingle that
  • 00:18:34
    as much as possible and try to move in a
  • 00:18:36
    way that's a little bit faster but this
  • 00:18:40
    is very important if you're gonna do
  • 00:18:41
    that to like make sure you have
  • 00:18:42
    milestones sinks like goals so it's not
  • 00:18:45
    just like on exploration time that comes
  • 00:18:48
    up with cool ideas but not actually a
  • 00:18:50
    line around the thing you actually want
  • 00:18:51
    to build in the end so just keep a note
  • 00:18:54
    on that but I find that that you know
  • 00:18:56
    design concepts obviously are really
  • 00:18:58
    really useful for clarifying goals
  • 00:19:00
    making sure if you visualize something
  • 00:19:02
    people can be like that's what I'm
  • 00:19:03
    thinking about or like nope that's very
  • 00:19:05
    different the problem actually wanted to
  • 00:19:06
    solve you know you can come with a bunch
  • 00:19:09
    of different solution concepts without
  • 00:19:11
    committing to something which is I think
  • 00:19:12
    really important to make sure you've
  • 00:19:13
    explored as far as you can go very
  • 00:19:16
    quickly technical explorations and
  • 00:19:19
    prototypes super useful for two things
  • 00:19:20
    one of them is informing design concepts
  • 00:19:22
    if you can play with it you understand
  • 00:19:25
    it much more differently than if you're
  • 00:19:26
    just mocking or even if you're
  • 00:19:27
    prototyping as a designer it's not the
  • 00:19:28
    same it's like live data and the other
  • 00:19:31
    thing around this is that you get a
  • 00:19:33
    sense of like technically how difficult
  • 00:19:34
    it is how long it's gonna take because
  • 00:19:36
    if you're like I want to fight for this
  • 00:19:37
    feature this is really important if
  • 00:19:39
    you're armed it's like and we know
  • 00:19:41
    engineering says it's gonna take two
  • 00:19:43
    months you can do it you're gonna get a
  • 00:19:45
    sign-off if you say like I have no idea
  • 00:19:46
    it's gonna take another month to figure
  • 00:19:47
    out if it's doable or not then you know
  • 00:19:49
    then everything gets pushed out longer
  • 00:19:52
    and a specific example of this that
  • 00:19:54
    happened recently in our team is
  • 00:19:59
    dialogues just feature we launched or
  • 00:20:02
    developers to build essentially forms in
  • 00:20:04
    slack which opens up a lot of more
  • 00:20:06
    powerful use cases
  • 00:20:08
    the types of apps that people can build
  • 00:20:09
    but this started as a project that was
  • 00:20:12
    like developers really really really
  • 00:20:14
    really really wants free text input why
  • 00:20:17
    don't we just add that because there's
  • 00:20:19
    no way for users to give that directly
  • 00:20:22
    to a developer unless they're willing to
  • 00:20:24
    make a bot which comes with a lot of
  • 00:20:25
    other things they'd have to build for
  • 00:20:27
    but this has a lot of implications right
  • 00:20:30
    so so Jason is like prototyping he's
  • 00:20:33
    he's an engineer
  • 00:20:34
    he's prototyping like kind of how does
  • 00:20:35
    my feel just try to see what's doable
  • 00:20:37
    hacking something together meanwhile
  • 00:20:42
    Bruce who may or may not actually be
  • 00:20:44
    here okay Bruce is designer on the
  • 00:20:48
    platform team who may have attended
  • 00:20:50
    tonight and he was doing well and we're
  • 00:20:54
    back there
  • 00:20:54
    Bruce is awesome to talk to him later he
  • 00:20:58
    was doing explorations around like hope
  • 00:20:59
    you do free text input with implications
  • 00:21:01
    and implications are people are going to
  • 00:21:03
    try to make forms like they're gonna
  • 00:21:04
    like do all these things that have a lot
  • 00:21:06
    of kind of UI complexity and maybe even
  • 00:21:09
    you know there's some pattern Thorogood
  • 00:21:11
    from their art so he's exploring this
  • 00:21:12
    he's exploring forms at some point
  • 00:21:15
    there's a lot of discussions and
  • 00:21:17
    channels around between forms reading
  • 00:21:18
    free text input where it's the boarder
  • 00:21:20
    what's the difference and because of all
  • 00:21:22
    this kind of parallel discovery it turns
  • 00:21:25
    out hey we should just do for us because
  • 00:21:26
    it's better it's not that hard
  • 00:21:27
    technically and it's like way better for
  • 00:21:29
    users is better for developers and at
  • 00:21:32
    that point when they started doing more
  • 00:21:34
    like serious wireframes around in
  • 00:21:37
    looking at like you know what the forms
  • 00:21:38
    features were it was great because you
  • 00:21:40
    know feedback that came from other parts
  • 00:21:42
    of the company which was like well let's
  • 00:21:44
    just do the smallest part first just do
  • 00:21:45
    free Texan but the team could be like no
  • 00:21:47
    we've explored this we're allied and we
  • 00:21:49
    know exactly the cost we know why the
  • 00:21:51
    experience is not as good and it was a
  • 00:21:54
    really good case for it and so when they
  • 00:21:56
    started implementing it was much much
  • 00:21:58
    faster
  • 00:21:58
    they were super effective they didn't
  • 00:22:01
    have all this turnaround like oh did you
  • 00:22:03
    did you think about actually think about
  • 00:22:04
    why and the last thing I wanted to talk
  • 00:22:07
    about is how to communicate design specs
  • 00:22:09
    and polish super important you're dear
  • 00:22:11
    to my heart very important part of this
  • 00:22:13
    job designer so the problem with exact
  • 00:22:17
    specs so this is where we were maybe
  • 00:22:21
    like
  • 00:22:22
    a couple quarters ago and slack we were
  • 00:22:24
    really it was very popular to share of
  • 00:22:25
    red lines using either in vision or
  • 00:22:27
    Zeppelin because we just use all the
  • 00:22:28
    tools or like a sketch plug-in that does
  • 00:22:30
    all the perfect red lines for you you
  • 00:22:32
    export them you sound engineer not bad
  • 00:22:35
    but two problems one super fragile like
  • 00:22:39
    you know you know you're doing your
  • 00:22:40
    mocks you have like you know twenty
  • 00:22:42
    states or something things get nudged a
  • 00:22:44
    little bit a engineers are gonna
  • 00:22:45
    implement exactly what you put in there
  • 00:22:46
    sometimes they're gonna be nudged not
  • 00:22:48
    great and also inaccurate like if I'm
  • 00:22:53
    trying to share a piece of like a font
  • 00:22:55
    style right or protects that I have like
  • 00:22:58
    is it actually 18 pixels or do actually
  • 00:23:01
    mean to communicate like Oh in our font
  • 00:23:03
    system is actually like based on Rams
  • 00:23:04
    and that's what I want or actually I
  • 00:23:06
    want to use this class I'm trying to
  • 00:23:08
    replicate this the system on this page
  • 00:23:11
    with this new feature I don't want to go
  • 00:23:12
    anything new I wanna be super consistent
  • 00:23:14
    so we change it later it changes here so
  • 00:23:16
    inaccurate right it's like it's a very
  • 00:23:18
    imperfect representation of what I'm
  • 00:23:20
    trying to communicate as a designer so
  • 00:23:22
    what we've been trying to be more and
  • 00:23:24
    more of over time is to rely more on a
  • 00:23:27
    shared language and shared standards
  • 00:23:29
    instead of like exact pixels for some
  • 00:23:31
    first specific feature and so what that
  • 00:23:34
    means it's stuff like this which is a
  • 00:23:37
    design spec so many words beautiful
  • 00:23:40
    words where it's like what does the
  • 00:23:42
    submit button what is like what does
  • 00:23:44
    that even mean
  • 00:23:44
    well like you know it's gonna be
  • 00:23:45
    disabled until the fields are valid like
  • 00:23:48
    what is the next character length how do
  • 00:23:49
    you treat all these things like this was
  • 00:23:51
    all captured like in the spec and
  • 00:23:54
    there's of course like images and like
  • 00:23:55
    you know more detailed spacing and
  • 00:23:57
    everything to but it's super important
  • 00:23:58
    to have that in there so we're trying to
  • 00:24:00
    use a lot more like language around
  • 00:24:01
    we're trying to do and how these things
  • 00:24:03
    are defined we also have things like
  • 00:24:06
    instead of you know measuring everything
  • 00:24:09
    on every page just talking about a
  • 00:24:11
    shared rhythm like what's our base grid
  • 00:24:13
    unit like it's our base unit is four and
  • 00:24:15
    so you can tell if something is really
  • 00:24:16
    big it's gonna be this multiple four
  • 00:24:18
    something is smaller it's that multiple
  • 00:24:19
    4 and so engineers have a much more
  • 00:24:21
    built in rhythm for how you know this is
  • 00:24:24
    kind of how designers think about things
  • 00:24:25
    and you're trying to translate that into
  • 00:24:27
    like how engineers hopefully will think
  • 00:24:29
    about things and be able to make really
  • 00:24:30
    smart decisions you know without
  • 00:24:32
    necessarily having to consult designer
  • 00:24:33
    for every little
  • 00:24:34
    every little spacing nudge that has to
  • 00:24:37
    happen which we can do but it's very
  • 00:24:38
    time-consuming and I think when I was
  • 00:24:43
    putting this together like how to build
  • 00:24:44
    a shared language is often something
  • 00:24:46
    that comes up because it's hard right
  • 00:24:47
    slack has 20-some product designers many
  • 00:24:52
    more engineers and even at that size
  • 00:24:54
    it's hard to get everybody on board you
  • 00:24:57
    know on design team with like what the
  • 00:24:58
    actual shared language should be with
  • 00:25:00
    the you know just even what the
  • 00:25:03
    component system should look like and
  • 00:25:04
    behave and then also getting engineers
  • 00:25:06
    to agree to that and have everybody
  • 00:25:08
    speaking the same language is hard so we
  • 00:25:12
    were stuck on this a little bit but more
  • 00:25:13
    recently we have found our pairs and our
  • 00:25:17
    advocates in our cross-functional
  • 00:25:19
    partners so this has helped a lot so an
  • 00:25:22
    example of this is socket which is our
  • 00:25:25
    component system which is a work in
  • 00:25:27
    progress but it started with like so
  • 00:25:30
    Garrett has as a wonderful front-end
  • 00:25:34
    senior front-end engineer has noticed
  • 00:25:36
    that a lot of engineers are rebuilding
  • 00:25:38
    things there was a lot of like
  • 00:25:40
    redundancy in the code it wasn't clean
  • 00:25:42
    it was hard to maintain a lot of like
  • 00:25:44
    slight differences which just result in
  • 00:25:46
    like a slightly eroded product
  • 00:25:48
    experience over time and he was spending
  • 00:25:50
    a lot of time trying to wrangle that
  • 00:25:51
    together into components that engineers
  • 00:25:53
    could reuse like style sheets that like
  • 00:25:55
    they could just prefer to instead of
  • 00:25:57
    building it over and over again then he
  • 00:25:59
    had questions like what is a pattern
  • 00:26:01
    that we want to perpetuate what is a
  • 00:26:03
    pattern we want to deprecate you know if
  • 00:26:05
    I'm going to make this warrant like this
  • 00:26:08
    like alert system like what are all the
  • 00:26:09
    states that we need to capture how do we
  • 00:26:11
    make it robust and so you need a design
  • 00:26:12
    partner to like sign off on that stuff
  • 00:26:14
    and actually like basically where it can
  • 00:26:16
    in hand to create the system and order
  • 00:26:17
    on the design side we had our master
  • 00:26:19
    sketch file which is all the things that
  • 00:26:21
    designers use the reference but we're
  • 00:26:22
    like oh it's two different styles like
  • 00:26:25
    20 colors and you know like we knew what
  • 00:26:28
    we wanted but we're like oh it's already
  • 00:26:30
    used because it's not in codes you can't
  • 00:26:31
    just tell you engineer like hey use this
  • 00:26:33
    component it's all defined just go ahead
  • 00:26:36
    and use it because it wasn't clean yet
  • 00:26:38
    and so when we like got together and
  • 00:26:40
    created like a place for that
  • 00:26:41
    conversation to happen a space for
  • 00:26:43
    people to donate basically their free
  • 00:26:44
    time and all of your it's I'm
  • 00:26:46
    to work on this it just oh it was great
  • 00:26:49
    we started getting them in sync
  • 00:26:52
    you know we had designer it's just like
  • 00:26:54
    getting these components system these
  • 00:26:57
    components I cleaned up and they were
  • 00:26:58
    just in code once they were in code
  • 00:26:59
    anybody could use them we started
  • 00:27:01
    getting rid of all his crappy code and
  • 00:27:03
    cleaning things up in the UI it was
  • 00:27:04
    great so that's the power of design and
  • 00:27:06
    engineering advocacy finding find your
  • 00:27:09
    advocacy friends and this is something
  • 00:27:12
    that happened recently which is Gloria
  • 00:27:15
    so 136 colors so many blues none of them
  • 00:27:21
    are accessible so many Gray's they are
  • 00:27:26
    also wonderful names but you can't
  • 00:27:27
    really read but they're very inspired
  • 00:27:28
    like I don't know like a tune you're
  • 00:27:32
    like Brandon ate a lot of these are
  • 00:27:34
    they're very good if you can read them
  • 00:27:36
    um but yes we a lot of colors and
  • 00:27:39
    there's just like really hard thing to
  • 00:27:40
    fix right because they're everywhere who
  • 00:27:42
    has time to audit them how do you know
  • 00:27:43
    what the right colors are McGarrett and
  • 00:27:45
    who Bear who's a designer at SLAC paired
  • 00:27:47
    together and who berry cares a lot about
  • 00:27:48
    they spent a lot of time figuring out
  • 00:27:50
    what the right blue should be and so
  • 00:27:51
    together they like went in they scrubbed
  • 00:27:53
    all the colors they made a build that
  • 00:27:55
    had only are approved mostly contrast
  • 00:27:59
    friendly 16 colors that we wanted and
  • 00:28:01
    then you know we shared it up scrubbed
  • 00:28:03
    it a little bit but it was great it was
  • 00:28:06
    fantastic so yeah so this happens when
  • 00:28:08
    you work together hands over to get we
  • 00:28:19
    merged that colors thing about a month
  • 00:28:21
    ago and those most terrifying merch I've
  • 00:28:23
    made yet at SLAC because we had no way
  • 00:28:25
    of actually uh rolling it out slowly so
  • 00:28:28
    hopefully no one noticed anything not so
  • 00:28:32
    yeah this is the part where I come in
  • 00:28:33
    and tell you a roomful of designers why
  • 00:28:35
    they're all wrong and engineering is
  • 00:28:36
    right no I really
  • 00:28:39
    Tina covered a lot of it I'm gonna be
  • 00:28:40
    pretty quick I just wanted to color some
  • 00:28:41
    of these things kind of from an
  • 00:28:43
    engineering perspective and we'll have
  • 00:28:44
    more time in the QA to kind of talk
  • 00:28:46
    through some of these things but I'll go
  • 00:28:48
    through some of these points and just
  • 00:28:49
    kind of give our perspective on these
  • 00:28:51
    things from the engineering side some
  • 00:28:53
    little background of myself I was
  • 00:28:55
    formerly a designer I know like I call
  • 00:28:57
    myself one because people in this room
  • 00:28:58
    here probably far more talented than
  • 00:28:59
    I'm myself anymore so I'm firmly in the
  • 00:29:02
    front-end world now but when I go to
  • 00:29:05
    places I do try to look at and find
  • 00:29:09
    designers that kind of think about these
  • 00:29:10
    things similar to how I do it there's a
  • 00:29:13
    lot of gray area there and I think it's
  • 00:29:14
    really important to kind of start
  • 00:29:15
    finding these relationships and so I
  • 00:29:18
    think as designers it's really important
  • 00:29:20
    to kind of understand the different I
  • 00:29:22
    call it different flavors of engineer
  • 00:29:23
    and what I mean by that is here's a very
  • 00:29:26
    oversimplified n diagram that doesn't
  • 00:29:28
    cover nearly enough skills but when
  • 00:29:31
    you're working with engineer a lot of
  • 00:29:32
    them kind of occupy some of those those
  • 00:29:34
    shaded areas they're those places that
  • 00:29:36
    they might they may have like me I have
  • 00:29:39
    a an interest in design of the work in
  • 00:29:42
    the front end or I don't know how many
  • 00:29:44
    folks occupy the back end and design
  • 00:29:46
    skills but I know they're out there in
  • 00:29:47
    this bar super talent as well but myself
  • 00:29:50
    I'm probably in that green area maybe a
  • 00:29:52
    little bit more yellow these days
  • 00:29:53
    there's a lot of slack Engineers like
  • 00:29:55
    that we also some folks that hang out in
  • 00:29:58
    that orange area there there's back and
  • 00:29:59
    in front and those are folks that kind
  • 00:30:01
    of deal with some of the hairier bits of
  • 00:30:03
    the front end code infrastructure api's
  • 00:30:05
    scalability things like that but really
  • 00:30:08
    it's just one big smear and so I think
  • 00:30:09
    what's really important here is kind of
  • 00:30:11
    within your own teams within your own
  • 00:30:12
    especially your media teams there's
  • 00:30:14
    really small cohorts figuring out what
  • 00:30:17
    kind of engineer you're working with
  • 00:30:18
    it's important because you're working
  • 00:30:20
    with someone who might have a design or
  • 00:30:22
    product background thinks a little bit
  • 00:30:24
    of the product they might be able to be
  • 00:30:25
    an ally in some ways or give you some an
  • 00:30:27
    interesting sounding board for some of
  • 00:30:29
    your ideas from an engineering
  • 00:30:30
    perspective the folks that you know lean
  • 00:30:33
    a little bit deeper in the code they
  • 00:30:35
    tend to do exactly what you tell them to
  • 00:30:37
    do so you need to make sure to remove
  • 00:30:38
    that to think about that and think about
  • 00:30:40
    kind of the information that you're
  • 00:30:42
    giving them and noting that they might
  • 00:30:44
    they might interpret it very literally
  • 00:30:46
    that middle area if you do ever find
  • 00:30:49
    those people they are magical and should
  • 00:30:51
    hold on to them because everyone will
  • 00:30:52
    learn a lot from them I've only worked
  • 00:30:54
    with a few and I just I wish I could
  • 00:30:56
    continue to work with him forever so
  • 00:31:00
    bringing engineering in early we tend to
  • 00:31:04
    approach prog develop with the system in
  • 00:31:05
    mind attina covered a lot of this and
  • 00:31:07
    I'm gonna keep kind of harping on the
  • 00:31:09
    system thing it's so important to kind
  • 00:31:11
    of immediately start thinking about
  • 00:31:12
    what's the system what's the design
  • 00:31:13
    system I don't mean just a component
  • 00:31:15
    library what are the pieces that make up
  • 00:31:16
    your model and then when you hope when
  • 00:31:21
    as Tina said when you bring them in
  • 00:31:22
    early it does help kind of uncover some
  • 00:31:25
    of those weak points for engineers
  • 00:31:27
    especially we might be familiar with
  • 00:31:30
    some parts of the code base that a
  • 00:31:32
    little bit hairy we might know about
  • 00:31:34
    some api's or you may have a feature
  • 00:31:35
    that seems really seems really
  • 00:31:38
    straightforward but not an engineer is
  • 00:31:40
    just terrifying cuz we know that that is
  • 00:31:41
    to go and touch this other part of the
  • 00:31:42
    code base that people haven't looked at
  • 00:31:43
    in six months so when you bring them in
  • 00:31:45
    early you really do kind of help focus
  • 00:31:47
    on those weak points and you can get
  • 00:31:48
    ahead of them as Tina said they can kind
  • 00:31:52
    of their engineers I think are kind of
  • 00:31:54
    scared by nature we're always scared
  • 00:31:55
    about like how people are gonna use
  • 00:31:56
    these things and where things will break
  • 00:31:58
    so just earlier the better
  • 00:32:02
    running these parallel explorations Tina
  • 00:32:04
    do amazing job of covering this keep
  • 00:32:07
    saying this consider the system asked
  • 00:32:10
    and asked the engineer which parts worry
  • 00:32:12
    them I love when people ask me this
  • 00:32:13
    question not just designers but everyone
  • 00:32:15
    when folks ask you what worries them
  • 00:32:16
    they will tell you there's probably a
  • 00:32:18
    lot of parts if the nothing worries them
  • 00:32:21
    then ask again because they're wrong and
  • 00:32:25
    a strong design system if you have
  • 00:32:27
    established it makes this prototyping
  • 00:32:28
    face so much more seamless we're getting
  • 00:32:30
    closer there slack is really pushing
  • 00:32:33
    hard to kind of start establishing some
  • 00:32:34
    of these patterns now that we've had a
  • 00:32:36
    few years to kind of build up to the
  • 00:32:37
    scale we're at we're kind of looking
  • 00:32:38
    back now and starting to look at what
  • 00:32:40
    what's the common DNA that make up these
  • 00:32:42
    things and as we're starting to pull all
  • 00:32:44
    these components
  • 00:32:45
    you know we're refactoring we're
  • 00:32:46
    bringing these things that were
  • 00:32:47
    disentangling the code I found that as
  • 00:32:50
    I've started prototyping you know when
  • 00:32:51
    we do a hack thing or something like
  • 00:32:53
    that it's so much quicker if there's
  • 00:32:54
    already a library of things that you are
  • 00:32:56
    using so if you've established a strong
  • 00:32:57
    design system if you're really focused
  • 00:32:59
    on that it makes this phase a lot more
  • 00:33:00
    seamless so clearly communicate the
  • 00:33:06
    specs and polish build for the system
  • 00:33:09
    you can keep keep that system in mind as
  • 00:33:11
    you're building these things and as
  • 00:33:12
    you're communicating don't just send you
  • 00:33:14
    know don't just send something that
  • 00:33:15
    maybe it was greenfield but make sure
  • 00:33:17
    that you look at those things and you
  • 00:33:19
    think about like what are the parts of
  • 00:33:20
    the system that this comes from what are
  • 00:33:21
    other familiar parts of the UI where
  • 00:33:23
    there's the shared functionality
  • 00:33:25
    and think like a computer I don't want
  • 00:33:29
    to say that engineers are robots but
  • 00:33:30
    they do build software for computers and
  • 00:33:33
    we all actually all do and so when I say
  • 00:33:35
    think like a computer I'm just gonna use
  • 00:33:37
    a real real tired analogy here folks are
  • 00:33:40
    probably familiar with this analogy
  • 00:33:41
    whenever people talk about component
  • 00:33:43
    libraries so we have your finished
  • 00:33:45
    feature it's perfect
  • 00:33:47
    it's beautiful Castle it's got this
  • 00:33:49
    drawbridge it goes up and down and hurt
  • 00:33:51
    and some soldiers and things like that
  • 00:33:53
    and yeah there's some familiar parts
  • 00:33:55
    that are common in a lot of sets there
  • 00:33:56
    might be some unique parts but when you
  • 00:33:59
    start looking at it if you are kind of
  • 00:34:01
    keeping the system in mind we start
  • 00:34:02
    looking at you kind of start breaking it
  • 00:34:03
    down into what it actually looks like
  • 00:34:05
    what are the parts that make this thing
  • 00:34:06
    up maybe there's some great braid
  • 00:34:08
    there's a lot of great excerpts and blue
  • 00:34:09
    bricks you start thinking about like
  • 00:34:11
    what are the what are the moving bits
  • 00:34:12
    what are these things where the where
  • 00:34:14
    the shared where's the shared bricks
  • 00:34:16
    that everyone has been using and can we
  • 00:34:18
    just reuse some of those things when you
  • 00:34:20
    start breaking you down to those things
  • 00:34:21
    you actually go all the way down to the
  • 00:34:23
    very root level and a designer looks at
  • 00:34:26
    this like yeah here's a here's a really
  • 00:34:27
    common this could be like the button of
  • 00:34:29
    your system right this thing is used
  • 00:34:30
    everywhere it's got two pegs it's this
  • 00:34:32
    tall it's blue but you know a designer
  • 00:34:36
    may look at this and say yeah that's
  • 00:34:37
    that's that's the component but
  • 00:34:39
    engineers even at this scale still look
  • 00:34:40
    at these things and just break it down
  • 00:34:43
    so you know they're saying okay so
  • 00:34:45
    that's two millimeters from the side
  • 00:34:46
    that's eight millimeters we'll wait wait
  • 00:34:47
    wait wait this thing says eight
  • 00:34:48
    millimeters but you know on this on this
  • 00:34:50
    back over here this is two so you know
  • 00:34:51
    what is this so the sooner you build
  • 00:34:53
    that shared understanding and the sooner
  • 00:34:54
    you start kind of looking at those base
  • 00:34:56
    building blocks the easier it is to
  • 00:34:59
    actually start building around that so
  • 00:35:02
    you know and you know with that in mind
  • 00:35:03
    like how does that how does that finish
  • 00:35:04
    spec how does that finish castle break
  • 00:35:06
    down into these building blocks and then
  • 00:35:08
    when you go all the way to the bottom
  • 00:35:09
    there how does changing those small
  • 00:35:11
    components how does that affect the
  • 00:35:12
    overall system when you go back and you
  • 00:35:13
    say well actually maybe this brick is a
  • 00:35:15
    little bit different don't just fix that
  • 00:35:17
    one brick and then call it a day think
  • 00:35:18
    about like how are other teams using
  • 00:35:20
    this thing how is everyone looking at
  • 00:35:21
    this component and how can it actually
  • 00:35:23
    be built you know have a little bit more
  • 00:35:26
    functionality that can be you know maybe
  • 00:35:28
    you want to add some more properties to
  • 00:35:29
    it maybe you want to make it you want to
  • 00:35:32
    be able to change the color of it so how
  • 00:35:34
    does changing that small component of
  • 00:35:35
    the overall structure and when you do
  • 00:35:36
    that then that thing has more
  • 00:35:38
    functionality
  • 00:35:39
    so I just encourage everyone just keep
  • 00:35:41
    thinking about that system think about
  • 00:35:42
    the things that make up your you eyes
  • 00:35:44
    think about what's shared what's new and
  • 00:35:46
    then figure out how to standardize that
  • 00:35:49
    and finally collaborate on documentation
  • 00:35:52
    Tina's talking about this very in there
  • 00:35:54
    this is something we're doing right now
  • 00:35:56
    this is actually a very new spec I've
  • 00:35:58
    kind of been designing the guide on my
  • 00:36:01
    own just when I can I'm so thankful now
  • 00:36:03
    to have some designers kind of come in
  • 00:36:05
    and actually color my own ideas but what
  • 00:36:07
    design looks for when they're describing
  • 00:36:09
    these things so in my case I come to
  • 00:36:11
    these things I want to know how do i how
  • 00:36:12
    do i implement it what's the code what
  • 00:36:15
    are the requirements what properties
  • 00:36:16
    does it need designers have to consider
  • 00:36:17
    things like accessibility reuse they
  • 00:36:21
    might want to talk about font size icons
  • 00:36:22
    what are these things that you need to
  • 00:36:23
    consider when you collaborate on
  • 00:36:25
    documentation it's not just that you're
  • 00:36:27
    kind of building these standards on your
  • 00:36:28
    own you actually put them together and
  • 00:36:30
    when you do that you both have a stake
  • 00:36:31
    in the game it means that you're both
  • 00:36:34
    you're both vested in this you're both
  • 00:36:36
    sharing this thing and you're actually
  • 00:36:37
    both referring to this thing when it's
  • 00:36:38
    done and that's kind of that's what
  • 00:36:40
    we're getting to now where we've we've
  • 00:36:42
    got designers all kind of collaborating
  • 00:36:44
    on these things and actually talking
  • 00:36:45
    about these components in the same way
  • 00:36:46
    which is so exciting for me and so and
  • 00:36:49
    now it's a matter of you know making
  • 00:36:51
    sure that all sides are kind of equal
  • 00:36:53
    say and and how this should be crafted
  • 00:36:55
    and equal ownership of making sure that
  • 00:36:57
    it's maintained and pushed forward so
  • 00:36:59
    and so that's my two cents Thanks I'll
  • 00:37:02
    give it to Tina to wrap up so just
  • 00:37:15
    wanted to revisit the common challenges
  • 00:37:16
    so hopefully some of the things you've
  • 00:37:19
    heard will help address some of these
  • 00:37:21
    issues that we all experience and I hope
  • 00:37:23
    that you know at the end of this we mean
  • 00:37:26
    in the next week the next month try one
  • 00:37:28
    of these things like have a conversation
  • 00:37:30
    with it with an engineer at the very or
  • 00:37:33
    as early as you can for your next
  • 00:37:34
    project even if feels kind of
  • 00:37:35
    uncomfortable just to kind of how it
  • 00:37:37
    goes run ahead design sprint even like
  • 00:37:39
    half a day is plenty of time try it out
  • 00:37:43
    it's pretty low cost and I think you'll
  • 00:37:45
    get a lot out of it start a design spec
  • 00:37:49
    without red lines just words I
  • 00:37:52
    and see how it forces you to break
  • 00:37:54
    things down into the system McGarrett
  • 00:37:56
    wants us all to remember and lastly and
  • 00:37:59
    think this is the most important one
  • 00:38:00
    like look for your engineering design
  • 00:38:02
    advocates you maybe you already know who
  • 00:38:03
    they are
  • 00:38:03
    just like topic them a little bit more
  • 00:38:05
    about how you can help each other or you
  • 00:38:08
    know just look around your company and
  • 00:38:10
    see the design the engineers are like
  • 00:38:11
    willing to spend extra time fixing the
  • 00:38:13
    design polished bugs and then just form
  • 00:38:15
    a good relationship with them because
  • 00:38:16
    that will really help you get to that
  • 00:38:19
    last bit of craft and polish that is
  • 00:38:21
    really really hard yeah cool
  • 00:38:23
    so thank you
  • 00:38:25
    [Applause]
Etiquetas
  • Collaboration
  • Design
  • Engineering
  • Product Development
  • Communication
  • Slack
  • Design Strategies
  • Engineering Advocate
  • Specifications
  • Team Dynamics