00:49 Hey, good to see you.
00:49 Thanks for coming.
00:50 This is another episode of wireframe.
00:52 And today I’m going to be talking about handoffs.
00:56 All right.
00:56 So something a little bit different today because someone reached out to the
01:00 design system Slack channel, looking for some feedback about the handoff process
01:06 and I DM that person and And they sent me a whole bunch of questions that they
01:10 said I could answer either in a loom or even in a video call, but I said, what
01:15 the heck, let me just do it on a podcast because I think these are great questions.
01:19 I did skim over the questions.
01:22 So I have a general gist of what they’re asking about, but I didn’t
01:25 actually read them in their entirety.
01:28 So I’m going to be reading them out.
01:30 In this episode here.
01:32 And I’m going to be basically giving you my answer off the dome.
01:35 There’s nothing here that I’ve prepared to answer these questions about.
01:39 So everything that I’m going to be talking about is really just what’s
01:42 off the top of my head when it comes to the handoff process, which is
01:46 what all these questions are about.
01:47 All right.
01:47 So let’s get started.
01:49 First question is what does an ideal design handoff process look like
01:54 from a development perspective?
01:56 All right.
01:57 So the ideal one, something that I would like to see.
02:02 If a designer was giving me some material for me to build would be specifications
02:08 that use design system pieces.
02:11 So we’re talking about the tokens that I’m supposed to be using to
02:14 compose these things all the different types of states that we considered.
02:20 And that’s not just hover and active.
02:21 We’re talking about things like empty state or first time user experience stuff.
02:26 All the different considerations that Have been accounted for
02:30 that would be really good.
02:31 Additionally potentially some accessibility things, for example
02:35 what could be announced in the flow of this particular thing
02:39 that I’m going to be building.
02:41 I’m sure that the question is probably based on trying to build
02:44 applications or products or features.
02:46 Of course, I’m coming from a design system angle.
02:48 But again, you know, trying to relate.
02:52 The thing that I’m about to build with existing pieces as much as possible is
02:57 going to be the thing that I really want to see because then we identify exactly
03:02 the stuff that I do need to build, right?
03:05 So we imagine that there’s going to be a lot of these resources that are
03:08 already in the system that are already identified in this handoff in this
03:12 design, and then that’s going to be.
03:14 You know, one unit of work that should be, of course, easier because
03:17 it’s all design system resources.
03:19 And then there’s an additional, of course, unit of work that may be novel
03:23 or unique to this feature that may not be covered entirely by the design system.
03:28 So knowing how much additional work that I’m going to need to do in order
03:32 to build this particular feature up front is going to be really great
03:35 because the more that the system is not being used, the more that I will
03:40 need to build More custom and that’s going to just take longer time, right?
03:44 That’s the, the beauty of design systems is that there should be resources
03:48 that you can use very quickly to then build Experiences very quickly, right?
03:54 So that’s what I’d really like to see.
03:55 That’s the ideal state is using all the system resources.
03:59 All right.
03:59 What are the most common pain points when receiving a design?
04:02 Well, kind of just mentioned that, right?
04:04 It’s having a design that doesn’t use the design system.
04:09 Just plain and simple, right?
04:10 Where you don’t know where these numbers came from, where these colors came from,
04:15 you know being inconsiderate about other users, other brands that might be using
04:20 this, this experience you know, that, that kind of thing where I’ve seen many
04:25 times in design that folks are building a.
04:29 Perfect experience, right.
04:31 Or the, or what they believe is the perfect visual, right.
04:35 And not considering maybe even mobile, right.
04:37 I mean, it sounds wild for 2024 where people aren’t even considering
04:41 mobile, but that does happen, right.
04:42 I mean, especially in an art board with an infinite canvas, you would love
04:46 to just, you know, put all these very interesting things on it and people
04:51 sometimes forget that you’re really trying to be solving user problems.
04:55 And with that.
04:57 There ends up being a lot of conflicts because, you know, especially a user
05:01 professional like myself, when I see something like that, I get upset, right?
05:06 What is the purpose of me doing this work?
05:08 I, I need to know, right?
05:09 What, why, why did we decide to do this direction when it isn’t obvious
05:14 to me that it’s, you know, should be the right direction, right?
05:17 It’s just, sometimes I, I feel that we’re left out right from as developers
05:22 that we don’t know the entire story about where this design came from.
05:25 And I think designers would have a lot better time in the handoff
05:29 process when you provide all of that data up front, right?
05:33 Who did you talk to you know, what users, what designers, what
05:36 parts of the team did you talk to?
05:37 I think all of that stuff when it’s missing is hugely a pain point when
05:42 that handoff, of course, comes in.
05:44 I’m trying to think about maybe what other materials might be pain points.
05:53 I mean again, if you don’t have the design system references
05:56 in there, that’s a huge pain.
05:58 Any other pain points that I have?
06:01 Yeah, I think it really just comes down to the communication, right?
06:03 If there’s a lack of communication between design and development, right?
06:07 You don’t know where this information came from or where this design is meant
06:14 to go or, or what it’s meant to solve.
06:16 And you’re kind of in the dark and you, it’s like the throw it over,
06:19 the fence and here you go, developer, good luck Godspeed, that’s not great.
06:24 Right.
06:24 You want to have that collaborative experience to like work together.
06:27 I’m reminded of Brad Frost and Dan Mall doing a talk at Clarity years ago, I
06:31 believe talking about the hot potato process 1 where they’re basically going
06:34 back and forth between design and development, trying to get, you know,
06:38 ideas flowing to then, you know, make an experience that’s going to work.
06:43 With, you know, a couple more cooks in the kitchen.
06:46 I’m not talking about a lot of cooks here.
06:48 We’re just talking one designer, maybe one developer that, you know, work together.
06:52 I think that’s a really better handoff process.
06:55 All right.
06:56 The next question is what do you wish designers understood better about the
07:00 development side of the handoff process?
07:03 Okay.
07:04 So this comes along with a hot take and the hot take that I’ve
07:08 been, I actually have a blog post that’s like sitting and marinating.
07:13 And the title of the blog post is, I think it’s designers should code.
07:19 So let me explain, and I’m not going to go into all of that, into the blog
07:22 post that, that may or may not show up.
07:24 The general gist about this is that I believe that People who understand their
07:30 medium in art or design do better than folks who don’t so What do I mean by that?
07:37 If you are a painter then you Will be more effective at your craft if
07:45 you understand how your paint is affected by the canvas and vice versa
07:50 right how the canvas is affected by the paint and Choosing the right
07:53 paints for the right canvas and all of that kind of stuff, right?
07:56 So all of your materials understanding your materials It’s it’s not a
08:00 matter of you making your own canvas or making your own paint.
08:04 It’s a matter of knowing What materials to use and when right?
08:08 So the more that you know about your Materials the better you will be at
08:15 what you do now transferring that over to digital design as we know it today
08:20 The folks that know the designers that know HTML and CSS Will do better off in
08:26 my opinion than folks who don’t , and it shows, I think, I mean, we see
08:31 this with UX engineers and design technologists and the like, right.
08:34 Those are the folks that can really you know do both sides of this kind
08:38 of craft of design and development.
08:40 Right.
08:40 So.
08:41 The more designers that understand development, even in a small
08:47 slice, I think that that would be beneficial just overall, right?
08:53 And that goes both ways, right?
08:55 Developers should also understand design, right?
08:58 They should understand user experience and how that feels.
09:01 Sometimes I feel like that’s not the case.
09:03 I mean, Look at web pack for the developers out there.
09:07 Web pack is such a disaster.
09:09 I’ve avoided for my entire career.
09:12 And I’m very thankful for things like Vite out there that just suddenly work.
09:17 And I use that in the background of Astro and that’s why, how I know about Vite.
09:21 Yeah, I mean, I, I imagine there’s lots of things that are meant to improve
09:27 developer experience that just don’t.
09:30 You know, there’s lots of different technologies that claim to be
09:33 better in a particular aspect when they really are just more
09:37 configuration and wild documentation.
09:40 I mean, you know, I think about, you know, AWS or GitHub’s documentation
09:44 and how, Vast it is and just jarring.
09:47 It is to, to go around.
09:49 And I could see that being a barrier for designers just generally speaking,
09:53 but it’s a barrier for me too.
09:54 You know, it’s just it’s not fun.
09:56 But anyway, I think designers understanding how, how to code just how
10:01 that , Operates is going to be beneficial.
10:03 My wife is a designer with a master’s in design and she knows a little bit of code.
10:10 I don’t think that was part of her curriculum, but she knows how
10:12 to go into dev tools and change a couple of CSS properties.
10:15 That’s fine.
10:15 She could write a couple of lines of HTML and understand, you
10:18 know, how that renders on a page.
10:20 So that’s all I’m really asking for designers to do.
10:24 Other things that I wish designers understood about the development side.
10:27 Well, I guess another hot take on this is, is that developers can do just
10:33 about anything that you want them to do.
10:35 Okay.
10:35 So if some developer tells you, no, they’re half telling the truth.
10:42 And I say that because there are trade offs with every decision that we make
10:46 when it comes to development, right?
10:49 Whether it comes to performance or you know, resources that we
10:53 have to even try to build on.
10:54 You know, consider building something depending on how complex it is, you know,
10:58 so and performance is actually one of the big things that I’m thinking about
11:01 it because like you can imagine some designer asking for six different fonts
11:05 to be loaded on the page because, you know, that’s the style that they want,
11:09 maybe old style movie poster with lots of different typography and As you might
11:13 know, the more fonts that you load in the page, the more requests that you
11:17 have to make for different assets and the heavier the page ends up being,
11:20 you know, and granted, like, are there, you know award winning sites that are
11:24 out there that have that loading screen to come up to then enter the site?
11:29 Yes, that exists, but you may also know that every millisecond
11:34 that Amazon takes to load is dollars off of their bottom line.
11:39 So there is a balance, of course, between that, engaging experience
11:44 and one that is just meant to, to get the user to end at a goal, right?
11:51 So there’s a balance between that you have to always pay attention to.
11:55 And I would hope that designers understand that that’s what we’re trying to balance.
12:01 Is that it’s not that we Don’t want to do the work or cool work or
12:05 amazing work interesting stuff that could be coming out of this work.
12:09 It is a matter of thinking about.
12:12 Things systematically.
12:13 That’s what developers honestly do.
12:14 We’re thinking about scalability, how easy.
12:17 It is going to be able to maintain and, and update this this change
12:20 that could be happening here.
12:22 So something to just pay attention to, like, you know, we want to do the stuff.
12:26 That you’re doing, but we want to do it in a way that’s going
12:29 to be maintainable over time.
12:31 We do have to maintain this code after all, right?
12:33 This is the stuff that the users are logging into that are using on a
12:36 regular basis, and we need to return to it to update it for whatever reason.
12:41 It’s not something that we can normally just ball up and throw out.
12:45 Right.
12:45 We usually have to maintain this stuff.
12:47 It’s a little bit different from design, right?
12:48 We will just kind of create a new art board to start fresh.
12:51 Like that’s, that’s cool.
12:53 But it’s a lot more resource intensive on the code side.
12:56 So probably something else that would be helpful.
12:58 And I’m sure there’s other things that would be really helpful
13:00 too, for designers, but those are the two things that are coming.
13:03 Off the top of my head…
13:04 how do you think about the handoff process overall?
13:08 Do you think, for example, that development and design teams should
13:12 aim for more of a design ops approach?
13:15 Interesting.
13:16 Okay.
13:17 So first off, I want to talk about the word design ops and I
13:21 originally understood design ops as.
13:26 Person or team who would unblock design unblock design could mean
13:33 a lot of different things Right when I first learned about the term
13:37 I’ll say five or six years ago.
13:39 I Understood it as okay, you know this designer who’s supposed to be sitting,
13:44 you know in figma as an example They’re gonna have a lot of Other things that they
13:48 need to take care of throughout the day.
13:50 For example, maybe they would be scheduling research studies.
13:54 So they have to be interacting with lots of different people to get that
13:57 stuff done and maybe that design ops person would help in that way.
14:02 Right.
14:02 Design ops.
14:03 I’ve seen it more recently where that person is maintaining the
14:06 design system and its libraries.
14:08 So, you know, Figuring out the best way to work with Figma and that kind of thing.
14:13 So I’ve seen that as well.
14:14 So I just want to kind of like mention that design ops could be kind of
14:18 a multifaceted area and it might depend on the team or organization
14:24 about what design ops might mean.
14:26 Okay.
14:27 But how do you think about the handoff process overall?
14:30 And aim for design ops approach.
14:32 Well, I guess that, that matters about how design ops would interface with
14:37 the handoff and I’m not sure how much they would be involved in the handoff.
14:47 So traditionally, right?
14:48 Traditionally, you would have a designer working on a particular design, particular
14:52 feature, whatever that is, and that would be handed off to the development team.
14:56 Just kind of like, you know, maybe there’s a, you know, handoff meeting, right.
15:00 These talk about, you know, what things are going to be changing,
15:03 what things to pay attention to, what things are less important.
15:07 But that goes right to developers and I’m not entirely sure where the design ops in
15:12 this question would kick in in that way.
15:15 If in the ideal approach, right, where they’re handing off parts from the
15:19 system, then maybe it does go through design ops because maybe design ops
15:25 is in a place where they’re validating how systematic this design is.
15:32 That’s a possibility, but again, I’m not sure exactly where the design ops
15:37 part of it comes into this question.
15:39 The question again is just, how do you think design ops About how do you think
15:44 about the handoff process overall?
15:46 I think it would be like, what do you think about the process overall?
15:50 And as it is today, where I’m working with designers, I don’t enjoy it,
15:59 but I’m familiar enough with the expectations, especially as a, you
16:04 know, a trade UX engineer, I communicate a much better with designers than
16:09 I think many other engineers might.
16:12 So I think I have a little bit of an upper hand there.
16:14 But past that, I’ve seen many, many engineers show up in a support
16:18 channel asking questions about design that don’t follow the system.
16:23 And that’s, I think the big problem that we have, right?
16:26 If you’re not following the system and you have to build things from scratch, there’s
16:29 going to be a lot of questions about how I might build something because it doesn’t
16:33 look like this is part of the system where I don’t know if it’s part of the system.
16:37 So that’s been a big problem.
16:39 All right.
16:39 Next question.
16:41 How does a design system help facilitate the design handoff process?
16:44 Well, I guess I’ve been talking about that the whole time, right?
16:47 That handoff process, if we are identifying the pieces that are part of
16:51 the system immediately, then it’s much easier for the developer to grab those
16:55 pieces from a library that hopefully exists and then start building these
16:59 experiences and then identify exactly what parts of the experience they might
17:04 need to build custom or otherwise You know, dive in deeper about, right.
17:08 Cause the more that’s already prebuilt, the faster this thing comes out.
17:11 Right.
17:12 So I already kind of mentioned that.
17:15 All right.
17:15 The next thing is when you’re handed design files, do you ever get lost in
17:22 parentheses in complex file systems, non standardized terms, et cetera.
17:27 Lost in design files.
17:29 Of course, of course you’re lost in design files.
17:33 I imagine, you know, with dev mode in Figma.
17:37 Someone who may be in a design ops role might’ve curated that,
17:42 that file so that a developer couldn’t traverse it a lot easier.
17:45 I remember seeing the demo of it in last June where they were
17:49 demoing how you might mark certain.
17:53 Artboards that are important to the developer so that when a developer
17:57 goes into dev mode, that all they need to see is those particular
18:01 screens that they’ll be building right where, and as a designer, you
18:04 might have an art board that’s full of explorations and presentations and
18:09 other resources that are just going to be all over the place, right?
18:12 It’s just kind of like a mess sometimes that might happen.
18:15 And.
18:16 In order to organize it a little bit better Figma is able to like
18:19 mark out those things, but if it’s disorganized, of course you’ll get lost.
18:23 I mean, that’s anywhere.
18:24 I mean, we get lost in code all the time as well, right?
18:27 You go into somebody else’s repo and you’re like, what does this even do?
18:30 Right.
18:30 How does this even work?
18:32 If it’s not something that you’re familiar with.
18:34 So it’s very common for that to happen to get lost in a design file or, or, or even
18:40 development in, in the file structure.
18:42 I wonder a little bit now I’m thinking about it how we might
18:46 attempt to solve for that, right?
18:50 My gears are turning a little bit.
18:51 I have to definitely think about that because I think there’s a world
18:54 where wayfinding in files that we are creating like creative files.
19:03 There might be something there, honestly.
19:06 Yeah, I don’t know.
19:07 Something to think about on top of all the other things that I’m
19:09 thinking about you know, 12 at a time.
19:12 Okay.
19:13 The next thing here is do you typically feel comfortable
19:19 in the tools designers use?
19:21 No, absolutely not.
19:23 So fun facts, I’m invited.
19:27 Most recently to a couple of the sneak previews for Figma’s new releases.
19:32 And I find that funny because I’m probably the only person on these calls
19:38 that doesn’t use their application.
19:42 Now when I say doesn’t use the application, I, I mean, I do
19:45 click links that go to Figma.
19:47 I do traverse Figma files, but that’s basically the extent of
19:51 how I use Figma because I don’t need to, I’m a UX engineer, right?
19:55 So if I’m going to design something, I’m going to design it in like
19:59 CodePen or just in code in general.
20:01 There’s no reason for me to go into a place that doesn’t bring me A
20:09 finished product out of it, right?
20:11 Something that is actually going to work.
20:13 So I find it to be like unnecessary for me to go into that
20:19 application on a regular basis.
20:21 I have in the past built Figma plugins.
20:24 So I’m familiar with that ecosystem.
20:26 But that’s been a while now.
20:28 I actually haven’t been in it for a while, but past that.
20:31 No, I mean, I’m not a person who’s Using those tools.
20:36 And I think it’s not important for a developer to use those tools.
20:46 It’s important for them to be able to traverse files, right?
20:49 They need to be able to see the things that they’re about to build, the
20:52 specifications that they need to pay attention to, to build it properly.
20:57 Like that stuff’s important, right?
21:00 I’m a think about like, you know, an architect building something in CAD and
21:04 then printing it out as a blueprint.
21:06 And then just handing off the blueprint, you know or even just showing a person,
21:11 the CAD model and having them, you know, walk through the CAD model.
21:14 Right.
21:14 The person who’s.
21:16 Walking through the CAD model doesn’t know or need to know how
21:20 to use CAD in order to do that.
21:21 They just need to know how to traverse to get a feeling of how this building
21:25 and the structure is going to be built.
21:27 So they don’t need to know all the idiosyncrasies of
21:30 how you might build in CAD.
21:33 So yeah, I don’t feel comfortable and that’s fine.
21:36 It’s totally fine.
21:37 Totally okay to not be in those design ecosystems.
21:42 And again, that goes all the way back to what I was talking about, where,
21:45 you know, the designer should code and developers should, should learn design.
21:49 Right.
21:51 When I say that in terms of not knowing the tool inside and out, yeah, you
21:56 should know how to traverse Figma.
21:58 You should know how to be able to zoom in and zoom out.
22:01 You know, be able to leave comments like that’s like, fine.
22:04 That’s what you should be able to learn how to do.
22:07 But trying to figure out, oh, I don’t know.
22:11 How to do auto layout.
22:14 Not important, honestly, for a developer, right?
22:17 We’re just going to put a flex box on the thing and call it a day.
22:19 We could do that in two lines of code while you designers are messing
22:22 around with settings, I guess.
22:24 All right.
22:25 Next one is, does the handoff process ever lead to antagonism
22:30 between developers and designers?
22:31 Absolutely.
22:33 Absolutely.
22:35 Goodness gracious.
22:36 Yeah, of course.
22:37 Right.
22:37 We’re, this is not a dream world we’re talking about here.
22:39 Of course it does.
22:41 Right.
22:41 For all those things that I talked about, you know, when we’re have designers that
22:45 are not talking to developers, they’re not bringing them in the conversation, not.
22:49 Exposing all of the pre work that was done to get up to this final decision, right?
22:56 You know, as a designer, I feel like it’s important for you to, to kind of validate
23:01 your direction right through data, right?
23:05 That’s the whole thing that that we’re trying to do is solve user problems.
23:08 So let’s identify what the user problem is that we were solving and present
23:14 that to your team, right, and say, Hey, I went through all of these steps
23:19 and this is what came out, right?
23:21 And of course the, the team developers, PMs, all of these folks are going to
23:27 put a lot more faith in this design.
23:30 If they see all of that work beforehand being done, right.
23:34 As opposed to a design, just coming out of nowhere, just like design, I made it.
23:41 You go, well, okay, why?
23:45 Right?
23:45 Like we don’t, we don’t know where this came from.
23:47 Were you just bored?
23:48 You just decided, oh, okay, this is suddenly yellow now.
23:51 Like, where is, where did this come from?
23:53 Right?
23:53 The more that you provide in terms of the information, the less antagonism
24:00 I think you’ll find for developers.
24:03 Additionally, I’ll say it several thousand times in this episode the more that you
24:08 use the system, the better you will be.
24:10 Right?
24:11 The less that you use the system and the more snowflakes that
24:14 appear in this design are.
24:16 Otherwise unidentified in the system, the more the developers are going to go.
24:21 Why couldn’t we just use X thing out of the library?
24:25 Right?
24:25 Oh, well, it’s kind of like that, but it’s different.
24:28 Why?
24:29 what is it different for?
24:31 Right?
24:33 And it’s entirely possible that the library isn’t fully featured
24:36 enough to support everything that, that might be done.
24:41 But I imagine if you got a library of, let’s say, 30 components that
24:47 would be shared across all major design systems, if you got that
24:50 core set, you probably can build any interface you want, more or less.
24:56 For the most part, right?
24:57 I mean, you’re going to have certain special features that might not
25:00 be covered by that kind of stuff.
25:02 Again, the less that the designer uses the system, the more stress
25:08 that the developers are going to have by trying to fill in those gaps.
25:13 So yeah, of course there’s antagonism.
25:15 Oh my goodness gracious.
25:16 So, you know, I could call out a dozen different things over the course of
25:20 my career that I just was like, I, why can’t we just make this easier?
25:25 You know, keep it simple.
25:26 I believe this is the last question.
25:29 Does the typical handoff process feel efficient or is it a pain point?
25:33 All right.
25:34 The answer is, there’s a lot of answers here.
25:41 All right.
25:42 So I’m thinking about the current process that we, that I use right now.
25:47 at my day job.
25:48 And the current process that we have, more or less, is that I have a fairly
25:54 good working relationship with the main designer on the design system team.
26:00 And we have a regular one on one on Fridays, just before adult
26:04 beverage time, where we spend about an hour talking about whatever.
26:10 The whatever might be work related.
26:13 It might not be work related.
26:14 I remember he was talking about his sheep last week, which was cool.
26:18 So.
26:19 Yeah.
26:20 So in these meetings, we may typically go over some sort of
26:25 design that might be coming up and to, you know, share thoughts.
26:29 Similarly, I might have some idea from the engineering side that I might want
26:33 to collaborate with, and that’s another place where we bring that stuff up.
26:37 So that usually goes well.
26:40 From there, depending on whose initiative it is.
26:46 If it’s designs initiative, usually what happens is that the designer
26:50 will go into a Figma or start, you know, doing explorations or
26:54 otherwise, you know, trying to figure stuff out they will typically have
26:58 meetings that bring more people in.
27:00 So other designers and developers to get more feedback.
27:03 And then finally, there’s like a handoff kind of thing that happens.
27:07 And that ends up being a prioritization.
27:11 As a ticket through our PM that says, okay, this is a thing that we’re
27:15 going to put into the next sprint or prioritize just in general, and at that
27:20 point, it begins a development process.
27:23 And I got to pause at the development process for a moment, because if it’s
27:28 something that’s dev related, that affects design, what I typically do, and what we
27:33 have been now pushing on the team is to write an RFC or basically a doc that says,
27:40 here’s the plan on what we want to do.
27:43 And when we write this plan, we are trying to describe either changes or updates
27:49 that we want to make to the system.
27:51 We attempt to provide visuals as, as necessary, as best as we can.
27:55 Luckily, my design partner is familiar with the code.
27:59 He’s written a couple of small apps himself or websites.
28:02 So putting code in there actually is not a problem.
28:05 But then we write that doc and then we shop that doc around
28:09 the organization at large.
28:11 We try to get as much feedback as possible in terms of what we might
28:15 be changing because it will affect everyone from a library standpoint.
28:19 We want to make sure that it’s going to be helpful to folks that are
28:23 expecting it to be helpful and useful.
28:26 For, you know, the, the organization of all.
28:28 So that’ll go through some rounds of review and revisions,
28:32 of course, eventually.
28:33 We will get that kind of merged as a doc and then we will build to that.
28:39 And that’s what I talk about the development process, right?
28:41 So there’s a ticket that’s of course made both of those cases and then
28:45 developers will build these things out.
28:47 And once the PR is done.
28:49 Usually there will be a screenshot of the changes in there, in some cases,
28:53 especially more complicated ones, we will have some sort of small meeting
28:58 that shows off like the storybook of all the different variations of
29:02 this component and how it’s meant to behave for design and development.
29:06 And then it’s public and it’s released and out in the world and hopefully it
29:12 helps people and then that’s how it works.
29:14 Could it be better?
29:15 Absolutely.
29:16 Like I said in a couple of points earlier is that you know, identifying
29:22 what the existing , design system resources are in these new designs
29:29 is going to be more helpful.
29:31 Unfortunately, what does happen often is in our system today, we
29:37 have novel concepts that end up being introduced that cause friction.
29:42 That’s what happens.
29:44 And we always ask from developer side is there stuff that can be reused here?
29:50 I’m trying to think of one thing in particular.
29:52 Oh, yes.
29:53 So, we’re considering a new, like, onboarding experience.
29:56 Like a, kind of like a Coachmark thing, if you, if you know the term.
30:00 And, one of the things I was asking is, well, we have this, Component that
30:06 shows how many steps are in the process.
30:09 And it seems like it’s only in this one spot at the moment, but I was wondering if
30:14 we expect the ability to show the number of steps for something in other areas,
30:19 I can imagine like a wizard experience where you might have different steps
30:23 that you need to go through as a customer to finally verify a final decision
30:28 right.
30:28 So you go through like steps and it’s always good to know how many steps
30:31 you’re going to be sitting in, right?
30:32 Cause if it’s only six steps, then, okay, I could finish that, you know,
30:35 in the sitting that I have right now.
30:37 But if the thing is like, I don’t know, 20 steps, so like, hold on a second.
30:41 I don’t know if I have time to even start this process.
30:43 I also recognize that, you know, if it’s only being used in this
30:46 one spot identified right now, you know, it’s, it’s the whole, you
30:50 know, Once is an instance, right?
30:55 Twice as a coincidence.
30:56 And third is a component.
30:56 As I think Dan Mall says, I might be misquoting there, but yeah, if it’s
31:01 only the first instance and yeah, okay.
31:02 We’ll build a custom for right now using pieces of course, that we
31:05 already have, you know, text and buttons and so on and so forth.
31:08 And then if we find that needs to be componentized, then hopefully we’ll
31:12 identify that, make it, make it so.
31:14 But yeah, that’s, our current typical handoff process has room for improvement.
31:20 And I think everyone’s probably does right.
31:23 I think seeing what I’ve seen on different social media platforms and
31:30 different discourse that I’ve had with folks in the community handoff is a big
31:34 sticking point that we all seem to share.
31:38 And I know that, you know, Figma is trying to.
31:41 Make things better in their ecosystem Through trying to connect things like
31:45 VScode through the platform and such like that Admittedly, I’m not entirely
31:53 confident in That direction, but I think it’s a valiant attempt certainly
32:03 so anyway, I believe that was the last question I’m gonna just double check
32:06 here Yes, that was the last question.
32:09 But you can let me know what you think.
32:12 Just, you know, tweet at wireframe.
32:14 fm on Twitter
32:15 and, yeah, let me know what you think about the handoff process.
32:18 If it’s working for you out there, if it’s not working for you out there.
32:22 I’m interested to know the results of this survey that’s popping around over here.
32:25 I do know the company that’s trying to do this survey.
32:28 I’m not going to name that company, but I’m looking forward to seeing
32:32 what changes that company makes based on this information and the
32:36 information that they’re collecting and I hope that things improve.
32:41 Honestly, just overall, I hope the, the collaboration between design
32:44 and development improves over time.
32:46 I believe that there’s definitely still some confusion of roles,
32:52 responsibilities, and things like that overall that make this a challenge.
32:58 But hopefully it gets better just overall for the whole practice for.
33:05 Everyone in design and development, everyone adjacent to these folks.
33:10 I have some optimism, let’s say.
33:15 All right, folks.
33:15 See you next time.
33:16 Thanks.
