All right, well I am here today to talk to you

about collaboration and content design, and what it means to the

web experiences that we're creating in the future, so before I

get started, I wanna tell you, a little bit about myself.

I work at Site Wire, it's a firm of a 100 people in Phoenix, digital agency.

Just joined the team about two months ago and, these are my people.

Well, some of them.

[LAUGH] This is my parents and my husband in the back and my sister.

Got two more siblings.

And the reason I wanted to tell you little bit about my family, is because I think.

Knowing my background will help you understand how

I've come to think of things a little bit.

So, my dad was a GIS developer.

And I grew up, in a really small town in

Northern Florida and my dad was hearing impaired, he was deaf.

And so when I was 13, 14 I

started interpreting for his ESRI word courses right?

And learning about typography and that vector and raster word data

and information systems and, how we can interpret rich complex information

visually and my Mom, sort of the opposite of that my

Mom is an artist and i learned from my Mom that.

How you shape things visually and how you combine

them with words can really shape how people feel.

And guide them through processes because she also does set design.

So I learned a lot from them growing up.

And I was also homeschooled.

So it really affected, I think, the work that I do today.

And I'm from Phoenix, which is super awesome.

If any of you guys wanna come for a visit,

I can tell you where to find the best tacos.

And in Phoenix, I have this little guy: Omar Jackson.

He is amazing.

He does not like computers.

Okay.

So enough about me.

[LAUGH] Let's talk about collaboration and content design.

So, before we take a look at the future.

I thought it would be helpful just for a moment to go back to the past.

Right.

So, a lot of times when we think about the industrial revolution

we think about some of the negative things that came along with it.

Tenaments, overcrowded cities, non-existent worker rights.

But, there was actually a lot of advances during the time, right, in health care.

And literacy and in people marching forward, right?

And one of the most remarkable things I think about the industrial

revolution is, that the way people worked and produced together was forever changed.

There was a little bit of that magic that happens, when the whole is greater.,

than the sum of it's parts, right?

And that's, that's, when we unlock that magic, that's what drives us forward.

So, flash forward to today.

We see that, digital experiences have dramatically

changed since the birth of the web, right?

They're extremely interconnected.

They flow from one device to the next device and,

and through people's lives through digital and in person experiences.

There's almost no way to distinguish them.

They're really interconnected.

Walgreens, has this amazing App.

It was, it was amazing before they did their last update.

It won a webbie award.

But what's so amazing about this App, Is they,

they studied the usage stats for it and they

found that most people using the App, were actually

in Walgreens at the time they were using it.

This was really remarkable to them.

They hadn't planned the experience for that.

They hadn't thought about that context.

So, they changed the functionality of the App to suite that.

So now, when you're using the App, at home you can scan

bar codes and make a quick list of things you have to pick

up and when you walk into the store, the App will light up

a store floor map and guide you to the items on your list.

Or say that you're waiting for your prescriptions or maybe a

take care clinic appointment, kind of bored no one likes to wait.

You can browse through your Instagram or Facebook pics

and have prints instantly ready, when you're done, right?

You can scan coupons, it basically is a partner.

It elevates the in-person experience.

They're very intertwined, both contextually, and with the

data nad information that's being transferred back and forth.

So it really is a whole new world.

Sorry for the Disney TV reference.

We have devices that we haven't even dreamed of yet.

I know a lot of people make fun of the Google Glass and

all of these wearables that we have, because they seem a little bit silly.

We know they're just in the middle, of what's coming next.

But the point is, is that we can't plan, for

what's coming next, because we haven't even dreamed it yet.

And so we have to change the way that we produce

things, because we've been stuck producing content and digital experiences for

things that we can plan for and when all of the

constraints and bets are off, we're left with sort of broken processes.

So it's getting really hard to tell where

the code ends and the content begins, isn't it?

Jerod Spool likes to say that everything is content.

Content is what the user needs or wants right now.

And that's wrapped in interaction, design.

It's wrapped in meta data that helps people find it easily and categorize it.

Content is at the heart of every experience that we design.

And yet, here we are in 2014, still producing content

and still producing web experiences like each element is completely interdependent.

We have, the writerly people, the designer type people, the developers who don't

get looped in until the end and then, wonder why the heck we thought.

We can have that sort of interaction design.

And on that platform or on this device.

Right, in fact with responsive design, we've

started to see that these work flows that

we have and these silos that we've built,

are starting to really cause us some trouble.

There's been a lot of articles and things said and talks given.

About, how with responsive design and adaptive

content, the friction that we feel, in

those siloed work processes and our waterfall

methods are becoming more and more apparent.

Right?

There was an article recently posted, I think just

a couple of weeks ago, on a list apart.

And, the author was talking about how they

had landed this new web project and, this web

project was going to be responsive, it was

a high profile project, and they were ultra stoked.

Because they were gonna try all of these new toys and tricks

and, and methods of building things that they had been wanting to try.

They were going to try HTML wire frames, and Atomic

design, adaptive content style ties, all of these awesome things.

And then, when they actually went to go do them, and try to

fit those new ways of making things,

this new methodology into their current workflow.

They got stuck.

And what the author came to the conclusion is, is that meeting the demands of a

multidevice web is much less a problem of

technique and much more one about how we communicate.

And communication, is essential to collaboration.

So, remember earlier how I was talking about the Industrial Revolution?

There's something interesting, about being in the present time.

We have this great luxury of being able

to look back and see quite clearly what happened.

But if you imagined the people who were living, in the Industrial Revolution.

I'm sure that they were just going about their daily jobs trying to get through,

focusing on the task at hand, no idea that they were in the middle of something

as big as a revolution, so I may sound a little crazy but if you look.

And how where we are now, and, and contrasted and

parallel it with what was happening in the Industrial Revolution.

I think that we're in the midst of another one right now,

because we're at the point where if we don't learn how to work

together, in a new way, and change the way we produce,we'll either

stop making progress, or the companies that don't learn will get left behind.

Right?

So, it's time to be greater than the sum of our parts yet again, in a new and

different way and move from merely collaborating and the

exchange of ideas and having inputs to actual co-design.

The co-design is not easy.

Just like the author of that [UNKNOWN] part article

noted, you can have the most talented designers and developers.

Interaction designers and writers on your team.

But if the processes aren't in place and the communication skills you

need to make those things happen aren't there, you'll fall short every time.

Right?

So, the revolution is already underway, and we see it.

We see it in projects that we think, how, how was that possible?

How are they able to build this amazing website or this amazing App?

It's noticeably different, than everything else that's out there.

We see these high functioning teams and, I wanted to find out how they did it.

And so, my normal way of doing a talk

is I'll research information and try to piece it together.

On my own, and I realised that was completely

counter intuitive to the talk that I was giving,

which was all about communication and collaboration and that

two or three, four heads are much better than one.

So what I decided to do instead,is I decided

to look at projects that really inspired me lately.

Those projects that I wondered, how did they accomplish this ,what was different.

And, I called them up I interviewed them on the phone sometimes on the back of a

über on the way to my next business meeting so, I hadn't intended to share the

phone recordings with you because they're a little

ghetto but I thought it'd be much more

fan, to hear even a low quality phone

recording then listen to me talk the whole time.

So, we'll have some of those clips and the people that I interviewed, first

off, how many of you have seen the new Virgin America site that just launched?

Only a few?

It's so rad.

It's the world's first fully responsive airline website.

And it's amazing.

It functions more like a web App.

And this is the homepage, that is all that's on it isn't this amazing?

I looked at this and thought how, on earth did they

get such a large cooperation to whittle down the amount of stuff

they wanted to cram on the homepage to something as focused

and streamlined as this and how did they create such a seamless?

Web App experience, when it's powered by something as old as Sabre?

Sabre is, is the system that powers all of the flight's information.

It's, it's archaic.

So, I interviewed the design team from WorkingCo, to get some of their invites,

their insights, and we'll hear a few of their stories in a little bit.

Happy Cog.

Happy Cog does great work.

One of the projects that they did that

really impressed me was a higher education site rebuild.

I looked at this and I thought, why

there's a lot of politics that go into that.

How many times have you been in a project where it's steeped in

tradition, there's so many people who have opinions and wanna weigh in on things.

And the end result ends up kind of Frankenstein like.

This wasn't like that at all.

It was clear and focused and an amazing experience.

So, I talked to the designer who worked on this project to get some of her thoughts.

And then finally, Nicole Fenton is a friend of

mine and she teamed up with her friend, Kate

Keifer, from Mail Chimp and they recently wrote this

book called Writing For the Web With Style and Purpose.

And what's really interesting about these two ladies

is, they're really sort of cross discipline people themselves.

So Kate is steeped in UX she's learned mark down.

Ooops, What just happened?

Okay, we're good.

She's learned mark down to make things easier on her team.

And Nicole, works hand in hand with developers all the time.

In fact, sometimes she makes changes to content right in get.

That's not a normal copywriter.

And she understands what she's dealing with and how digital is different and

we need that material literacy, all of us do in order to create

experiences that matter and, and not have to redo work so I talked

to them to get a few insights as well, so throughout this talk.

We, we have a few stories from them peppered in.

But really all of the insights that I have,

are sort of distillation of those interviews and those

conversations that I had, trying to find patterns of

these high-functioning teams and share them with all of you.

So, the first step I think.

To being able to code design.

And to have true collaboration, where the whole is greater than the sum of the part.

It's to be open.

And by being open, I mean being open to possibilities, being open to being wrong.

Being open, to the fact that maybe our version of idea isn't the best.

It's always up for grabs.

Testing is the true answer, right?

So, the first step in being open is ask a lot of questions.

Ask a lot of questions, whether it's research, whether it's

from your co-workers who are also on the same projects.

I don't know about you and your workplaces but, from some

of the people that I've talked to, sometimes they don't even

realize that a project is going on, that really intersects with

their discipline or their expertise, because

there's so many blocks in communication.

So ask, have lunch, take new people to lunch.

Take, take a department.

That use, someone from a department that you normally don't talk to.

See what's going on.

Be willing to say, I don't know.

That's the biggest thing.

We can't make progress and we can't be open to suggestions and improvement, if

we insist on being right all the time and we insist on making mistakes.

I've done this plenty of times.

Ask for feedback, and consider criticisms.

So, this is huge.

Feedback in a way, it's a, it's a microversion of being mentored.

We open ourself up, for someone elses perspective

to help improve our work or make it better.

How many of you have read moon rocking with Einstein?

I was just talking with someone about it last night at dinner.

Isn't it a great book?

That book is by Joshua Foer, and

he proposes that practice doesn't make perfect.

That, seeing and observing someone who is doing something better than you.

That you want to be like.

And, looking at their steps and analyzing

how those are different from yours helps close

that gap, and that's the only way to

achieve excellence, and cruise past the okay plateau.

There's a video on it on 99U.

Highly recommend it, check it out.

But feedback is sort of a miniature version of that, right?

We can go and we can talk to someone who maybe has more experience in

a certain area, and just get quick information,

and don't, don't wait until the next meeting.

Try to do it right away, quickly.

And with criticism, criticism can sting the

most, especially when it's not delivered well.

That doesn't mean that there isn't value to it.

With criticism, I would say consider all of it.

If it doesn't stick after you've considered

and really thought through if that's something that

could make a difference or help you improve what you are doing then let it go.

That's okay, but at least consider it.

And finally always be learning.

Learning new methods.

Learning new ways of talking to people.

And staying on top, of course, of our industry knowledge.

There's one thing that I think is really important to mention

about this how many of you are familiar with Carol Dwecht?

She's a PhD psychologist.

She's done research.

On what it takes to grow.

What does it mean to have a growth mindset.

And one of the key things, that's scientifically

proven that lets someone grow and develop past where

they are as an adult, cuz most of us tend to plateau, is having an open mindset.

Lots of interesting research but check that out

as well, there's a lot of details to it.

So, the second thing I wanted to mention, was just jump in.

So, I recently joined a company and one of the things that I'm

trying to instill in the junior team members, is don't wait to be invited.

Don't wait for someone to invite you to a meeting.

Don't be, hurt if you don't.

If you think that there's an area.

That you can help in, just go there.

Nicole Fenton, when I was talking with her, said something really interesting.

She said, content doesn't belong to content, design doesn't

belong to design, and code doesn't belong to dev,

because we are all responsible for the end experience,

and I think that thinking of it in that way.

Helps me jump in, in ways where maybe I

feel like is a little outside of my comfort zone.

I know that they're interrelated.

So, I go ahead and get in there.

Actually, I just mentioned this already.

So, don't wait to be invited, jump in.

All of the same principles that you use to design, amazing experiences apply

to writing, how many of you are familiar with this hierarchy of design goals

I use it all the time I love it basically?

We start with functionality and we slowly graduate up to delight.

We can't have delight if we

dont' have functionality and intuitiveness and efficiency.

The same thing, the same principles apply to writing.

You can't have a personality and focus on brand tone and all

of those things if you don't have basic clarity and functionality in place.

So, my main reason for pointing this out, was that if

you're a designer you're already perfectly poised, to start thinking about content

and designing things that matter, by starting from the content first, because

that's what informs our design and

helps us create contextually relevent experiences.

And sometimes, content is like code, for all of you developers out there.

And Nicole has something to say about that, so I'm gonna let her talk to you.

So this is Nicole.

You can tweet her @nicoleslaw.

>> But I think that interface writing is code.

Like it's code for people, it's code for readers.

It's like, I'm doing this step.

What am I supposed to do next?

You know, and that's a very

like, programmatic way of dealing with something.

Like if you're going through a checkout flow and something happens, or you have a

question, like, an interface writer has to think of it almost like a programmer.

>> An interface writer has to think of it almost like a programmer.

So really what she's saying is, its as simple as thinking

through the steps what's the best way to guide someone through

this, user journey what's the best way to help someone get

the information that they need its very logical it branches off.

There's different possibilities, we have if, then, requirements as well.

So, if that is a useful framework for you as a developer in

terms of thinking how to write things more clearly, think of it that way.

The main point I'm trying to make here is, I think there's a lot of value.

And becoming T shaped individuals.

IDEO talks a lot about this and what they mean by

T shaped individuals are people who have a really deep expertise.

So really really skilled and knowledgeable in

one area, but have that material literacy.

That broad knowledge, that compliments their expertise and

allows them, to create things that are relevant.

And work in a way that's more productive, and efficient with their team.

Michael Evans talked a little bit about his T shaped team members.

He is the product manager for Work and CO.

The company who recently redesigned Versions website.

And so I'll let you guys hear a little bit from him about his thoughts on that.

For us, it wasn't, we didn't think about it

as content, we more thought about as like, how

do we present products to the user in a

way that really makes it as simple as possible.

With also presenting like, information that they care about.

But I mean the whole project was super collaborative.

Like that's the only way we could do this.

With the team, our team is very, like our designers can

program our junior product managers are a little bit our developers are

pretty so it's like everybody can sort of be in everybody's

business a little bit and sort of know what's right or wrong.

>> So, I apologize, the last captions didn't come up for that screen.

He says, our designers can code, our developers

know a little bit of UX design, and

having this cross discipline training and knowledge and

broad expertise, everybody can be in everybody's business.

And know when something's going right or wrong.

This is how we will create efficiencies and be able to produce things quicker.

So even if content isn't in your job description, it's

something that can bring a lot of relevance to your work

that you get to the right answers faster and help

you produce and design things that mean something, and that work.

The third point I wanted to make was to make friends and play nice.

So, join forces, right, if you're working in one area, maybe

you have another designer who has a slightly different role than you.

Again, two heads are better than one.

Jump in and do it together, you'll be surprised

how much faster you get to the right answers.

One of the things that work in co mentioned over and

over again was that they were really really focused on getting that

virgin america site into development as quickly as possible because they wanted

to be able to rapidly test it, and iterate on the design.

So in order to get something into development

as quickly as possible, you really have to

have a strong deep knowledge of what you're

designing for, what the most important information is.

The hierarchy of importance and, and what user flows makes sense,

in order to get that in and start testing and tweaking.

So, Joe Stewart talks a little bit about his process, and how he

got started and he was on the team was working co as well.

I'll let him tell you a little bit about that.

>> For the Virgin project there were two lead designers

on it, me and my background in graphic design and then this other guy Felipe

Memoria who's background is with more of a traditional UX and so.

We started doing the concept work together.

Were just sitting in the same room, next to each other, you know, usually

we just stared talking about it a

little bit of research and client interviews [INAUDIBLE].

We draw a lot together like most of the time

what we're doing is basically drawing really loose wire frames together.

So like, they'll look like four lines on a piece of paper.

But you know, we try to talk through it.

You know, so that part of what

co-designing which was a, a really big thing.

>> So, to give you a little context to what

I had asked him before he told me that story.

I said, how did you get started?

How did you even prioritize what was important

if you were jumping in and doing wire frames?

Did you work with a content strategist?

Did you work with someone who knew about the information.

Who had written for Virgin before, and he said, we didn't.

Between the project manager, between the UX design experience that Filipe

had, and Joe's design experience, they were able to put their heads together.

Put themselves in the user's shoe, right?

You noticed he mentioned they had done research, they had

done stake holders interviews, to find out what mattered right?

And in doing this, they were able to

get together and really prioritize what information works best.

So one of the things that I would

recommend, and one of the things that I like

to do with my team, is anytime we're

starting on a new project, we get everyone together.

We throw out every piece of information that has to be included in

the experience, and just put it up on the board, kinda like content modeling.

So we understand the little building blocks that we're

dealing with and in doing that, we're able to force

the priority of each one of those elements, and

get to wire frames that makes sense a lot faster.

Alright, so the second thing that was a theme in everyone's

conversations that I talked to, was to make sure that everyone's invited.

Time and time again they said you can't

co-design, with just a select amount of people.

So even though they would start the process, with maybe two or three of them.

They would very quickly and even before then so remember he mentioned that

they had done the stakeholder interviews that was getting a lot of people

in the room to see what mattered and they checked in with them

often so your designers your devs your UX people your strategists, art director.

He mentions that all of these people were

heavily involved in every step of the project

and there's absolutely no way they could have

designed something together had those people not been invited.

I'll let him tell you a little bit about that.

>> The magic was really when where it, our executive

had them involve one unbelievably smart thing that Virgin did was.

They had a lot of stakeholders from a

lot of different departments all there, all the time.

So we, we moved into Virgin's office to be there every single day

and it wasn't like there was one person that we were working with.

Beta director was there, head of IQ was there, head of

operations was there, you know, all the different people that understand

all the different parts, what's gonna make this airline website work

with us were all there, so it's are you all together.

It's not like this person works with this person

and then you have to do this to this person.

We're all there all together.

>> They are all there all together.

I like how he said they are all in the room so

they could all argue, right, 'cuz you have to hash it out.

That's one of the things that I think was so amazing when I

saw that homepage and saw how streamlined that information was on the front.

Homepages are extremely political.

Especially when you deal with large

organizations who have different department heads.

Sometimes the department heads have competing goals right?

They got everyone together to make sure they had people's buy-in.

To make sure that people knew what was happening to gain efficiencies.

They don't have to go back and explain something or present it.

One of the things that Joe mentioned was

they never ever put together a presentation deck.

Because every time they put together a presentation deck for a client.

Is time that they didn't spend actually making something

that mattered to the client and making a difference.

I thought that was pretty impressive.

One of the caveats to this, though, is I asked him,

how are you able to get by doing all of this?

And he mentioned that Virgin was an exceptional

client, it was really the right client fit.

I don't know if any of you are wondering those things but, but I did.

Cuz, some of the things that they were talking

about, like moving into virgin's office for a year.

Having an hour meeting with their team every day, making sure

that all of the senior level executives where in the room.

These are not easy things to ask of a company.

A lot of times you'll get turned down.

So I think one of the things I learned in

talking to him, is that in order to code design

to be possible, we always have to be working at

educating our clients and selling them on why this matters.

How it reaches their bottom line.

Not that it's some fluffy, happier way of doing things.

But really hitting home on getting things into development faster.

Not wasting time and money on

presentations that don't affect their bottom line.

And making sure that you have everyone's who's opinions matter.

And who knows about the product and

understands what it takes to make something work.

In the room to avoid costly redesigns, going back and forth,

making simple changes that could have been done had those people been together, but

in order for that to happen, we have to learn to let go

and there's a couple things I think about this that are really tough.

As an individual sometimes when I'm working with proj, our projects and

someone has maybe an idea or a different way of doing something,

and I know that's not gonna work or I've been working on

that project a really long time and I'm deeply invested in it.

It, it can sting a little bit and

be a little uncomfortable to trust someone else.

Enough to really work with them.

Because you can't co-design with someone and co-create if

you think that your opinion's better or you're holding

on to something really tightly because you're not creating

the room or the space that allows that to happen.

Right?

And that can happen in any department.

Ora, the designer who worked on the higher ed project for Happy Cog.

Had something interesting to say.

Her, she's a designer so she focused it on

what letting go of control looks like as a designer.

I had asked her or a you worked

really closely with a client, you worked really closely

with a content, you started from the content

first and built this in a really collaborative fashion.

What would you say to a designer that might hold them back.

From doing the same thing.

What are some of the challenges that you want them to be aware of?

And she had this to say.

This is Aura, by the way.

>> So, if you're a designer chances are

like, an assumption I'll make but it's casly true.

A somewhat controlling person when it comes to what you're creating.

And I think what sets your client up for success, is for what

you're trying to control so deeply to actually, like, take into account.

That extra variable, right?

And the, one of the [INAUDIBLE] here or testaments

to the success of a site is once a

client puts all their content in does the design

system that you built still function the way you intended.

>> Yeah.

>> And that, that's twofold.

Like, that has to do, did you build a system that like, has enough needs.

And then also there's an education guide, like did you teach

the client what to use where, or what each piece is for?

So I think the sooner you open yourself up to

using two accounts for those things rather than trying to like

jam a square into a circle, you know there's

I think that you'll be happier once your sites launch.

You will be able to show them on your website so long.

[LAUGH]

>> So some of the things that she said, I want

to, I want to unpack it because it's easy to gloss over.

Some of the.

Challenges she said that we faced.

Some of the things that stand in our way from having co-design

and what it means to let go of controllers, a few things, on

she said making haunting considerations first, was a challenge for her because it

meant letting go of he older notion of how things should be designed.

It meant saying well, what are all of the content types and information needs first?

How can that inform the design?

And so it means the design sort of flexes and

bends to fit the content, rather than the other way around.

So that's one of the ways of giving up control.

She mentioned something else.

She said,.

Educating clients.

Educating clients and making sure that they understand how the system works.

That's letting go of the control making sure that we can manage it for them.

Or sometimes re design things in a way that really

doesn't even account, we think so much about the users.

That we forget about the people who have to use the CMS, the people

who will be responsible for keeping this

project alive and updated long after they're gone.

So, and sharing the control earlier on, we ensure that our projects will live longer,

healthier lives, and stay relevant, far beyond the

time that we stop working with the team.

Sorry this, that keeps happening you guys.

I'm not sure what's up there.

So, the fourth thing that I wanted to talk about was planning ahead.

So we've talked a lot about being open and collaborating,

getting together with other people, making sure you get all the.

Right people in the room at the same time.

But one of the things that I really have to mention or I would be doing you

disservice, is that in order to have really effective

productive, co-design working sessions, you have to be prepared.

You cannot go in and not have your agenda planned to a T.

I don't mean getting really granular, and

trying to be prescriptive in your approach.

I just mean being really intentional about how you're gonna use your time.

And I'll tell you about some of the things I do to prepare for co-design sessions.

I always do my research and discovery with my team, right?

To build those shared insights.

So it can really slow someone down if only one person is

interfacing a client, only one person is in on the stakeholder interviews.

Maybe development isn't included in that part at all.

What can happen is, is that we lose insights

and we end up having to redo work or regurgitate.

Information to certain team members.

So if we can build smaller project teams and make sure that everyone can

be involved in that discovery and research

phase, we can have shared roles and responsibilities.

We, we build that common knowledge and we're able to

be really informed and work together as a team more efficiently.

Just a tip: Nicole wanted me to let you guys know that she has some really

great research questions to get you started on

the resources section of Nicely Said, the book's website.

So some of these questions are the exact same

questions that I use when I'm doing discovery projects, and.

Getting started when I'm thinking about what to

consider in terms of both content and design.

So a really great useful tool.

The next thing that I think is really

important is that we have to consider the context.

And clearly state our project goals.

We're not going to be able to get together and

produce anything of meaning, no matter how collaborative it is.

If we have it, first consider the context in which we're designing for,

and made sure that our goals

are overlapping, with user needs, business goals.

So I like to state those openly.

It can seem a little funny and stilted when you get into a, a meeting and every

time you're going into a co-design session to just

jot it down, but it kind of becomes routine.

And it really helps you stay focused and I was really pleased to

hear when I was talking to Joe from Workingco that they do this aswell.

They have a crystal clear goal when it came to their

redesign of Virgin America's site and that was to increase bookings.

So, all of the design decisions they made.

Of course, wanted to make things easier and focused

on the user where we are all in service of

reaching that business goal, which is the whole reason, no

team was there in the first place, re-doing that site.

And so, by reminding ourselves, every

time, we get into create something together.

Just real quickly, having them up someplace visual.

We make sure that we don't get off course.

And that we don't make decisions that down align to

our, what we're trying to achieve, in the first place.

By the way, when it comes to user needs.

If you're curious, the Virgin America project.

They realy really heavily user testing.

So.

Everything they did was shaped by watching something, seeing how

people were using it, and then iterating on that approach.

So, really in alignment with this principle.

And then finally, considering someone's context, even if you

don't have the time to go through and read all

the research, maybe you weren't in as a team together

when you were going through and doing that discovery finding.

Maybe you're struggling with having one of the stakeholders trying to micro manage a

project or trying to slow down a productive working session.

It helps to just jump back in really

quickly and go through, what is the user thinking,

feeling and doing at this moment, when we are

in this user flow, when we're on this screen.

And sometimes, I even use this to put myself in my client's shoes.

To make sure that I'm really being a true partner to them.

So sometimes, when friction comes up again.

May-,

maybe I don't have the right answer.

Maybe I just need to take a step back,

and have a little bit of empathy for the client.

And respect them as a subject matter expert.

And as a true.

Co creator with me.

Because there's is that habit a lot of times that we have of

to separate people who are non-designers

or non-developers who don't have that expertise.

From being true experts who can make a

great decision but that's not always the case.

Great ideas can come from anywhere.

This can work for both users and co-workers, clients, et cetera.

Finally, when it gets down to actually designing the working meeting.

I like to get really basic.

So, I put up a visual agenda.

Some of my friends who can sketch a little bit

better than me, actually put it out like a real clock.

I can't do that.

I can never draw a full circle.

But I wanna make sure that everyone knows what's going on that day, how

much time we have to do it, what the goals we need to accomplish are.

So that everyone's working towards the same thing

and we can see progress in the meeting.

This is especially useful if you're doing this with client

stakeholders because a lot of times it can feel really uncomfortable.

For clients to be in a situation where you're creating things on the fly.

It can feel a little bit like am I going to get my money's worth.

Will they actually accomplish this goal?

So making sure that you clearly state what

each collaborative working session is meant to accomplish.

Having it up and then checking it off as you go through.

Really helps build trust, keeps people on task, and helps

ensure that those working sessions are productive as they can be.

Finally, diverge and converge.

The whole concept of building buy in means

that everyone needs to feel heard and listened to.

That's great, you can start with brainstorming.

but you can never have a brainstorm session and not end

with actually narrowing it down and making decisions there's some really

cool games that you can use gamestorming has them and stanford

design school has great resources on how to construct more meaningful.

Divergent and convergent thinking processes.

So, it's always a flow of getting by in, making sure all of the ideas are heard,

and then, narrowing down, grouping, prioritizing, organizing,and getting

to that final decision that you're going to make.

So, those are the main four areas.

That I wanted to cover.

And one of the things I wanted to, to end with is that I've heard a few

people say this in different ways, people don't

experience content separately from design, UX, and code ever.

Like, have you ever talked to your mom?

My mom has never once said to me, well

the words sucked but the interaction design was amazing.

She doesn't need to know what that means, to her they're all

one thing, and that's how it is to most of our users.

And so, when we make things, we can't separate them, we

can't be that way either, we have to do it together,

because in the end it's all one experience, it's all about

designing the best experience we can, it'll come from doing it together.

So.

Let's create things that matter.

Let's work together.

Let's find faster ways to build

more efficient products and start the revolution.

Thanks guys.

[APPLAUSE].

We've got a couple minutes for questions.

>> I concur we have a couple minutes

for questions would anyone like to ask Rebecca anything,

I've got one.

>> Okay.

>> What's a project so I know you just

recently changed jobs, you were at Forty before that, right?

>> Mm-hm, mm-hm.

>> What is the project that you did at

Forty where it it first sort of opened your

eyes that it went a lot better when you

collaborated in this fashion as opposed to an old one.

>> Sure, sure.

But you know it was actually a project where we didn't

start in a collaborative session, it was for a mobile app.

The client had come to us, and they had specked out all

their design requirements really laid out how they wanted it to be accomplished.

And we kind of, just jumped in and went to work.

We did our normal discovery process, but once

we kind of got that information from them,

we went off to create it on our own, and then came back with some wire frames.

And.

For them it really missed the mark.

It wasn't what they were expecting.

There were some requirements that we hadn't considered for the type

of development that they needed and what their developers could do.

And so we thought, you know, instead of going back

and forth and iterating on this and trying to get feedback.

Why don't we just have a meeting where.

These product managers can be with us, call the developer in, have

your designer come in and we'll all, we'll all sketch these together.

So what would normally be like a week long process

turned into a six hour working session, and we had

the entire user flow and really fast sketches done that

informed the more formal wire frames that we had to do.

For some of the higher ups and execs.

So it was immediate, it was literally this

realization of, this could of taken a week.

But because we were all there, and if we had questions we could ask them.

If someone had input or concerns it could get

put in and influence the design right then and there.

It was amazing.

>> anyone, as soon as anyone has a question

just raise your hand cuz I'm just gonna keep going.

So a lot of you talked about be open, have an open mind, be receptive to criticism.

>> Mm-hm.

>> There's gonna be somebody who's hot

head and doesn't like hearing what they say.

How do you diffuse tension in some of those co-working experiences-

>> Sure.

>> Where you say okay let's, you know, how, how do you go through that process.

>> Sure.

So typically I find, this is mostly the case that the people I work with,

who we have tension with, whether it's a

client or a coworker, they're not bad people.

They're not nefarious and wanna make my day suck really bad.

[LAUGH] Typically what's happening is, something

they really care about feels threatened.

Right?

Something that they think is really important

to the project, feels like it's at risk.

And so I try to find out what that is, and why they're feeling that way.

So I usually do a lit of, a little bit of digging.

Like, tell me about this, or what's bothering you here?

And I, I ask.

A lot of times, we see someone that's kind of upset.

And we'll never say, hey, is something bothering you?

Is there any way that I can help?

Or, is something going wrong here?

Do you have any concerns about this project.

A lot of times.

I found that, in just having a conversation with him.

And considering that they're not attacking me.

That I'm able to find out what they were concerned about,

and it's usually pretty easy to fix, does that make sense?

>> Absolutely.

And that, it definitely plays into

the, the homepage's political comment [CROSSTALK] which

I thought was really dead on, here's the question right here on the front.

>> Hey this is more of like a organization or even a sales question.

>> Okay.

>> But in my experience one of the hardest things about being able to collaborate

and have everybody involved in user research,

is that clients will cut the research parts.

>> Yes.

>> Or they'll try to cut out member s of the team to trim the budget back.

>> Yes, mm-hm.

>> Cuz they think my nephew makes websites, why can't you

guys just have two people and do it in two weeks?

So I'm always interested to hear like what's your approach to, making

sure that the whole team is able to stay there through the

duration of a project and selling in the research phases and really

preserving all the, the time and people you need to do it right?

>> Sure.

There's a couple of things.

It's a two fold question and I can talk to you afterwards about it at length.

But there's two things.

One.

I usually try and find out who's holding the purse strings and why they're tight

on that budget, why do they think that they only have x amount to spend.

I also try to find out where they're spending other things

and I try to put actual value whether it's in experience metrics.

Or I've actually tied UX and persona development directly to loss of organic

traffic with panda 4.0 and Hummingbird, because those Google algorithms consider

the entire experience, so once, once I can translate how what I'm

doing ties back directly to what they want, whether it's traffic or ROI.

And make it a lot less fuzzy, putting tangible frameworks around it on

what they can see, what they can expect from this I'll get better results.

On the other hand, sometimes you just gotta work with what you've got,

sometimes you're not gonna be able to get more research budget and what

I like to do there, is I like to just scale back some

of the processes that i'm using so it's not that I ever stop applying.

Best practices or the way I'm thinking about it, it's just that

maybe, I've got to really condense down the process that I'm going through.

So perhaps I'm doing just a couple qualitative interviews.

Right?

Qualitative interviews are a lot cheaper than backing it up with surveys.

Or maybe, if I can't do, if they don't have a budget for

qualitative interviews, I'll say, well, can I talk to your customer service reps?

The people who interface most directly with your customers.

That's free, just a couple hours of their time.

So, I'll usually try and improvise and use the best

practice methods but in a condensed or scaled back framework.

Does that make sense?

>> Great.

Rebecca that was awesome.

So, we're out of time, but Rebecca will be in the expo hall during the

afternoon break, so you can go up and ask her any more questions you might have.

Let's put our hands together for her, for her right now.

[APPLAUSE]