YUI Library Open RoundTable, 20 Mar 2014

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: YUI Open Roundtable with Lauren Tsung on Working with Designers

Description

YUI Open Roundtable features discussion on topics related to YUI and front-end technologies from around the community.

A

All right welcome everybody to our next and the latest. Why why open round table we're featuring uh we're hosting um lawrence.

B

A

From the uh which team are you.

C

I'm in the media market, I'm in the homepage and verticals team, I'm a prototyper and I support monetization.

A

Cool- and we also have with us um jriptech, there's also from some of the ydm teams yep, and we also have folks who are online and various people watching on youtube, and we also have folks on our diy dev channel our yy channel and yui. Who may potentially ask questions so.

C

And we can just get things.

A

Kicked off, let me start off with just a little bit of housekeeping right now, we're in the midst of um the latest sprint for the yy project.

C

A

Let's take a look at the schedule real quickly here.

B

The development sketches.

A

um Coming up, we have uh right now on screen. 13. uh march 25th will be the code. Freeze, pull request deadline march 28th will be our code freeze april. 1St is our commit freeze, which is uh what happens after we've done a release, branch and then april. Fourth, will be the commitment, freedom or check-ins for that and april 13th.

C

A

Potential release just housekeeping there if you're watching uh via youtube, um feel free to join the found yy channel- oh yeah, marco's, watching cool and hatch. uh That's.

B

A

uh Free note: it's a freedom, so a couple folks already saying: hey: hi, lauren how's it going so marco, some folks from germany, and so let's get things kicked off um and so glad to have you here today lauren. um Maybe we could start things off just to tell us a little bit about yourself and working.

C

Sure so, currently I'm a design prototyper in the homepage and verticals team. I support monetization, um so I I did start off with a computer science background. I graduated in bachelors in that. So I did some engineering internships.

C

Prior to deciding to go into user experience- and I actually was an interaction designer for a couple of years before I decided to go back to my coding roots as a design prototyper.

C

So I'd like to think I'm somebody who can understand both sides of the house, whether it's engineering and design, and so ultimately, my goal with today's hangout session is just to just kind of talk about ways that these two disciplines can just learn from each other cool.

A

um So how long have you been in yahoo? I've.

C

Been at yahoo! Well, that's a tricky question, um so I actually started off as an intern, but I did my senior project um with yahoo. I sponsored it before it became full-time, so full-time a little over, maybe four years now, um but I've been pretty involved with yahoo since my college days so long long time now.

A

So when your first interactions uh with with uh teams at yahoo, was it on the technical side or on the ux.

C

um So I wasn't, I was an engineering team when I first started out, but I was their first interaction designer I was there for about three and a half years. um I worked on developer tools and just more internal engineering systems where I helped to streamline the user flows. For that, so I took a I took on a designer role and a really technical sort of um domain with an engineering team. I was in their engineering team and then eventually, as I wanted to explore more consumer-facing products.

C

Now, I'm more of a developer in a design team, yeah.

A

So what you mentioned, uh interaction designer? How would you um sort of characterize that versus say a graphic designer or just a regular.

C

Sure they're definitely so I'll answer that question by kind of talking about the spectrum of youtube experience. All these sub disciplines are necessary to work together like traditionally now um now when we refer to user experience or talking about combo of visual and interaction design, but all distinguished subdisciplines.

C

So I'd like to think someone who is most focused on typography or composition or or color, that's more of a graphic or a visual designer, and in my experience those who are individual design tend to be happy coming from backgrounds from like from printing, but then so they're more focused on composition, whereas interaction designers are more focused on okay. What is the user goal? What, ultimately, what do we need?

C

How does the flow need to be to to to best reach there and to understand user pain, points and needs, and they work together, because I think, having a good graphic design background gives you more visual vocabulary so that you can design interesting interactions and vice versa. The interaction informs what is necessary for the graphic design. So it's not just aesthetics, but it's actually useful under your graphics.

C

um So then, there's other. You know other people who specialize in ux, so there's researchers, obviously who host usability studies or inform the design through market research um prototypers. My role is really to rapidly. um You know, develop a prototype so that we can inform design decisions or even inform how you know how things need to be built out in an engineering scale.

C

um There's information designers who are really interested in how you know how navigationally, how how information needs to be clustered, so it's more intuitive for a user to parse through.

C

So, ultimately, there are many different ways to approach the user experience, but I think primarily having a really strong visual vocabulary through graphic design and understanding about user pain points, the interaction design they need to be together to make a good ui.

A

When you worked with some of the first teams that you're here did you run across people who uh I know for me when I first began uh developing, you know large-scale projects, you'd have people who kind of push back on. You know like like, for instance, engineers would say you know.

C

Let's just you know it's, I already know what.

A

To do, let's just go for it and you know what do we even need you guys for you know you just send us your pixels and movie times.

C

um So how do I um well I'm a little I'm a little uh lucky, because I I come from a technical background, so I feel it's easier for me to negotiate with engineers. Okay, like I like, for example,.

A

C

I have a little- I guess, a little bit of stupid. So if I, if I understand like maybe what what your api looks like or the underlying schema like, I can kind of see that all right, that's how they're going to pipe information to the ui and how can I negotiate with these sort of parameters?

C

But let's say if I, if I were speaking on behalf of any designer who doesn't have a technical background, I think ultimately there needs to be lessons taught in both sides. Designers can educate engineers hey you know. This is this is not just decoration, there's actually a utility as to why this particular color is used so because it's the likelihood of being clipped.

A

C

Then, and, and vice versa, engineers can try to inform designers okay. This is why it's not feasible, because it will break the dom somehow or.

D

C

I think so really, I think, to improve that communication or pushbacks. It's really. It has to start with teaching each other. The basics first.

A

So that leads me to like one of the questions we have on here. We have these questions about um if you send a visual vocabulary, that sort of shared between engineers and designers, because I've seen a lot of times so much like cross paths would say. Well, I thought you meant you know do this in pixels versus you know, em or I didn't realize, left alignment left a line, no matter how you resize it, or you know things like that.

C

So I can't speak for all designers. I think designers come from very different backgrounds. I come from a computer science background. Some come from printing like traditional print or even from like motion design, so they'll express in the way they kind of come from um with that said, I think, to establish patterns. It has to be built around your culture of your team, like, for example, um when I first started my design career here I was, I was directly embedded in a future engineering team, so we were building a widget library together.

C

So basically my vision for how flows need to be kind of build out. We baked that in into a design pattern, library that was built with javascript and I even had a hand in both the css and javascript a little bit at that time. So I think so, whatever your setup is how how how close how closely knit an engineering team is with designers, you should figure out what vehicles needed to get requirements out as quickly as possible.

C

So yeah, I don't know how to solve the px versus pt versus em problem. But I think if you can figure out like some pre-baked solutions and and just work from there.

A

Cool, have you had the kit? Have you been able to carry over things? You learn from one engagement to a next. In terms of like oh, I mean it's. You know it was so much easier when everyone.

B

A

From a google doc or worked from you know, whatever we're able to like I've, seen some designers who who they've come up with this really great um document like they'll, create like interaction flow diagrams and when you show the flow diagram to the you know, engineer they're like oh, this is so much better than just you know, a bunch of screens things like that.

C

um I think it depends. I don't have that where I honestly don't have that workflow anymore, because then I I just code it out now.

D

E

I design I just.

C

I just go straight to code, um but I think for some people it depends on their preference and I guess the culture of the team so for some designers they just if they want to express an interaction, they'll use, um you know their their graphics software, although they'll just print out the mocks.

C

um I I don't know of any tool that people like universally use- I mean maybe other than photoshop illustrator and maybe ponder graphical or balsamic, but I I think it depends on the culture of the team and what is necessary to happen between engineer designer.

E

So, for you guys, you guys just go and straight out make prototypes like just like actual prototypes with real code.

C

um So that tends to be my style except the designers I work with they. They show me mocks. They'll, give me the photoshop or illustrator file, and I just.

B

C

Like all right half away or if I wanted to express my ideas, I sometimes I will sketch, like literally sketch- I think that's pretty therapeutic, sometimes or or I'll use or I'll use omnigraffle. If I want to do a wireframe I'll get I'll get into what a wireframe really is in its function.

C

But, honestly, like my, my role has really been all right. Just just try to bake out the the html css and javascript as soon as possible and just be able to adapt out to a design requirement.

E

So there are things that are harder to see from just like I don't know like photoshop or illustrator, or anything like that, like, for example, like gesture interactions nowadays with people working on mobile. Those are things that you can't really like see inside like a psd file right. So how do people like represent those, for instance,.

C

Sure, um okay, so for those who don't code, I've seen and sometimes if I don't feel like coding for some reason.

B

I'll use I'll.

C

Use keynote like apple keynote or powerpoint or after effects um so yeah like, I think, any sort, there's just so many click-through prototype software out there that um that people can use to express their interactions and also um or or they can story if they don't like. If they haven't, got the time to do like a full-on clip through prototype. Your storyboarding, like you can you can show the story in which a user needs to flow through your app so.

A

When you worked on some of these projects, did you have to do like I've seen it used to be that there was like the traditional waterfall like you know,.

C

Where you can like yeah designers would go.

A

Do their design stuff and then they'd, throw it over the wall and they'd be like we used to have these big meetings where it's like, okay, the designers are going to like bless you with all the all the screens now and then the engineers take it from there. It's kind of like this relay race.

A

Did you have to do with that? Or did you have more of a sort of you know smaller psychology.

C

Okay, it's interesting. I've been on three teams now at yahoo, so just to be on the same page as you guys, so the very.

B

First team.

C

um Where I was an interaction designer I was baked in an engineering team where it was full on agile, like I was in their sprints and um so I'll talk mostly about that and when I.

B

C

And cons of that and then when I move towards consumer facing now, I'm more of a more of a dev now, but I see it's kind of water quality, so um so the the benefit of a designer being in an engineering team is that obviously there's closer knit communication.

D

C

I I was able to talk to engineers just know exact feedback on my designs, and there was a clear expectation that all right, let me just get the wireframe out right away, uh you guys can put in parallel and then maybe I can. I like help the css, so I know, like things, are pixel perfect or to my understanding, um but then the the drawback. For that, though, is that I as a designer I didn't feel like.

C

I had enough time to really think out my solution, because I felt the pressure of pushing it out right away to code, because you.

A

Had to go straight.

C

A

Code quickly, right.

C

A

C

So that's so so pros and cons of that um definite pro was great communication with the engineers now in an almost water, I'm actually relatively new to the team I'm in now, but it seems a bit waterfally right now. I like it for divial.

C

I was raised in naturals so but um I think what what's great about being in a full-on design team now is that yeah there is definitely the room to be creative and and sometimes for some for some designers. They don't really want to be told constraints. They prefer blue sky because they want to be able to explore all the edge cases and then and then narrow down based on constraints.

C

um But obviously the downside is there's not much communication with engineering and so, and I think, and something I'd like to solve now as a prototyper who can kind of speak, both languages is enabled designers just feel like they can talk to engineers as frequently as needed.

C

um So really the problem comes down to team culture and and like what what what process are using agile or what whatever flavor and enabling designers to feel like they can be creative and to explore as many options. But how can you be lean enough to to be able to bake out a prototype or a full-on product right away?.

E

So, have you ever like worked with one of these like blue sky designers, or have you yourself been a blue sky designer.

C

E

C

Hard for me to be blue sky.

E

C

I've just been trained to think in terms of constraints quickly as quickly as possible, but I do work with people who are blue sky and I think it's I think, there's merit to it. I mean my style tends to be constraints first and then go around constraints, but with the blue sky thinkers I mean, I think, they're more more strong and creating delightful experiences like for me. I think my emphasis has been more.

C

This is usable, it's tried and true, it's technically feasible, so I think there and ultimately I think, a user experience needs to be a balance, because you know you can use things that are usable but they're, probably a painful to really look at right right or an or in the long term. They're. Not just really I mean, if you think, of competing products, there's tell that are just I.

A

Was going to say yeah, it may be perfectly worked perfectly well, but competing with some other flashier product or something that's.

C

A

You know, for instance, I think uh I brought in mine like uh facebook's paper products. Now you know you could download the regular facebook app and then view your streams and things like that. When you look at the paper app, you know that's a lot of different interactions.

A

It's it has that delightful quality.

C

Sure, and and yeah I think. Okay again, I don't want to generalize too much, but in my observations, those who tend to be more blue sky, like I think they get inspired they're because they don't have constraints, they're willing to be inspired by any any interaction in the real world and I'm sure, with the paper, with a paper app like those interactions that they're those interaction paradigms are introducing that just comes from raw inspiration, I think um so yeah so ultimately yeah.

C

I think I think there there needs to I- and I think, just to just give just to give a caveat. I think it's worthy to to be creative and to go blue sky, but make sure that you're not just doing flash for flash's sake. I think I think I think aesthetics need to be tasteful and ultimately there needs to be a harmony to function and form so yeah.

A

Personally, I think uh if you walk into a room, you probably like as an engineer. I'd rather have a constraint based designer versus the blue sky, because the blue sky is going to sit there and there's a lot of eye rolling going on.

F

A

Like I can't believe he thinks we're going to be able to, like you know, rotate the device upside down.

C

And now everything.

A

You know is twice as big, and you know they come up with these crazy interactions.

C

Yeah, so it's it's an exercise for me because I'm I'm constraints oriented, but I I actually what I appreciate about a design team, ideally there's so many different thinkers on the team. Maybe someone who's coming from an architecture like like traditional architecture, background or a psychology background. Basically, I think any anyone with the lens of catching as many edge cases as possible and sometimes when you're too constraints oriented you're boxed into one type of thinking. So.

E

So let's say I'm like a product, I'm an engineer on a product team and I'm working with one of these, like blue sky designers, like if I want to like, tell them like this. This might be something that's a lot like technically harder to like implement. What's the best way to give them like feedback so that they can improve their designs without hurting their egos.

C

Again, I think it's an it's a co-educational process, um but I think maybe start with explaining to you to your designer okay. These are designs that these are some designs that we've worked out together that have worked, and maybe just go into the fundamentals of why they've worked and then started to pair out like okay with this new design you presented. This is the specific thing: that's not working.

E

That could break.

C

So I think just again, starting from a common vocab and then it's starting to introduce like this is why it's not working.

A

Do you think that, on from the engineering side of things, if is there are things like knowing like human computer act, computer interaction guidelines from apple of having those kinds of things in your in short, quiver that you can bring out and say you know, there's a reason why you know tap and hold? Does this versus scroll but can.

C

A

Help like give credence to the designer.

C

um So yeah, I think, almost okay. If I could recommend for both sides of the house design, I mean they should really do this and engineers yeah definitely read some hci or interaction design books. Even I would recommend engineers I mean, I'm still learning this myself. I didn't come from a graphic design background, so I have to teach myself typography and color theory, but it's useful because the way that you look at a product as a consumer, the way your.

A

C

Parse through information like you're, that's just type that someone had to design the typography or the the spacing there. So that's easy for you to use, so I think, having so educating the engineering side of the house having that empathy for the design process, how that takes a lot of time to get the right gesture in place to make you feel like you get from point a to b, reads: read some stuff, maybe on cognitive, science or or whatnot, and and and actually I encourage you to sit in on usability studies. I.

B

Know at yahoo we.

C

Try to encourage engineers or just anybody to just sit in on some usability studies, but they're really enlightening so.

E

Any interesting things that you've learned from these usability studies in the past.

C

Oh man, well as a prototyper, I feel like uh it's my it's one of my roles is to frequently be in usability studies, because I want to be able to fully design pretty quickly so yeah so being in monetization.

C

One of the things I need to study, just especially on like link colors, maybe or just like what are the ideal graphics necessary to encourage click-through rates or interaction or engagement, so yeah. I think it's just really eye-opening to think. Okay well, currently, with this design that I thought would do well, because it looks delightful to me- it's not being clicked for some reason. So I I enjoy usability studies because it just shows how, like you can plan all you want as a design and engineering team, but your users will use it.

C

They'll have a completely different mental model, so it's great to just try to be on the same page as them and user studies kind of keep you cut down to earth about your product, so.

A

You think both designers and engineers would benefit from being involved in usability studies and seeing actual users do use their product.

C

Sure, or, and or let's say, a designer needs to go through a design review with the engineering team, um you can do like a walk-through as a team. All right here are all the screens um we'll just flow through them and just just call out like what could be wrong here. I think any any sort of team exercise around your actual products is just really, I think it's healthy. It encourages everyone to just be honest, like where they're at what's what's a buggy, and I think it could be a co-educational exercise.

A

Have you ever had an encounter where, because there's really three parts of this there's also uh the product manager, sure who's, also the third pillar and a lot of times the product manager will say, just do it because I say so so.

F

A

Deal with uh you know, do you like team up with engineering sites? How can you talk to that kind of thing as well.

C

Okay, um I think just with I think any sort of interpersonal communication understand what the other side's trying to say it's. It may.

D

C

That whoever is saying it, whether it's an engineer to me or a pm that they're they don't, they don't know how to articulate it very well, and maybe I have to examine the bigger picture. Okay, so.

A

They're saying I want it to be blue, but what they're really saying is. I want more people to click on.

C

Exactly so, they may be saying one thing.

A

But meaning some other more generically.

C

So often I find when I'm when I'm in design mode. um I have to think what is the deeper need or intention here I never want to solve for people's wants, because people's emotions are so fickle right.

B

C

When you want something one day and the next day is something completely different, so it's important as designers to really think about the trends and what people are needing or asking for and then and try to propose alternate solutions, so how I would push back if you will with the pm. If I thoroughly disagreed again, take a step back and provide some options, maybe one per exactly what the pm wanted and then what I think could be solving what the pm needs.

E

So do you back that uh back those answers out with like data or anything like that, like.

C

um Preferably for a preferred like with sound reasoning, yeah absolutely, but I think, with design there has to be a balance between sometimes data like okay, when it comes to things like search or big money makers. Of course you want to back that up with concrete data. We can increase the ctr x percent. This way, like.

F

C

Where it's necessary, but there's some things, I think that come with intuition.

C

So I think, with going back to the paper example, I have I actually have not used the product, but I've seen some really great great mocks of that product and I feel like when it comes to introducing new gestures or interaction paradigms that comes with intuition. I think so. There needs to be a balance.

A

Have you ever felt like, and I'm just drawing on experience, that's similar to this, where um on the search team we were dealing with, uh this was a search a long time ago, where they would create bucket tests and they would test like 50 000 different shades of blue, whichever shade of blue, like at the most clicks, regardless of any other sort of factor, becomes the shade of blue and what always irritated me about. That was that it was all like this incrementalism versus, like this leap frog into like. Why not do something completely new?

A

It's just not you know, playing with colors yeah.

C

A

So the the question question is: how do you deal with like that kind of like on the engineering side? You know incremental incrementalism is great right because it's not as much coding, but on the other hand, you know sort of leaping to something new would be.

C

I think it's a very tough question and something I'm about to enter in being in monetization. I I I have to encounter similar um sort of problems to that. So that's tough. I think. Sometimes, though, a team needs to be like all right, we're just going to go with it just go with it risk it, because otherwise, if you're too, too incremental and too safe you're not going to ship anything, um so I think there needs to be a call, but when does that happen? um I think okay.

C

So I think when it comes to making new decisions um with your product, I think yeah having a small sample and having incremental incremental changes to that. That could help you to study that, but I think ultimately there needs to be a point where you're saying just go with it: no more don't invest too much time in this.

E

So, in terms of that, have you ever, like I don't know, have you also had like uh problems like with multiple designers working on a project like? Has it ever come out that, like multiple designs will like have conflicts with each other on where, like the design, should go.

A

Yes, I just want to say that I have had that encounter where I would get one set of mocks from one designer.

B

And then a day.

A

Later it would be another designer and some other aspect of it sure and.

C

A

Completely different mocks and they would say you know oh use, mine mine's, so much better and they never actually you know is. Is it um an aspect that question is when you've dealt with like multiple designers? What's our hierarchy, are they all peers.

C

um I've been in I've been in mostly a peer relationship, and there are times when I happen to be the most senior, but I still think, okay, what's great about having multiple designers coming out with different mocks or wireframes they're. Thinking about again what I was talking about earlier, it's great to have different thinkers. You catch different edge cases, so I think I think there needs to be some sort of metric. A team has to agree to like okay. We.

B

C

Product is successful based on these concrete criteria and how do these mocks or whatever like uh compare to what we, how we measure out success.

C

So um I don't advocate for design by committee no, but I do think there needs to be some sort of key performance indicators that you, your your team, is going for and see what makes sense um per design and and see. And ultimately, I think designers need to work together and and and put ego aside and see what's best for the product, so um so so yeah. So.

A

You think that the teams that you've had where there's been no mutual respect across even across disciplines has been a more smooth experience.

C

um You mean between engineers and designers or across.

A

D

A

For both like, like.

C

A

Is like respect like I've seen projects where you know when the engineering team didn't feel like they could trust the designer, then every every you know the blocks they bring or whatever they would just they'd get more criticism versus like. Oh, we trust your insight. You know.

C

um I think initial okay, so just to give a little bit that background. My first job here where I was more of a designer um I was a designer, so there was there was a couple months or years where I didn't really touch css and javascript at all, and I found a little bit more conflict there. But then, as soon as I started to code in and get code more and- and I feel I felt like- I could negotiate a lot more and and vice versa.

C

I also had the mindset, just as they're allow, as developers are allowing me to code. I think I need to be able to listen to what engineers are seeing the design so because everyone owns the product, not just designers. I think I mean designers have a specialty, but they have to be able to listen to the deeper need of the product.

C

So I think conflicts you can't avoid conflicts in any situation, but I I do think again going goes down to empathy and and hearing the deeper need and seeing how I can even empathize myself like in the process. So.

A

I know you had some screens that you you wanted to show.

C

Okay, this is actually I just wanted to show you um yeah.

A

You can't do uh interaction talk without visual stuff.

C

This is true. um Can you see my screen yeah? Okay, I'm new to this. um I just wanted to show you there's not really much, but um so there's a when I used to do a lot of wireframing.

F

Okay, sorry, a lot.

A

From the left, let's see the interaction with this.

C

There you go okay and then you have to click on.

A

On the there, you go: okay, great, that it will it'll lag. Okay,.

C

Okay, so I just wanted to show you a wire frames website I used to visit pretty often when I was more of an interaction designer and here you can see that there's different types of sketches.

C

Oh, you can't really see it. You.

D

Zoom a bit, maybe in the browser.

C

Well: um okay, I'm not going to stay on this slide very on this page, very long, but the point is there's so many because there's different designers and different backgrounds of these designers there's different ways to approach wireframes. So let me define my understanding of a wireframe. The goal of a wireframe is really to capture what the what how information or content needs to be placed. um Basically the skeleton of it. um It's it's all about trying to understand um the user, like the user flows or interactions with with the page.

C

So things like honestly, things like adding in colors or pre-typography or or even high-resolution photos, that's not necessary in the wireframe. The wireframe is ultimately meant to be a skeleton. It's meant to educate the design team or engineers like how things need to be placed. um It's a thinking. Device have.

A

You noticed that the more uh it looks realistic, the more like pms will get confused and think. That's the real design, or you know things like that.

C

You're just pros and cons so you're getting to different fidelities, so the very low so there's something called low, fidelity and high fidelity. So.

B

C

Fidelity the lowest fidelity would be like if you literally sketched your your product on a napkin. You know with a sharpie or um or if you're, using a notebook or or you start to do, just basic great basic boxes um like with whatever whatever tool like you know, omnigraffle, and it looks something like this, where you can't make out exactly what it's saying, but you can get the gist of it. This is pretty low fidelity, but as you're adding in more like, if you you've, probably seen lower mips some text in.

D

Some wireframes.

C

Yeah, that's increasing the fidelity and usually when you increase the fidelity, it means you have much more confidence in your design and so the benefit to showing mocks, which is the highest resolution. Actually, the highest resolution would be code, but the highest resolution design world, um sometimes people. They can't think in terms of wireframes. They want to get inspiration for what the final product would look like, but things like going down to the wireframe level.

C

Its purpose is to work out, maybe the usability kinks, or that how how information is placed with the kinks, whereas showing mocks it's more like okay. This is the ultimate feel of the product, so yeah, so that's another, so those are fidelities. I just I wanted to show you. I thought this was pretty cool that an example of a wireframing sort of toolkit. They showed they're using this sort of like a blueprint sort of fuel.

C

I thought that was pretty cool. It's dry inspiration to traditional architecture- and this is this- is increasing fidelity like some some uh just some templates out there.

C

That will allow your wireframes or mocks to look like this, um and then you can describe flows like you know in terms of task analyses or or use or just maps like you can map it out, like this pretty sketchy and if you want to get really fancy, especially if you're designing like mobile apps like there's again more templates out there that allow you to kind of like uh mock mimic, what your final product experience could look like, but so it's my point here is there's just so many different tools or templates out there that allow you to express your ideas, um but don't forget the power of even the lowest fidelity.

C

I think that tends to be taken for granted. I think, especially when the emphasis is okay, we need we need to shift this product right away. So I think some some teams prefer mocks over wireframes, but I think there's still some beauty to working out all the kinks. You know even a sketchy, wireframe level.

E

So in a low fidelity sketch, where the things are most important like spacing or content like, what would you consider to be like the first things that you would do for low fidelity.

C

So I'm not as concerned about like do I have proper alignment or spacing in a wireframe. My goal here is: do I have the appropriate amount of information on this page?

C

um What what what general content types belong here and if I'm thinking about navigation, I I need, if I I can, I can like I could probably lightly map it out here or even think about it from this level, like I draw out like the general screens and how things need to flow or you can use, you know, like decision trees to show up, you know just just break down a task into atomic parts um as well, so so yeah so again, the point of a wireframe is to be a skeleton.

C

So when you start adding things like gradients or you know beautiful typography, that's not really, that's not helping. You understand usability as much as just the skeleton I think.

C

So that's all. I really wanted to show like there's just different fidelities and there's so many tools out there. I tend to use omnigraffle for wireframes or or photoshop and illustrator for mocks. Otherwise I just code yeah.

A

Have you noticed that, when you're having to like you're in the code that um doing a lot of rapid like doing a lot of iterations on a specific one, that's harder or easier, when you're.

C

Could you everyone else.

A

Well, let's say that uh you know they want like five different treatments of something- and you know do you. You probably wouldn't go into code for the treatments aspect. You'd, probably do it more when you're at the the phase of interacting with the engineering team right.

C

um I'm trying to understand how.

A

It gets like a pm, says: hey. I want three treatments of this. You know, okay,.

C

Next week,.

A

You probably wouldn't drop in the code right away, necessarily no.

C

I think I I guess I could, but um it depends on how complex they are, but I think okay, if it if, if it's like um yeah, try these different typography um or you know, if it's little things like, I think I could use code, it would be a css change. But if it's three completely different treatments, then I just I would stick to mocs at that point. So yeah.

E

How much of your code, like is the code that you write like um more structured or is it just like? Would you consider using some of the prototype code that you write into once the actual product is implemented, or is that like never the case.

C

C

Okay, so I come from a school of thought that I would like my code to be evolutionary if possible. So things like you know, css, I think could well assuming that my html is pretty comparable to uh to what the funnel build needs to be I'd like to at least risk the cycle style sheets. um But I think in cases where you just need to just show a customer right away. Unfortunately, um things just are thrown away so.

A

Have you ever sat down, I mean this is one one experience I had. That was one of the most best experiences I had with another designer was we sat down and we got. We brought up dom inspector and we looked at the the prototype. We started measuring on dominant spectre and you know like oh, let's try a little bit bigger, but there's almost like a pair programming experience. Yeah. Have you ever had that sort of interaction with the engineering side.

C

Yeah pretty often, but now, okay. So when I, when I was more of an intern when I was an interaction center yeah, I definitely pair programmed now that I'm more of a developer for designers. I just I kind of just do it on my own, but I do think that practice is helpful. I think it's important for for designers, if it uh to just again co-educate each other for them to know the basis of the dom or the box model, because it'll help them to design better specs, I think, and to not be.

C

I think I think one of the problems I've observed um observing designers, who don't don't have a technical background, is they they feel intimidated by code.

F

C

And so I think, just looking through the dom together inspecting it together, it kind of alleviates the fear, I think um so.

A

B

One that if you didn't have a question now, oh yeah, sure.

A

One of the questions we had was: uh do you have any pointers for new designers as they enter. The projects like working with engineers is part of the team. Sure well.

C

So yeah, I definitely would suggest um if, if you're, coming from a pure design background to at least get into html and css, I think javascript is a huge bonus and writing proper javascript, not just slapping in jquery, but no seriously start off with at least html and css. Because again, um I think there needs to be a uniform spirit between design and engineering in any sort of team setting does.

A

It come back to like that common vocabulary as well. Yeah.

C

Absolutely- um and I also I also think um for me- okay, maybe I'm just weird so when.

B

C

Finally, I because I keep okay when I was doing more engineering I was I came from like a back end uh background. I never touched javascript at all, so I had to I learned all my front end here at yahoo, so.

A

You've had the full spectrum.

C

You need to do.

A

Now is become a pm.

C

Pretty much, but so when I had to learn html and css and javascript properly here, I actually helped me become a better designer why I felt that I understood how things needed to be gritted out. I understood. Okay, given that I understand how this is programmed.

C

I I know how to be more uniform and I don't want to give like completely inconsistent specs, because I know that would take a long time to.

A

Help organize your thinking too, absolutely.

C

So so I think yes, my advice to designers, especially newer designers and working with engineers, to see how you could take some baby steps to understanding their world or even when they're talking about when engineers are talking about apis interfaces at the end of the day are centered around user interactions.

C

So I think just finding the ways in which you can have a common vocabulary.

A

So the flip side that, if you're a new uh engineer, let's say front, end engineer, are there things that you could do to help learn the user interface.

C

Absolutely so, I think in front of engineering. You have to know at least for engineering at scale. You should at least consider accessibility right, so definitely picking up a book on hci and empathizing with how people read a page flow through a page how they can be confused, what their mental models are with respect to your product, I think that could educate you even on how to design your schemas, how how is data truly being accessed? How can we improve performance based on how we know users are behaving so.

A

By the way or someone who's, maybe watching this heis human computer interaction, yeah.

B

A

Dig through some more of these, let me make sure we cover the ones that we had over here. So we talked about the tools right and then.

B

F

A

Mean how designers can best provide developers can provide you with feedback when they come across design. Yeah. That's.

F

Interesting so.

A

Let's just spell out a little bit more carefully, so one of the questions is: how can developers best provide you with feedback if they come across a designer.

C

Okay, I'm sorry, I'm gonna try and charge this a little bit um okay. So I'm just in the talk from the experience of like whoever, because I don't mind like an engineer telling me what's not feasible or anything I can negotiate, but for those.

D

C

I think again it comes down to going back to what they've what you've accomplished together as a design and engineering pair you know, uh and and seeing how this new design deviates from that and how it, how it's not working.

C

Does that make any sense like um so, for example, let's say like you've already coded modules together in your history together and then and and then maybe explain to your design counterpart, okay, oh this is this is how it was coded, html and css. Twice like you, can see how it's structured here. We needed this for a piece of logic to make this happen, but then, when you come to this module, this is where it can like. This is where it's impossible, so I think just establishing some uniform ground when you're explaining, what's not feasible.

A

Have you had to deal with uh saying? Oh, it's it's impossible in ie versus the rest of the world. That's another comment.

C

um I've been very blessed to not really talk about ie as much. I don't want to sorry moments, um but like okay, I guess great so great a browser. I primarily focus on grade 8 browsers in my experience, so.

E

How well should like uh designers know, like I don't know, like common interactions like, for example, like swipe left, to delete and stuff like that. How often do you uh like incorporate like more like common gestures into your designs? This is implying the mobile space right, yeah, okay, so.

A

E

Versus I don't know like coming off your own uh interactions. For instance, like you, don't want like design, things are too like way out there right.

C

Okay, that's a good question, um I'll answer it based on kind of a similar response I gave earlier. We were talking about um paper a bit, uh so I think you can't sometimes with the design. You can't introduce too many new things, because at the end of the day, you have to consider a learning curve with your product right and people are usually adverse to change.

C

So I think there needs to be a universal or an industry-wide vocab that you have to use and you have to just accept as a designer. So, for example, I call it the hamburger.

C

You know the three lines that indicate like that's your navigation mobile, especially or especially, if you have a most responsive site like you, can see on your desktop. So that's a pretty industry-wide symbol.

C

You don't really want to deviate too much from that, but I think when you're introducing new interactions think about like a metaphor that you're being inspired from so um let's see um like maybe when you're, when you're, making like circular sort of interactions with your screen, maybe think about like maybe is that, could that be similar to how someone's winding up a clock in real in the real form. So I think, when you're designing interactions, especially introducing quote-unquote new interactions, think about how your demographic has been using something pretty similar in the physical realm.

C

Maybe so I guess the trick is to never really introduce something. That's too wild or too new. I mean, I think it's. It should be incremental to a degree and always drawn a metaphor.

A

So you feel, like um both designers engineers should be able to feel free to say no. Is that correct because no seems to be very powerful.

C

um I think it depends on the culture of a team. I I love the mind that you know everyone know like everyone on a team. They have privy to say what they feel about our product. um So don't avoid conflict. If you, if you think that you have a strong case for design decision, you see you've seen it work. You have just the reasoning to back it up. You should say it honestly.

A

These are, these are great questions. um So what do? What are some of the things you feel like designers could learn from engineers, in vice versa,.

C

um Let's see I'm thinking well, it's interesting, I think, of some some of the designers that I know because they're more water folly I.

B

C

They know scrum and I think even talking about the basics of scrum or sprint cycles, or you know things around just good best practice best practices around agile, that's a good place to get on the same page and improve your workflow.

C

I also think things like test driven development or story, driven development and you're thinking about like the bigger uh business need that you want to. You know, build against. I think that can start also a meaningful conversation with designers. How to.

B

C

In that way too, so so yeah, I think that's how engineers can teach designers understand that designer the designer's role is to always advocate for the user.

C

So if there's any intersections, where you feel like your technology is or your practice is advocating for the user, then I think that's great way to start like being on the same page,.

E

So like write user stories, first like what we would do with like test driven, for instance, yeah.

C

Make sure that you definitely user stories, I think, is the most common unit between any party so make sure your user stories are are signed off from all parties, but then yeah. I think if you're building out test cases like bring the language back down to earth for the designer, so they can be on the same page.

A

um A couple more here, um what do you believe are like uh common or chronic issues that that sort of arise between a designer and an engineering sort of relationship during the project.

C

um I'm gonna make kind of jokes but they're kind of they're kind of serious, but I think, okay, I think designers, think engineers like. Oh, they can't design all they know is code.

C

They don't know like one color from the next and I think engineers think designers may take too long when they design just because it's they're complete, they can be seen as completely different disciplines, so they make assumptions about each other and so, and especially if, if design I mean, I like, I think, there's there's just great practices being introduced around lean ux and that fitting into the natural flow, but I think design typically honestly is um it tends to be student in a waterfall model, because some designers prefer, like you, know, blue sky.

C

I think I I think I think uh that's that's something that the industry needs to overcome honestly like. I think there needs to be a common team culture that will allow designers to be creative, but time boxed in such a way that things are lean so yeah. Those are the chronic issues. I think there's misconceptions and I think the timing in which the liver bowls are are pushed out that there needs to be some irony out there.

B

Did you ask me, uh no, I didn't uh my thing, that's all I have for now yeah anyways. No, I think that pretty much covers, I think, did you.

D

Get jordan actually? um What would you recommend for engineers to learn more about design.

C

D

Blog posts, articles.

C

Absolutely yeah, that's what I how I had to start. um I I would I do like um there's so many different um blogs out there like ux booth or things like that. I would I do. This is my method to my madness.

C

So what I do I I try to find these vlogs and I find their twitter and then I basically make a twitter list in my tweet deck, and I just stalk people reading pretty much or uh go to meetups and just observe uh just observe designers talk pick up an interaction, design or hci book be in user study, I think being in user studies is really again: educational, you're, ultimately very humbled by how users use your product, because I mean it's great to learn the theory from a book or from a professor or whatnot, but when you're seeing a user actually using your product, that's just something you can't really capture in a textbook yeah.

C

A

Have to describe there's this feeling here when you first go to a user study and you watch someone doing it. You're like just go over there, you're like you're, trying to coach them mentally like, but it's just right there in front of you or right click or you know, did you know you're auto completing just hit enter yeah, and then you know when people don't do things like that.

A

You're surprised, and you realize that you know the person that you envision as this user is like this all-knowing person said it's just like you know some mom or somebody. You know who's, not really. You know it's not what they do all the time you know. So this may be the first time they've encountered anything like that.

C

Design is really about communication and I think, when you're using something like visuals to communicate, that could be it's more abstract right. So it's inherently difficult, I think, to design something really well and really polished and going back to how can engineers learn design and just like even designers, how they, I believe they learn design. You just keep designing you design as many things as you can just build out a portfolio work on different types of projects, whether it's tools to consumer applications, different screens, just just make mistakes and just learn from it. Yeah.

A

I heard some advice. I have similar that where a designer was saying that um one of the things.

C

They really, they really.

A

Benefited from was they had their own side projects and they did all the coding they did all they took on the other role.

C

And that really.

A

Helped them so, I think the same thing could go for engineers where they should take on the design role and try to see what you know from that perspective.

C

Yes, um and I think um also with when you're learning design understand, ultimately who your users are and what their goals are. I think it's it's a when I was learning design.

C

Admittedly, I kept thinking hmm this is what I think a user will do. I think this looks good and I'm just going to slap this accordion in here and hope it works now. You have to really think about what is the true goal. What is the pain point you're trying to solve and iterate for that? Oh.

A

I have a good one. So what do you think about things like engineers who, like pick up, say bootstrap? Because it's like it's a crutch right.

C

They, you know they're.

A

Dudes, you know it's a startup, something like that. They're like okay, I don't know anything about design. So hey the bootstrip looks good. Let's go with that.

C

You know when I actually, as a pro driver I use or- or I use pure by the way.

F

C

Use whatever technology for the job, um but I prefer things kind of bundled up like bootstrap, for instance, um so to answer your question, I think when it comes to just in prototyping world using bootstrap fine, I think that's fine, but when it comes to design and understanding the intention of why would you use this accordion or carousel?

C

I think that goes down to understanding design patterns in in an interaction space. You just.

A

Don't take it for granted, don't.

C

Take it for granted like there is a particular reason why you would use a carousel right, just like with engineering design patterns like there's a reason why we use npc.

C

B

Well, did you have anything anything to close us out with anything ooh.

C

Closing statements, I think I think I would like to see. I would love to see the relationship become more more like a more fruitful between engineers. I think again, I think it boils down to a communication problem and I think just having that co-educational exercises gone in the team could just just be fun and exciting and just just enable people just to make really great products. So I really encourage that in your team.

A

Well great, thank you so much.

B

For coming today, and I appreciate.

A

uh All the insights that you've brought to us too- and I know.

C

That we've been laughing.

A

About things a lot of things, because we we.

C

Know you know like.

A

Every time we say you know what about these two things you're, like you, know, you're, quite bringing back memories of like.

C

Just in retrospect, I could see how we could have improved, but it's fine, it's. I think people are entitled to have opinions, and sometimes it comes and sometimes like you just need to understand the deeper need. So.

E

Yeah, it's definitely great to have like someone on you, like I'm bored, for a roundtable, especially when we've had been like we've been like heads out with like pure, like technical tools and all that for like the past few weeks. So let's talk about you know this. This method, for you know, npc or something.

A

E

We can talk.

A

E

Better things yeah, so we always it's always nice to like get us back down to like the perspective of an end user. Yes,.

C

All right take care.

A

Thank you. So I have one last thing before we go next week, we'll have uh stephen olmstead talk about uh some of the projects he's working on so just to follow up for next week, so that let me see if there's any last-minute questions, yeah there's not so thanks, again, lauren all right! Thank you.

F