Copenhagen

I think we're ready to start. Um, our next speaker

is a student of the Danish Design School. He has his own, uh, design company. Um, but the reason he's here is th-that he's done a lot of, uh, of,

uh, put a lot of thoughts into, uh, personas and goal-oriented design processes. He's, uh, done a six-month internship at, uh, the, the school of personas at Cooper Interaction Design,

and he's also looked into kind of the, the schools of IDEO and Frog, et cetera, all these, uh, big, uh, design companies coming out of the eighties computing age,

et cetera. So, uh, take it away. Thank you. Is, is sound okay?

Sweet.

So as Thomas mentioned, I'm going to talk about my experiences at Cooper,

and, um, I'm calling it The Cooper Way Demystified because as is-- I experienced it myself. There's kind of a hype, uh, surrounding Cooper, and I at least, uh, kind

of hacked it, and it's demystified to me, so I'm kind-- want to, um, communicate that to you.

Um,

so it's, it's all about sharing my experiences.

And me, as Thomas said, I'm Anders,

and I'm studying design. I am working with interaction design and visual design. I have a visual design background,

and, uh, for the past five years, I've worked with, um,

only with interaction design and creating user interfaces.

And I've interned at Cooper, um,

last year, second half of last year.

So how many of you know Cooper?

How many of you know personas?

Sweet.

Just to kind of, um,

round up on Cooper. Cooper is, is based in San Francisco and has been around for twelve, fifteen years

and is an interaction design company. So kind of the primary function is, is doing interaction design.

A big thing they also do is, is consulting, and the whole consulting part of it is, is growing day by day.

And a fairly big amount of their work is, is training. They have custom, custom courses. They train, uh,

fairly large companies like Nokia and IBM and

so on. Um, kind of the, the

intellectual property of, of Cooper is, uh, goal-directed design, and the whole goal-directed design features personas, and that's, uh, kind of the reason why I,

I traveled to, to Cooper. That's to learn about personas.

Um, Cooper is,

is kind of a-- it's a big company in the way that they deal with large clients. The company itself is, is rather small. It's, I think when I was

there, they had twenty people hired, so it's, it's a small, intimate family.

The, the

assignments they deal with are kind of complex, super huge companies, and

this goal-directed design method is kind of tailored to handle these complex design spaces.

So most of the stuff they do is huge clients, super complex. They have some assignments for more like consumer-oriented products, and they have a, a growing, um, market of,

of med tech assignments.

So the way I'm going to do it today is

give you a lowdown on the Cooper method. I'm not going into to super details about how to create a specific persona. It's more how are they using it, how

is the whole layout of, of from A to B, the process.

And I'm going to talk about the hidden features, uh, the insights of the method, which is kind of where I got a kind of clear sight. I, I was

enlightened by finding out what it-- what the hype was all about.

And then, uh, as Thomas mentioned, I'm going to, to finish off with some general thoughts on, on methods.

Um,

and during this, you're of course welcome to prompt questions if you, if you feel like it. Otherwise, I have a Q&A slot in the end of it.

Um,

to start out with, uh, I would like to explain how the teams are organized, um,

kind of just to, to get a basic, uh, understanding. So in Cooper, they have teams of designers, and one team is, is, uh, consists of an interaction designer

and a design communicator.

Um, so these people work together during the whole process from research until they deliver the f-the final project. And one team only has one project at a time, so

they have their full attention on this. They don't have to juggle with four or five projects.

And, uh, they are a team, like, really tied together. On the site, they have a design coach or consultant, so if they kind of run into a dead end

or

if they have issues that they can't resolve by themselves, they are kind of, um, meeting up with a coach or consultant. And the consultant is typically a retired interaction

designer,

which serves as a, a consultant within Cooper. And there's the visual designer, which is, is me.

And, uh, that's the team. So

The interaction designer is, is leading the, uh, interface and the kind of the overall interaction concept. And

the focus is, is mostly on conceptualizing and visualiz- uh, visualization of interface. So it's kind of the

crazy, mad, um, creative person, whereas the, uh, the design communicator is, is kind of trying to keep it all together and communicate the whole narrative story, which is generated

within this goal-directed design method.

And, um, the focus for the design communicator is on, on making a coherent, uh, design throughout the whole project. So if you should translate these two functions into something

we all, we all know, that would be, uh,

Mulder and Scully, where the interaction designer is Mulder and the communicator is Scully.

Um, so I'm, I'm going to break this down into, um, to the steps.

Of course, it all starts out with research, like all design projects.

Uh, the research is, is of course about understanding the domain, understanding the users, what kind of users do we have.

And this is done by doing interviews with stakeholders and users, end users, and possibly the, the people who are going to produce this. So it's, it's kind of a

straightforward research step. There's some, some, uh, more to it, and I'll touch that later.

So the modeling phase is, is kind of where the persona is created, and I'm not going to spend a lot of time on that now.

Um, after the modeling of the user, the team goes into kind of analyzing it

and writing a requirement definition. It's very, um,

the way they work is very based on hitting specific deliverables. So one deliverable in the process is the cr- the requirement definition.

Um,

so there, there's a lot of typing and analyzing here,

and it all end up-- ends up with, um, kind of a report that is, is being, uh, communicated to the client.

Um, so after the analysis, it, it turns into more like the, the raw design job, which is the framework definition. In this phase, it's all about creating raw framework

sketches, having, uh, kind of whiteboard sessions, doing-- drawing, uh, rectangles and primitive buttons, deciding which pane goes where, and,

and, um, kind of making up the whole behavior.

After, um, the framework definition, it goes into a more refined design step.

And in this step, you kind of, uh, push the pixels around and define, uh,

the labels for the buttons and the panes and kind of lock it all down. And in the end, there is some kind of deliverable where you, uh, hand over

the, uh, the material.

Um,

but as I mentioned, the, uh, kind of the

very essential foundation in this process and kind of things you have to, to be really careful about is, is the research and the modeling.

Um, the research is, is, I guess you could call it user-centered design. It's kind of the same qualitative method that, uh, IDEO is, is kind of selling their design

on. So they go out to a client or,

uh, kind of trying to find out what's in this domain, and they do some research, uh, at the end user's place. So they conduct interviews and take photos and

break it down and try to see what's under it.

Um, so it's definitely, uh, without going into more details about it, it's the most important step.

Um,

after researching, um, the whole modeling process starts, and it's taking the research notes back to the office, going into the meeting room and throwing it all up on the

whiteboard, kind of making, uh, huge tables and matric- ma-matrix of, of user patterns, finding out if we have-- if we interviewed twenty people, do we have some kind of

patterns? Can we divide the users into two or three or more groups?

And it's analyzing workflows and kind of hacking it and going, uh, under what you heard.

And of course, there's an element of, of kind of assessing the work environment, uh, understanding what kind of human factors are, are kind of in play in this specific

domain. Uh, one example is, um,

one team was, was working on a medical interface, and this interface was in a operation room,

and it was controlling something. And every time the doctor had to interact with this, he had to kind of move five meters through the room because he couldn't kind

of see what was on the screen. So that's kind of an obvious, uh, human factor you have to take into consideration when you're designing it.

Um, when you have kind of this all outlined, you can create the persona and with the c-persona create the goals that goes with this persona.

Um,

and the persona is, is, as I guess you all know, just an archetype user. The persona is not A real user just renamed. It's, it's taking several user types

or several users into one and making it into a consistent, um, well-defined person.

So the persona represents the needs of many, but not necessarily the needs of many different users. So it's very, uh, defined

user, and it's, uh, it's kind of the purpose is eliminating the elastic users. So

if you have a person, persona called Mike, and Mike is totally crazy about

doing amateur photography, Mike is not going to, to, uh, need really advanced printout options for his, uh, photo software. That's kind of being able to be as precise as

possible in the design process.

And then it's totally eliminating the edge cases where you have-- if you're sitting in a design session, and you say, "Oh, what if, uh, whatever user wants to,

to print with a SMYK note in the corner of the picture?"

And then you have Mike, and you say, "No, it's not for Mike. Mike is not totally interested in that."

Um,

so this is kind of

what the persona looks like when it's, uh, done. It's a fairly short description,

and it's

not filled with too many background details.

The background description is kind of pointed in the direction where it's supposed to go. So in this case, it's about Debbie, and Debbie is, uh, this, this persona is,

uh, described for photo software.

So the whole description and background is, is targeted toward Debbie's use and needs in, uh, in photo, uh, handling and photo sharing.

And in the end of a persona description, you kind of outline the goals of,

of this specific persona. So it's, it's all about having these kind of very specific things, but kind of trying to put them in a human way so you can

sense this persona as a, as a real individual.

So

in this specific case, there's one persona, but in, in other kind of more complex domains, you could end up having four or five personas or even ten or fifteen.

So you need to take these personas and break them into groups and, and figure out if you, if you're doing, um,

like a big complicated management tool, do you need to, to create a specific project for three of your users, or do you need to,

to make one project that kind of fits all? In most cases, it's, it's more about breaking it down.

Mm-hmm.

Yeah. Everything is done by, by the two team players. And in, in the research and the modeling, they work kind of on similar terms. They do

an equal amount of work, and when they move on, they kind of split out and, and kind of do more supplementary work.

So the whole benefit of, of creating personas is, of course, that you have some kind of foundation that you can use as a reflection throughout the whole pro-process.

And when you have done your kind of your basic work, you have your persona, and you move on, uh, throughout the, the steps.

And you actually use the personas until kind of the deliverable or even after the deliverable. When you need to, to talk about the project, you, you reflect it in

the person, in the persona.

Um, so that's kind of, of the method in its totally raw frame.

Um, there's a kind of-- there's a whole deal of, of details in actually creating the persona. But, um, uh, this scope is, uh, it's a little bit out of

scope for this talk.

Um, the hidden features are kind of my

enlightenment feeling, uh, after working there because, I mean, the whole persona thing is kind of... It's pretty easy to understand, and it's nice to work with. But what's kind

of how it works is, is a totally different, uh, ballgame.

So, um,

as I, as I just mentioned, it's, uh, it's about reflecting design decisions through the, the persona. So every time the designers, the designers, the cute one with the square

glasses.

Every time the designers are kind of debating a feature or kind of deciding which direction to go

towards, it's, it's done upon the persona. So you carry

your findings from the research into the whole process, and that's kind of the power tool of it.

Um, so there's no kind of magic spots in the process where you're kind of, uh, trying to guess what, what the users would require.

Um,

and even more, um,

powerful, uh, side of it is, is the whole external communication. Um, so of course, inside the organization, it's all about

kind of putting the user in the center and talking about the user and around the user. But when you're communicating with the client, it's, um, it's kind of works

the same way. So the client knows exactly

what kind of user layout you have. If you have four users, they know the name of the users and Kind of the behavior of the user and, and they

know what the, the, the user goals are.

And it's, uh, in that sense, it's, it's super easy to, to communicate with the client.

Um,

and there's a little example here.

In one, in one, uh, project, um, Cooper created a persona gallery. I think there was maybe, uh, five personas, and the company who had to develop the, the product

in the, in the end were adopting these personas in a really, uh, intense way. So they created

fictive email addresses for these personas and kind of send out emails to the whole organization from these made-up persons to kind of

spread the vibe. So it's-- it can be, can be powerful and intense.

Um,

I would say the--

Cooper is, is good at kind of creating personas and being true to the whole, uh, method, but what they are really good at is, um, is identifying the key

decision-makers in, in the organizations they work with.

So you might be working with this guy who's, um, a part of a product team or

a design team within the organization you work for, and this is called the client champion.

But what is more essential is kind of knowing who's above this guy and having communicated the whole,

uh, method and the reason why w-why we are working with this method, and this applies for, for kind of all levels in the hierarchy. So the further you go

up, the more tie-in or, or buy-in you can get.

And if, if you start out with the project, and you don't have kind of the connection all the way to the top, it's, uh, it's a weak foundation, and

you could end up in the end of the project with get it-- getting it all, um, kind of teared apart because somebody didn't like the, uh, the defined personas.

So actually, Cooper's not starting doing projects without having this connection all the way to the top. That's kind of a nice thing to know in, uh, in future products

or projects.

Um,

that said, it's, uh...

Even though it's an very efficient method, and, uh, it, it provides very, uh,

low-friction design, uh, process, it's kind of dangerous to base everything on this made-up persona or kind of-- It's not made up, but it's, uh, it's artificially, uh,

narrated.

Uh, so if, if your research is, is weak, and you're not really-- if you're not-- if you don't get the insights into your persona, then you don't really have

any, uh, foundation for, for using this, uh, method.

So it, it all comes down to, to the research, the quality of the research, and how good you are at getting these insights and, and goals into your persona.

So without that, it's, it's, uh, it's not really a good method.

And, uh, I've, I've worked with, with the persona method, uh, a couple of times in other contexts where the research were kind of super weak or not even existing,

and that means that the whole kind of reflecting into this persona is kind of useless.

So again, without re-- the research, it's, um, it makes no sense.

And, um, a few, uh, general thoughts on, on methods.

Um,

like Cooper, um, Cooper and IDEO are kind of, uh, equal examples in, in selling their method.

Um,

their method is their product, so they have kind of-- some kind of branded, um, method, which is kind of what they pitch when they go out to clients.

And, uh, it's, it's really good handle for, for people to understand. It's, it's a powerful communication tool,

and, uh, especially when you don't really have anything to... I mean, you can show them references, but for, for the given client, you, you can't really show them how

it's going to look. So you need to assure them that it's going to be just fine because you have this nice, well-thought method.

Um, I was in this, um,

workshop with an-- with a guy from IDEO, and he said that fifty percent of their calls is, uh, is about consulting,

and that's kind of-- and I guess the same applies to Cooper. So

people are not really that interested in, in getting a specific job done. They're just interested in knowing how to think this way or kind of how to implement it

in their organization.

And, uh, that's totally fine. It's-- I guess there's a lot of benefit to that, but

it's kind of, as I said, the whole--

the biggest value lies in, in creating a, a proper research and being able to take the research into the persona. So if you can't really conduct

an unbiased, objective research, you can't really use this, uh, the Cooper method, at least in your own organization.

Um, so that's kind of-- that's a little, um,

something to think about.

Um, another thing when you're kind of in this field where you're selling your method, I've worked in, in s-several places where they had some kind of, um, defined method,

but they were not really using it.

And that's kind of-- that's super lame, but that's how it works some places. So if you're not really doing what you're preaching, there's obviously a, a gap. And in

order to, to make your product believable and effective, you-- of course, you need to, to

be what you, uh, what you preach.

And, uh, I guess that could, that could, uh, be a lesson to some of the more

superficial companies.

Um,

so kind of to, to round it up, I,

I, I,

I'm not sure if I sold my soul to the devil, but, uh, I'm totally into it, and I try to be as, as critical as I could be. But

it's-- I guess you found out that I'm not really critical.

And, um, on this scale from tight to loose or to looser,

in my preference, um, for working in this specific end of the scale, I'm definitely into working in a tight design framework because you-- the amount of energy you spend

in, in this, uh, design process is, is being, um,

capitalized very well.

So

I would

to-- I would prefer to work in a, in a very tight design framework.

So I would like to, um, invite you to ask questions.

So I, I would like to hear, uh, what background, uh, do the interactive designer and the design communicator, uh, have? Are they from design schools? Are they from-- have

they been studying, uh, sociol-sociology? What's the English word for it? Um...

Um, actually, they have a lot of

mixed backgrounds, so they don't-- they are not being casted on whether they are sociologists or design students. They're more based on kind of the way they think, if they're

empathetic, if they can communicate what they think, if they are able to analyze what they, what they get in.

So

the whole way they, they do this is by having a really, uh, rigid, um,

way to hire people. It's, uh, it's based on a test. It's-- in the beginning, it sounds a little corny, but it's super efficient. You have to fill out this

test, and if the test is good,

you're getting into to an interview. And if the interview is good, uh, you're kind of in the office for one day.

And, uh, in the end of this day, which is kind of hand-on, uh, based, you have a session where you're kind of, uh, in front of the whiteboard, and

people are shooting questions at you.

So that's kind of the way they, they recruit people. So it's, uh, it's, it's smart people, and they typically have a academic background, but it's not from a specific

domain.

Uh, I guess the-- one of the, uh, uh, recurring problems with personas is that condensing huge amounts of data into personas, they can become too bland or generic. Mm-hmm.

Um, I've heard of some business or some companies that, uh, use, uh, utilize screenwriting methods to en-enrich the persona descriptions to ensure that this half page of whatever it

is becomes, uh, as condensed, data condensed as possible. Do you have any views on that? I mean, now we've just heard that it's, uh, regular academic backgrounds and- Mm-hmm.

-no specific writing skills are needed in your company.

So when you say screenwriting, what do you mean? Well, uh, screenwriting for, for movies or a soap opera- Okay. Yeah. -where they have to condense- So they- -persona descriptions-

Yeah. -to, to unfold. Yeah, I know that there's a lot of, uh, talk about making the narrative side of it as, as rich as possible.

Um,

as I showed you a short example of a persona description, it's kind of...

It's not like a fifteen-page script of this persona with a lot of super deep details. I mean, for most users, you can, you can condense the actual needs into,

uh, or goals into four or five goals and what style you would approach these goals with.

You know, you can summarize that into to a short text. And of course, it-- I guess it helps having some kind of, uh, story writing background. But, uh,

I mean, again, like, um,

like I said about recruiting, if you can't really put your talent into use in the context, you-- if you can't really write a,

a catching and, and detail-rich persona, you're not really, uh, able to do the job.

Do you have a persona archive? No, they don't have any, uh-- they don't have a persona archive because, uh, that would make the persona into a generic, uh, reusable

thing. I mean, when you've worked with personas for twelve years, you've-- of course, you've kind of meet some of the same

personalities and descriptions, but you can't,

you can't reuse one because it won't fit into the project.

So, uh,

they're not even, uh... In the persona description, they have a little picture. They're, they're not even reusing the, the picture. So no, they don't.

Any more questions?

Just a little one.

Thanks. Great.