SpoolCast D Keith Robinson
Brian Keith Robinson, interviewed by Jared Spool, recorded remotely from
Christiansen: the studios of UIE, November 29th, 2007.
[music]
Brian: Welcome. I'm Brian Christiansen, producer of UIE Podcasts. In this
week's episode, Jared speaks with D. Keith Robinson, creative
director of Blue Flavor, a design and development shop operating
out of Seattle, Washington.
Keith is an expert on design and information architecture, most
formerly editor-in-chief of Digital Web Magazine. Prior to agency
life, Keith worked internally for both Boeing and Children's
Hospital Seattle.
Keith will be presenting his talk "Making the Translation: Critical
Webapp Design Deliverables" at our Webapp Summit, which will take
place March 26th through 28th, 2008 in Coronado, California. You
won't want to miss it.
And now, here's Jared.
[music]
Jared Spool: I'd like to welcome everyone to an interview with Keith Robinson.
He is the Creative Director for Blue Flavor, which is a Seattle
design firm. He's going to be speaking at the UI Webapp Summit in
March, Hi Keith.
Keith Robinson: Hi Jared, how's it going?
Jared: It's going well. What we want to talk about today is lessons that
we've learned when trying to get designs developed. The question
I've been asking people--I'd like to ask you--is to talk about a
project from hell.
Something that haunts your past, just made your life a bit more
complex than it needed to be.
Keith: Right. Well, to be honest I think I've had a few of those, as most
designer will probably tell you. I do have one in particular that I
can think of that went very far south in numerous different ways.
Since I've worked on that project I've changed the way that I work.
And I can think of a few different things in particular that I've
done differently that has helped avoid those kinds of situations.
So, I'll talk about that one.
I'm not going to mention our particular client. I was with Blue
Flavor. But we had a client where they had basically two projects
going on. One was a typical web frontend redesign, an informational
based website.
The other was a web application that they needed a whole lot of
work, interaction design. They had an application pre-existing that
they needed just a lot of consulting help with.
Our first mistake, going into that, that ended up coming back to
haunt us was, we didn't scope it out properly. We didn't
communicate properly what we were going to be doing in specific. I
think sometimes with smaller projects you can get away with that.
But when you have a large project that has a lot of different specs
to it, and you're working with a lot of different people, it's
really important to not be inflexible, but be very specific about
the kind of work that you're going to do.
Along the way, parts of the projects went OK; parts of them were a
little bit shaky. But we really took a lot of things for granted.
Again, we had designed deliverables on both sites, the website and
the web application site. We probably didn't do as a good of a job
explaining, if that makes any sense. We created deliverables that
were a little bit fuzzier than they should have been.
Our wireframes, for example, for the application weren't annotated
to the level of detail they probably should have been, which caused
lot of rework on our end and on our client's end.
It also caused misinterpretations of what it was we were going to
be designing and building. So, when we got farther along in the
process we ended up kind of building something that was a little
bit different than what they had expected.
A lot of this comes down to communication, but at the same time, we
also probably could have done a better job being much more specific
and explicit with some of those higher fidelity deliverables, wire
frames, mock ups, things like that.
Again it went back t the start, where we just weren't specific
enough with our client in understanding what exactly they wanted.
We just kind of did one of these things, which I think is fairly
common, where we sat down, discussed the project. Thought we had a
pretty good idea what they wanted. They thought that we had a
pretty good idea of they wanted; when in all actuality those things
weren't true. They were never documented.
We didn't have any overarching deliverables that kind of defined
the scope of those projects. Now we are really, really, really
specific, not with everything, but with things that we feel need to
be specific with, if you were to look at one of our job orders for
example that we use with clients.
We have a little, a box, a disclaimer at the top of our job order
that says, you know: Common sense disclaimer. Please read this.
Make sure that you understand everything in this document because
we are going to be using this as the "Bible" going forward.
If you are expecting us to do something that is not in here, we
need to stop right now and make sure that we address it and that we
document it and we know that we are working on that.
And, you know, that is something that I've just learned in the last
two years. I haven't been a business owner, working for a
consultancy for that long, but I have seen a lot of these job
orders and contracts and the way that people enter into business
with each other and a lot of them are really vague.
Jared: That can be true for internal folks, too, right?
Keith: Oh, sure. Oh, definitely. In fact, it's probably less of a risk
with internal folks I think but yeah, it is definitely true. It
doesn't matter if you are a client service relationship or if you
are an internal team working with another group internally or even
within your own team. I think it's vital that at the start of a
project you take the time to really...
Obviously there research and kind of a requirements gathering phase
where everything is kind of fuzzy, but when you really sit down and
start to design and develop and build, not to be inflexible again,
but you need to just have a really good idea of what it is you are
building and you need to be able to communicate that accurately to
everybody involved.
Whether it's the stakeholders, the people working on the project
that you know... if you are the designer you need to communicate to
a developer what exactly they need to build and what kind of assets
they are going to need from a designer end. In this case, we took a
lot of that for granted, not realizing that we were doing that at
the time.
At the time we were just working away, thinking, oh, everything's
great and when we got to the end, they didn't really get everything
that we gave them. They didn't really interpret a lot of the stuff
that we have given them correctly, which I put on us. We've made a
lot of adjustments since then.
Jared: In terms of the lessons that are learned and in particular this
idea of having solid documentation as you go through your process
and when you are building web based applications, the fact that
you've got interaction that you are talking about.
It's not just, we're going to put up this screen. It's going to
have this content and we're done. But you've got business rules
involved. You've got all these different aspects of it.
How does one sort of plan out, based on what you learned from this
project, how do you do things differently now?
Keith: Well, there are a few things. I think first of all, this is
something that I think is become really, really clear to me in the
last year or so.
Regardless of how great your deliverables are and how much that
they communicate, they're never going to replace being able to have
a conversation with somebody involving the right people in the
creation or research that goes behind creating a certain
deliverable.
I think that that's one thing that in this particular instance I
was talking about, and several others. Sometimes it's a budgetary
thing and a time thing, and you just don't think about it.
But you tend to put a lot of importance on your deliverables and
let them carry a lot of the weight that sometimes they can not
carry.
There are certain things that a deliverable is not going to convey
to somebody, but you assume or you don't worry about it. You just
hand off deliverables to the next person in the chain, just
thinking it'll be OK, and then they never come back and ask
questions. The next thing you know, you're reviewing what they did
and it's all off.
So, I think the first thing is just keeping lines of communication
open, not relying on deliverables. Just be a little bit more
involved as a person, having a live body there to talk to people.
There's that. Also, we've spent a lot of time trying to refine our
deliverables, and create deliverables that are, A, appropriate for
the right people. For example, our developer, something like a
persona is probably not going to be all that helpful for him.
He needs something that's a lot more detailed and what he needs to
build than a persona. Handing him a persona, he may look at it and
glean some information from it, but it's not for him.
At the same time, I think it's important to make sure that
deliverables are very accessible.
Pretty much anybody involved with the project should be able to
take a look at anything that we create as far as a deliverable,
documenting any design, or development, or research of anything,
and being able at least to understand what's going on with that.
When it comes to the actual building of a web application, we've
gotten pretty high fidelity with our deliverables. Nowadays we
don't just do wireframes, for example. Wireframes on their own
don't really communicate everything that needs to go into a web
application.
We have a little bit of a different process depending to client
that we're working with. But my preferred process is to create
something that I call screen description diagrams, or page
description diagrams, which are very detailed.
But they're not showing any visual layout, they're just pros that
explain any interaction and different content elements or design
elements. And then I pair those with annotated wireframes.
Those deliverables really need to work together. If you look at
them apart, they're not nearly as useful as they are together.
Higher fidelity, more detail, and also trying to create a chain
where our deliverables are linked and attached to each other,
instead of being separate silent things.
Jared: Say a little bit more about the screen description diagrams.
Keith: It's a description of what would be on a particular screen, broken
down by priority and attached to deliverables. So, for example, if
I were creating a dashboard screen for an application, part of the
document would describe the goals for that screen.
You know, this is to give somebody a general overview of what's
going on with the application, et cetera et cetera.
Then, I break different interaction and bits of information into
pieces, and then I rank them by priority and how they support the
goals of that particular screen. Or, if you're talking about a
website, it would be a page.
Key here is that we're talking about a narrative rather than a
visual line. A wireframe would show you layout, this is something
that's a lot more narrative. Our clients love this.
Jared: Yeah, I would think so.
Keith: For whatever reason. I actually liked them a lot myself as a
designer. For example, if I'm working with Nick [indecipherable],
he's one of my business partners.
If he's doing that research, upfront requirements gathering, and he
hands me something like a page description, I don't feel somehow
creatively pinched, but I still have a pretty good idea of what it
is I need to design, if that makes any sense?
Jared: Oh, it makes a lot of sense. I like that it's in priority order, so
you can go down and the most important elements, like doing a
dashboard, are status on current sales and status on conversion
rate, and all that stuff.
It would have something, I imagine, that would say, when I click on
a given region in the sales chart, it would zoom in and give me
detail about the region.
Keith: Exactly. And the other thing that's nice about having it
prioritized is, when you get further along in the design process,
inevitably you will come across a situation where you may want to
remove something to call more attention to something else.
It really can show you what on these particular screens can be
removed to make them more useful overall--from a visual sense, for
example--where should I be placing the focus of the pages. But it
doesn't show you, it tells you.
Jared: Yeah, that makes sense to me. What I love is this idea that you're
communicating through the position in the document what the
priority is.
So, if it turns out that there's some element which will render
itself usually very small on the screen, but it's really high-
priority, that's going to tell you how to color it, or choose your
fonts or space it in the visual display.
It's going to communicate that in this document. Whereas if you
showed me a Photoshop image of the page, I may not understand why
that thing as a lot of white space around it, because I don't know
what the priority is when I'm looking at that Photoshop image.
Keith: Right. For somebody who's not a designer, I guess what ends up
happening sometimes is--if you just give somebody a Photoshop
document, I'd have this happen to me with developers, they will
change things because it makes more sense with how they built
application with the business logic or whatever.
Sometimes some things that I've deemed important, or a certain
interaction was supposed to be done in a certain way and they're
like, "Oh, we didn't do it, " I have to then go back and explain
them why it was done, or why we needed to do it a certain way. And
then they have to go back and redo it, whereas if you hand them a
wireframe or mockup and screen description diagrams or page
description diagrams, then they have a little of that background
information.
And if they read through it, they can get a better picture of, "Oh,
you know what, I can't really modify this without going back and
checking with my designer, at least to make sure that this is the
right thing to do."
Jared: That makes perfect sense to me. I had a project a few years back
where we had done a paper mockup of a design, and we had tested it.
We found that there was some specific wording on the screen that,
when that wording was missing, nobody knew what to do.
But when that wording was there--and we hand-wrote it on the paper
prototype, that's how it worked--everyone knew instantly what to
do.
The client, because we don't have design resources in our team,
hired another designer. That designer prettied it all up.
But because we didn't do a good job of communicating that piece of
text, that little piece of instructions, and they weren't sitting
in on the test, they ended up putting it--it was still on the
screen, but it was in a small font in a shade of the background
where you could hardly see it, because they thought it would be
ugly.
Sure enough, when the screens showed up for the electronic testing,
no one could use it again. We knew exactly what the problem was,
because that text you couldn't see. That sounds like these
documents would have solved that problem nicely.
Keith: They may have. The priority's a good thing, just simply because a
designer who maybe doesn't have the full benefit of the research
and the background and everything, if they knew the priority,
they're going to be less inclined to, say, make this bit of text
dimmer or whatever, because they know it's a priority.
So, there's that. And again, the description diagrams are something
that you can pair with wireframes, for example, or even mockups.
You can tie those two things directly. In fact, they aren't a whole
lot different than doing a very well-annotated wireframe.
If I had a linear process, I would just like to do something like a
screen description first, because it spells out the goals, it kind
of spells out to a certain degree the elements you're working with,
what's going to be on the different screens. Obviously there are
other documents; a developer might need a requirements document and
all that.
But it doesn't necessarily show what the design is. It gives you a
little bit of creative freedom when you're first sitting down and
sketching out those designs. And you still have a good idea of what
it is that you need to design, what's going to be going on the
page.
Jared: That makes perfect sense to me.
Keith: Yeah, they worked really, really well for us.
Jared: So, what other things came out of this that you're keeping?
Keith: Another thing, especially when we're talking about web
applications, I think one problem that we've made or that I've
made, I guess, in the past--my background lies a little bit more in
informational web page designs.
I've been doing web applications since the start of my career, but
I didn't do them as much until very recently. Now we're about fifty
-fifty.
The deliverables, and tools and terminologies that you use for web
page design contexts are different than web applications,
especially when you're talking about rich Internet, Flash-based web
applications. The interactions you can do there and the context to
the user is different than a web page.
So, when we first starting getting our first few web application
design jobs here at Blue Flavor, Nick and I still would speak in
our web page design lingo. A lot of the things didn't translate
exactly.
They are very similar, but we now try to draw a pretty hard line
between the process we use to build a web application and what we
use to build a web page, because they are just different.
A designer or a developer doing a web application needs a lot more
information about certain types of interaction, things like that.
Jared: Give me some examples.
Keith: Well, an example going back to the page description versus what I
call screen description: the context of a page, something that's
very informational website, whereas with a web application you're
going to have multi-state screens a lot of the time.
So, you'll have to describe not only more complicated interaction,
but you'll also have to describe screen refreshes that aren't
changing a page, for example.
When you are talking to a developer, those things need to be
described in a lot more detail, because otherwise you're just going
to get a bunch of static screens with no complicated interaction in
them.
These are things that we would do, but we would all use our old web
page IA process to do them. It's not exactly the best way to do it
as far as a designer coming on down the road, or a developer coming
on down the road.
There's just a lot more to that interaction, a lot more behind the
scene. It's a lot more complication.
You don't need a formal requirements document when you are building
a five-page informational web page. But if you're going to be
building something that's got a lot of business logic, like if
you're building Flickr, there's a lot more to that. And the
terminology is different.
Jared: Is the structure of the document different?
Keith: Well, yes and no. To a certain degree it's similar, for example,
when we're talking about screen descriptions, the difference
between an informational-based website and a web application, for
that document the structure's fairly similar.
You're basically talking about areas on a screen or on a page.
I say screen and page because that's how I separate the two in my
head. The thing about listing priorities and different content
elements is basically the same. It's just when you're doing screen
description for a web application, you have to get into a lot more
detail about the actual interactions.
For example, a wireframe is a really good example when you are
talking about the difference between designing a web page and
designing for a web application.
You have to annotate wireframe if you are doing a web application.
Or, you have to be able to somehow show and explain interaction in
much higher detail than you would with a simple web page.
If I show a navigation bar for a website, I don't need to explain
to a developer or designer usually how that's going to work. I
might put something in explaining that if there's a rollover state
or something like that. But in general I don't need to get into a
whole lot of specifics.
Think of Flickr where you can add in content within the page. That
needs to be described in much more detail than something as basic
as simple website navigation, for example.
You know, and some of the terminology is a little bit different.
You know, when you are in there, the terms aren't all the same, I
guess. And again, especially when we are talking about developers,
the level of detail and the level of complexity gets raised quite a
bit.
I guess on the user side, too, the context is a little bit
different. One thing that I've been thinking about a lot lately is
if you have a web application that's served to you in a web
browser, but that application is rendered, not in HTML and CSS, but
rendered with Flash, for example.
Does the context and expectation change to a user? Can you do more
desktop like interactions and still have them be usable? Does that
expectation change? I don't know.
If something's built and HTML and CSS is the front end, a user is
going to expect that a certain level of web browser like
interaction. A right click, a contextual menu in there might not be
the best idea, because the user is not going to expect to be able
to do that. Does that make sense?
Jared: Oh, it does, it does. The other day I was using Google Maps and
discovered by accident, not on purpose, I just accidentally clicked
the right mouse and found out there is a right mouse menu on Google
Maps. I don't know how long it's been there. I don't know when it
first showed up.
It turns out it has useful things in it like, you know, you can
point to any place on the map and say, center the map here or zoom
in, zoom out. That was completely new to me and it had been there
for months and had I not clicked accidentally it could be another
set of months before I discover it.
Keith: Sure, we have a client actually that we have been working with and
they came to us wanting to do a lot of, what they call, desktop
like interaction. You know, we recommended against a lot of that
stuff.
Understanding who their user was going to be and understanding the
context for which they were designing, it didn't seem like a good
idea simply because, in a browser based context, the user's not
necessarily going to expect that. Whether it's there and works well
is a whole other argument, but there are not going to know.
You could train them but at the same time, they wanted something
that was easily accessible to a wide variety of different people,
so we recommended more web browser traditional type of interactions
than going with the right click contextual menus and things like
that because of the context.
But I do wonder if you did an application entirely built in Flash
and your user based know that, I wonder if you could get away with
a little bit more of that. I'm not sure, I just....
Jared: I think if it is in a browser, people don't expect the right menu
to ever do anything useful. And, frankly, in Flash, it almost never
does anything useful.
Keith: Yeah, see you get the information about the Flash movie.
Jared: Yeah. The right menu is what you click on to copy a link or save a
file.
Keith: Yeah, that's exactly my thinking, too. But anyways back to the
deliverables, as far as the web page design versus web application
design. I think, as far as communicating design decisions go and
communicating requirements, I'm kind of a fan of over
communication. Some people don't like that but I have found it to
be helpful to me, so...
Jared: What about it, knowing that people don't like it, what makes you
persist with it?
Keith: I'm somebody who, if I've got a question, I would rather make sure
I have the answer to that question, most times, before I would go
and get to far along, doing something kind of based on assumption.
So, when I deliver documents to clients or to other people on my
team, I really, really, really try to make sure they are as details
as possible. So, (A) they don't have to come back and ask me
questions. (B) They have as much information as possible for them
to make their own decisions.
All too often in my career, I have been handed some sort of design
deliverable or research deliverable, that I've read through and
really turned around and said, there is nothing in her that I can
use.
I like my deliverables to be able to tell somebody something that
they can then do something with. I think that's a fairly common
that people are creating deliverables out there that they think are
communicating properly, but they're not.
You know, we're creating a web application here at Blue Flavor, for
example. We just started this fairly recently. It's an internal
project and we involved our developer from the very start, because
he is the guy that the buck is going to stop at him.
He's going to be somewhat involved with everything, and I asked him
at the very start. We talked about it, we had some documents, we
outlined the scope of the project, who the user was, all of that.
We had a pretty good idea of what we were building, which is a
whole other can of worms that can send a project south.
But we all had a pretty good idea of that, and then I turned around
and asked him, "OK, you've been involved with all of this, you've
seen everything that we've done up to this point. What are you
going to need from me?" A lot of projects, we can't do this.
Obviously this is an internal project, but he told me specifically
what it was he needed. That's what we're creating, that's what
we're documenting.
Jared: That sounds really good. One of the things you talked about was,
you mentioned early on in the project that was from hell, not
having all the right people involved.
Keith: Yeah.
Jared: Are you finding that just getting everybody in the room on a
regular basis, or on the phone on a regular basis, going over the
details--you know, nobody likes more meetings.
Keith: Yes and no. I guess the key for me is making sure that the right
people are involved at the beginning. I do like the idea of
touching base regularly. We tend to do that on our projects, I
wouldn't say too regularly, and we do try to keep our meetings
short.
But I think the main thing I'm getting at when I mentioned that is
just getting everybody involved at the start: making sure that
before you get too far along that everybody involved with the
project knows what they're doing, what the project's all about.
Hopefully, they're involved if there's research. My ideal project,
if I were to build a web application--like I said, Blue Flavor's
working on one right now--I wanted to make sure everyone who's
going to be working on that is involved from the start.
When we're sitting down and brainstorming, talking about who our
users are and what we want to do, the problems we're going to
solve, everybody was in that room. And everybody was able to
contribute to that.
I think a lot of time, say, when you're working at a big
organization internally and you're part of the web team, the web
team is going to be developing a web application, you may come in
halfway through, "Here's some requirements, here's some contexts,
here's some wireframes, can you build this please?" I think that
kind of a process, you're almost always asking for trouble.
You may still have a successful outcome, but it's going to take a
lot longer and be a lot more painful than if you just get everybody
involved at the start. Now, that doesn't mean that you need to go
and constantly loop everybody back in every time there's a decision
made.
I'm not saying that at all. But if you just get as many people as
possible involved at the start, as long as it realistically or
practically makes sense, you're going to avoid a lot of problems
down the road.
That's what we try to do. We recommend that to our clients.
Sometimes we get hired to do design work only. They say, "We have a
web application, we need you to do some consulting for us. Tell us
how we can make this better. Maybe do some design work for us, and
then we'll just hand it off to our developer.
" We try to get one of our developers involved with in those
meetings so that they can get an idea in case we have to bring him
in later. But also, they can share some expertise with us about
things that may be helpful when we give whatever our final
deliverables are back to our clients.
Again, it's a kind of a hard one, because you can't have everybody
involved all the time. That's just not realistic. But I think the
more you can do upfront with everybody involved that are going to
be working its better.
Jared: Right. I was reading a book recently called "The Point of the
Deal". It's by Danny Ertel and Mark Gordon. They make a big deal
about how a lot of deals are made without thinking about the actual
implementation. They're all about getting the deal signed and then
down the road someone else is going to have to worry about how
we're going to implement this.
Keith: We'll figure it out...
Jared: Their point is that the most successful deals are the deals are
deals where you deal with all these implementation issues up front.
Get the people that are going to be implementing it into the deal
make process and then they bring up the, "Well what about this
case, and what about that case? How are we going to do this? How
are we going to get things from this system to that system?"
All those little things that really are the things that if you
don't get those little details worked out very early on it really
comes back to haunt you later.
Keith: It's true. I know in our case - involving a developer, for example,
in the web application process from the start -there's other
benefits beside the fact that he's going to be more informed on
what it is he needs to build from an early standpoint.
They're smart. They'll think of things that we won't think of. It's
not all about "OK, I need to know how I'm going to build my schema
and how I'm going to do my developer stuff."
They'll think about interaction. They'll think about what may be a
feature that we think is really great for a particular product and
it's really not. Or it's so hard to implement, it's not really
worth it, that kind of thing.
I guess what I'm getting at, it's not only to inform them. Having a
lot of people in at the start doing the research and doing the
brainstorming; if you're doing contextual inquires and you're
talking to potential users, involve your designer. It's going to
help build empathy so that they can do a better job when they're
designing.
Involve your developer. It's going to help them realize that some
features really are important. Their input into that process I
think is very valuable as well. So it's a win-win. From what I can
tell, it's not rocket science. It doesn't take a whole lot of extra
time.
I think the savings in the long run, both effort and probably
budget-wise, are probably worth it.
Jared: Cool. This has been great. I'm very excited about your session at
the web apps summit. Where you're going to talk about your
processes and how you've done this in a little bit more depth. Any
sort of last thoughts you have here?
Keith: I'm really excited to distill a lot of my thoughts about our
process and the process of others; deliverables and how we get
thing done. And also get some feedback from people on what they do.
Hopefully I'm going to teach them some things that will be helpful.
But anytime you're teaching somebody something or you're engaging
with somebody on that level, you are also learning some stuff. I'm
really looking forward to it.
Jared: Well excellent. I'm looking forward to it to. Well thank you...
Keith: Great. Thank you.
Jared: This has been great. We will see you in March.
Keith: all right. That sounds great.
Jared: OK.
Keith: Bye-bye.
Jared: Bye.
[music]
Announcer: We hope you've enjoyed this podcast. You can comment on this and
other episodes as well as find more UIE podcasts at
www.uie.com/audio. You can win free admission to our next virtual
seminar by filling out a short listener survey about this podcast.
Please see the corresponding blog post at www.uie.com/brainsparks
for the survey link. You can enter once for every podcast you
listen to.
Don't forget: If you'd like to hear more of Keith's thoughts on deliverables for
web apps design, be sure to catch Keith at our web app summit,
March 26-28, 2008 on the sunny isle of Coronado just off the coast
of San Diego, California. Learn more at www.webappsummit.com,
that's all for this week. Thanks for listening. Goodbye.