We gaan weer verder.
Of zoiets niet.
Deze is de meest interessantste positie dat ik nog nooit heb gegeven.
Ik ga altijd over de banding.
Tot ik de banding heb gegeven.
Dus let's get started.
Like you said, I used to work here.
I'm now freelance.
My name is Kars.
Like most of you, I occupy myself with user experience stuff.
I need to confess something to you.
I'm a sketching addict.
Basically one of the reasons I guess I'm standing with today is that
a while back I did a project with the people of info,
where we kind of went pretty far in how much we applied sketching in the process,
which I'll tell a little bit more about in a bit.
Some other stuff I'll just briefly touch on today is some background,
I wouldn't call it theory, some background on sketching.
What I mean when I say sketching and why I think it works.
To start with what it is, it's more than just pencil and paper.
Hoeveel of you have read this book?
A few.
I can recommend it.
I think it's one of the most wonderful books on user experience I've read in quite a while.
It also kind of remewed my interest in sketching.
The guy who wrote this, Mr. Buxton, makes a lot of points in the book.
One of the points he makes is that sketching is more than just pencil and paper.
He identifies a number of qualities that characterize a sketch.
It has nothing to do with the material that you're using.
The nice thing is that it shows a broad range of disciplines from product design to game design,
interaction design for screens, and so on.
People are sketching, but they're sketching in very diverse ways.
The sketches they make, they share certain aspects, certain characteristics,
and these are the ones.
A lot of them are self-explanatory.
They're quick to make, you can make them just when you need them.
If it turns out wrong, you can throw it away without feeling too bad about it,
or your boss being upset, which is a disposable bit as well.
Plentiful, you can do a lot of them for the same single problem or feature of whatever.
In fact, that's one of the points of sketching.
Clear, vocabulary, and distinct gestures are more about the look of a sketch
and what that look conveys to people who look at, who see a sketch,
for instance your clients.
A sketch typically looks unfinished, which is what you want,
because that reminds people that it's work in progress.
It encourages them to react on what is there to give feedback.
They have just the right amount of detail.
The amount of detail is right for the stuff you're trying to communicate
or trying to explore.
If you're on a conceptual level, you're sketching very broadly,
and when you're working on a widget, an interface widget,
you might be sketching in much more detail.
Minimal is just enough detail,
which is also about the appropriate degree of refinement.
The last two are more theoretical, you could say.
The sketching is all about suggesting things,
more in a space of possibility, more than documenting and condensing
and ratifying what has been discussed.
You're using a sketch as a way to think,
different from just thinking inside your head.
It's okay if they're ambiguous, so they don't need to be clear cut,
contrary to a lot of other documentation that we produce.
It's a different thing from your typical wire training, for instance.
Why I think it works, I'd like to point out a nice little article.
I don't read many academic articles,
but this one I can recommend.
It's about basically the idea of embodiment
and what that means to interaction designers.
One part of this article is about thinking through doing,
you can see it right at the bottom over there,
and specifically about sketching and prototyping
and what role it plays in the design practice.
Basically, what the authors talk about is this thing,
this notion of reflective practice,
which means you're framing and evaluating problems while making stuff,
while sketching and so on.
This way of designing and this way of working,
so thinking while making things, while sketching, while prototyping,
has certain benefits, which I think you're all pretty familiar with.
For instance, you can get interesting results, surprises,
that you wouldn't find if you were just thinking about stuff
without actually exploring what it might mean on paper, for instance.
Working with prototypes and sketches,
you find that when you make something, it communicates back to you.
It works like a mirror.
You might be thinking of something and trying to drawing it, sketching it,
and things might turn out differently or you might make a mistake
and this might lead to interesting new avenues to explore,
which is what we like as designers,
this serendipitous aspect in our work,
at least to new creative insights.
This is the idea of backtalk, basically.
It allows you to express tacit knowledge,
which is the kind of knowledge, the kind of stuff you know
that you cannot express verbally,
but you might be able to express it visually,
which is really nice if you're discussing stuff with clients
or technical people or other business types,
your boss or whatever.
You might have all these important concepts
of things in your head that you know are essential to the project,
but you might not be able to express them verbally.
It turns out, at least in my experience,
drawing a picture helps a lot in getting the point across.
Those are some of the reasons why I think sketching works,
it's of course not a panacea,
but it's an important part of our work, I think.
Enough of the theory,
I'd like to just share one example of a project
where I did a lot of sketching,
where I exclusively sketched,
I hardly touched any drawing software whatsoever.
I had some assistance of a certain person
who is present here as well, Mr. Gomert over there.
This was a project which I think I can name.
It's launched, it's called MICE.
You could describe it as a start-up funded by some large companies.
Info.no was hired,
and I was part of their project team for the creative,
kind of the design part, you could say.
There was a separate kind of technical partner.
What MICE is, is to put it very briefly,
it's a social web application for independent professionals,
freelancers, ZZ payers in index, right?
Independent professionals mostly aimed at the business,
the business searchers mark.
What I'd like to show you is just a part of the sketching
that we did.
I'm showing you a part of a part of a part of the project.
We had a lot of stuff in place before we started
what I'm going to show you now.
We had done user research, we had our personas,
we had a big list of scenarios categorized
and prioritized and so on.
We also had conceptualized some of the key features
of the service already.
In the conceptualization phase,
I did quite a bit of sketching,
you could say as well.
We did these very rough drawings
to explain in a very concrete manner
some vague interaction design principles
and concepts and so on.
Which is not what I'd like to zoom in on today.
I'd like to talk to you about the bit
waar we started with a list of scenarios
and started to rough out basically the screens,
what you would call the wireframe of the site.
We kicked off with a meeting with a technical partner
and subject matter experts and so on.
We had our list of scenarios
and we started to collaboratively rough out
what the sitemap might be
for that set of features.
This was done just on the fly,
drawing out the pages
and some of the salient bits of the pages
and how those would connect.
This is, as you can see, not rocket science.
It worked really well to sketch this out
and also let everyone be aware of the fact
that this is what we leave the meeting with.
This is the thing that we move forward with.
After we had everybody go ahead
on this piece of sketching,
I quickly did a cleanup of the same thing
in only gravel.
This was the only part where I would actually sit down
en do a bit of only gravel stuff.
Then, using that,
I would start roughing out page layouts
of each of those pages,
starting very, very, very roughly.
I'm showing you, by the way,
the content part of the site.
Of course, it has many different aspects.
That influences the point where you would start.
I start with rough layouts
and gradually refine them.
These are variations.
I would do many, many of these for one page.
You might have heard of this apple process
or this kind of thing,
which is called 10 times 3 times 1.
In each feature,
the first and ten versions of,
for instance, an interface bit,
select the best ones and do 3.
Finally, do 1.
They start very broadly
and kind of converge in one solution.
I don't have time to do that,
but I try to do 3 times 1.
At least 3 rough sketches
before I would settle on one direction,
which I find works quite well.
The point here is,
this is just thinking through doing.
This is just me kind of
using the paper to talk back at me, basically.
Finally, we end up with
a large stack of sketches.
These we would take into a meeting
with the clients.
This would be something we would do every week,
what I'm showing you now.
We would sit down with them,
make sketches,
and walk him through that part of the site.
While kind of discussing it,
he would point out things,
he would suggest changes,
and we would annotate these sketches.
You might notice some kind of green bits.
I think it's green and some blue bits.
The green bits are some of the stuff
that we added while talking to the client.
I think there is a big kind of value
in adding those things on there.
He feels very kind of involved
with what you are doing.
The other nice thing is,
I don't have to take minutes or whatever,
I can just go leave this meeting
with this stack of paper,
and I would sit down and do a second draft
of all of those.
You notice I switch from pencil to ink,
which is just something that feels right for me,
whatever works.
I would detail these,
and then I would, for instance,
sit down with some of the other creatives
working on the projects,
such as Scandan and Walmart in this case.
We would go through them,
and again we would have
an internal review,
annotate these again,
this time in blue.
This is basically where the design sprint,
if you want to call it that,
the sketching sprint ends,
and a colleague who would
document this in software.
Ja.
You mentioned that you didn't actually document
the design rationale in the process.
You didn't make it just to the sketches.
Did you document in some way the rationale?
Why we made the changes we made?
That's a good point.
That's something that is hard to do
just in drawing.
In this case, it wasn't so much...
so much of an issue,
because I was always there.
In some other cases,
it might be an issue,
and you would need to keep minutes
of what is discussed,
and why we made the changes we made.
Which is important, I would...
It's also the question
what the rules behind the design are.
That's design rationale.
Ok, so...
Ja, because those...
I mean, the ones you mean, Peter,
we had already settled in a concepting phase,
where we had a pretty robust list
of interaction principles
that the client had signed often.
So we could always pull back on those.
I'm happy as well.
Does it guide and extend this,
because it's still perfect?
How can you see through?
In our case, yes.
Of course, I mean...
And is one.
This is just one project with one specific client.
I'm pretty sure this wouldn't work
with every client you have.
I'm hoping that you can
take from this
some things that might be helpful to you.
I'm pretty sure that...
I'm certain that I would not do this
exactly like this, again, in another project.
But some of the basic principles
of just not being afraid of
doing rough sketches and taking them to a client early,
I've certainly made a habit of
not only with clients, but also with colleagues, by the way,
who might not be
creators themselves.
I find people see through them
actually quite well.
As long as you're there,
this is not something that
can stand on its own.
It's typically a platform for discussion,
which leads me if there's no more questions.
One more.
We don't have much more time.
I'm happy to answer questions.
We had some projects that were extensively used in sketching.
We were then also sketching
more of the context and the process.
Have you got any experience with that?
Or do you focus entirely on the UI?
You mean the conceptual models and stuff like that?
No, I'm talking about the process,
the wide experience.
I've done those as well.
I do some game design stuff as well.
For instance,
I did some mobile game design stuff.
Clearly,
the broader context of use
is very important there.
We did storyboarding,
where we showed people with mobiles
in a surrounding, using the service
and trying to convey
the broader experience.
This is very specific
to how we did it
in a foreign web app.
It's very context-dependent
on what the sketch might look like.
I would say the basic principle holds.
Do you consider that scenario
hard of the sketching?
In some cases,
I don't know if there are any people
who do service design here.
In some cases,
it's all about that stuff.
Hardly about the interface stuff.
In my experience,
the basic principle holds.
You might think otherwise.
Anyway,
wrapping up,
I'm almost talking
for 20 minutes already.
Pieters asked me to share some tips
and tricks with you
for the stuff
we're going to do now.
These things I've already mentioned,
but again,
one of the nice things about sketching
is that you can do a lot of versions
of the same thing.
Go for volume,
diverge before you converge,
which is something I find typically
working in drawing software
just doesn't allow you to do.
Sketch as you think.
In my experience,
I sit back
and start thinking through a problem
and not touch anything
until you've come up with a solution.
I've had really good experiences
with just starting doodeling
while thinking
and trying to
immediately
visualize
to myself what it is
that's going on in my head.
There's this dialogue going on
between the paper and myself.
It might sound weird,
but it works that way.
It helps me to come up
with interesting routes.
Don't worry about the aesthetics.
Also,
when you're talking to colleagues,
you might be worried that your drawing looks crappy.
That's not the point.
These are sketches, they're not meant to look pretty.
I'm hoping you keep that all in mind
when we go sit down and draw.
Some of you might be more out of the drawing
than others.
That's not the point.
The point is that
you're just
communicating with each other
through other means
than just talking.
That's the basic thing.
And finally,
have created
a shared sketch space.
For instance, the annotations that I showed you.
When someone suggests
a change
is a good idea.
You agree on that change,
make the change on the spot.
Just draw on top of what you have there.
So that you confirm to each other
that you're on the same track.
You're still talking about the same thing.
Use each other's drawings
as a communal workspace.
Don't be afraid to do the other people stuff.
And don't be upset
when someone do's on your stuff.
That's me done.
Ha ha ha ha ha ha ha.
And carry on.
Voilà.
Dankjewel.
