Re: buy-in, consensus, etc.

31 Jan 2005 - 6:51pm
9 years ago
9 replies
594 reads
Andrei Herasimchuk
2004

On Jan 27, 2005, at 4:09 AM, David Heller wrote:

> Or at least I have found that the more they understand the decision
> making
> process the easier time they have in getting the implementation of a
> design
> right.

I would agree with this generally speaking. (And it's good to hear
Robert change his use from "consensus" to "buy-in".) It's just I find a
well made prototype to do the job of creating "buy-in" far more
effectively than any combination of research deliverables that at best
simply communicate the base research and not really "the decision
making process" whatsoever.

How does a persona communicate a design decision or the process behind
it? It doesn't in my experience. At best, it's just background
information. So much occurs, or should occur, after the research that
affects the design decision making process that the original materials
simply cannot cover it.

Also, I would clarify something here: I don't actually need anyone to
understand the "decision making process" except those that feel like
they have a vested interest in it. Direct members of the design team,
certain engineers and if I'm lucky maybe only one product manager can
fall into that category. Outside of that, the end result is really what
matters. A fully-formed prototype is the best tool for that exercise as
long as the prototype is fully formed.

A persona in my experience can be written as a very short,
non-formatted text document with the bare essentials of data. No need
for a photo, no need for "personal background" history or a short
made-up biography and very little of the pure marketing demographics.
Should take no longer than half an hour or so to write and should be
done once with very little iteration.

> But is this design by committee? AND with all the talk of x-functional
> design going on, so what if it is? I have heard Andrei and others talk
> poorly about "design by committee", but many big design organizations
> design
> in big groups, which are often x-functional and YES! They have put out
> successful products.

The most successful, well-designed products are, in my experience,
driven by strong design leads. They are not built as a committee or
unwieldy size teams. And when built by teams, they are built with a
strong sense of design leadership from one person. What tends to happen
when you get something like five very smart, talented people trying to
equally contribute to a design with none of them effectively in charge
or a manager who treats their decisions equally, you invariably weaken
those five overall. This results in a weakened product design.

Part of the role of the design lead is to get the needed buy-in from
others in the company. There should be no reason anyone on the team is
asked to do work to help get that if at all possible. Everyone on the
design team should be focused on executing and solving problems. If a
design lead is not doing getting the required buy-in, then they might
need to be replaced.

SIDENOTE: Which "big companies" have put out successful products using
large design teams? And don't forget, I said "well-made, successful..."
And what is large? More than 5 people?

> Design in isolation to me is not feasible to me when the level of
> complexity
> reaches a certain zenith.

What I do is not design in isolation. When I'm charged with leading a
team, I do my best to let everyone contribute given their skills and
expertise, but at certain stages when a decision has to be made, I will
make it whether everyone on my team agrees or not. That's just the way
it goes. At the same time, I run cover for everyone on the team to make
sure they aren't distracted by unnecessary time sinks like trying to
get buy-in from other people in the company. I use prototypes to get
that buy in, as other material is not nearly as effective.

> I like prototypes, too ... But it sounds like you only ask these
> groups for
> validation and you don't include them in the formation processes along
> the
> way AND you don't include them in the research periods either. I have
> found
> that some of my best ideas weren't even my, but rather occurred
> through the
> creation of a space where x-functional design occurred.

Not necessarily the case. When I do my work, I always leave all my work
open for anyone to review, follow, participate and engage in. I just
don't force anyone to try and keep up with me or the design team. The
folks on the team that have the most energy tend to collaborate with me
as certain problems they tend to favor come up. Further, working
through those problems is again best done with a prototype, not
research material.

> Andrei, I don't want to assume, since this is just an e-mail list and I
> could never know the entire process that you use... Can you clarify
> more how others in your
> process get to help you form (not just critique and validate) design?

I promote a strong design lead. Someone who understands enough about
the problem and who's neck is on the line if the product fails. I
believe research can be done in a thousand different ways and designers
should spend as much time as they can get away with doing various
research activities before even attempting to design the product.

During the design, I believe in building prototypes or accurate
representations of the product and iterating over and over and over
until you run out of time. (While also hitting the major milestones you
agreed to prior to the project's start.)

The hard thing for me is working through the various ways in a which a
prototype can be done. A "fully formed" prototype in my opinion can be
a robust Flash demo or a large set of static screenshots, as long as
everything is fairly realistic and accurate to what the real product
will look like. You should attempt to go the Flash route, or a route
that lets you play with the product in some form if at all possible
though. Getting money and resources to build a realistic prototype is
the hard sell inside companies generally. Now that I have my own design
company, I'm simply spending the money to do it as I know what value it
adds to the process. What I can tell you is that a prototype can't be
simple wireframes or flow diagrams or the like.

> As a side note, one of my favoriate pieces of the cooper process is not
> personas but the buddy system approach of having a designer and a
> design
> communicator.

Design Communicator? Why does a designer need a "design communicator?"
That sounds entirely counter-intuitive considering one of the most
critical skills a designer must have is their ability to communicate.

> Last point, I too believe that prototyping is really the core DESIGN
> tool,
> but I see a strong place for research data modeling to exist in the
> process:
> Task/workflow modeling
> User Environmental Maps
> Card Sorts & Thesauri
> Task Analysis maps
> Problem statement discovery
> Analog models

These things only exist, in my opinion, to the degree it helps
designers think through certain problems, not as a means to help
non-designers understand the process of design. If these deliverables
exist as a process checkpoint for the sake of keeping everyone else in
the company happy that the designers "are doing their jobs," it will
suck the creativity right out of your designers to solve problems in
unique, innovative ways as they spend more time on these deliverables
and not enough time building things.

> All these are models that help a design team communicate among each
> other
> and with a larger x-functional team.

Not in my experience. Some can help if kept under control and not
allowed to escalate into deliverables for process sake. In the end, the
thing that holds together a design team and the larger x-functional
team is a strong design lead. A real person with skills, vision and who
can manage the nuances that is required to get the most from the team
as well as keep them working together to execute that vision.

Teams without strong leads tend to flail around and no amount of
visualization models or research deliverables or whatever will save
them from drowning eventually. These sorts of deliverables tend to feel
like some way of controlling the design process to achieve predictable
results. In that end, they can succeed, but they also can rob teams of
the freedom to solve design problems in ways that best fit the product
problem.

> That's another interesting point ... How do DESIGNERS communicate
> among each
> other? I know Andrei you worked at Adobe, which has a host of
> designers. How
> did communication between designers on the same project, on related but
> separate projects communicate their research findings?

This is a topic that would require me to write a book. The short answer
is: My experience at Adobe is colored by my lack of experience at
managing people due to being younger at the time I started the team
there. I was more focused on trying to solve a large product design
problem while also trying to understand how to build a design team. The
latter suffered as I was more driven as a designer by the former.

Outside of that, it would not be appropriate for me to speak openly
about the process inside Adobe for a variety of reasons. That would
have to come from someone else.

Andrei

Comments

31 Jan 2005 - 7:48pm
Dave Malouf
2005

Hi Andrei, I think you assumed a lot from my response.
The main overriding theme that I understand from you is that you assume that
an attempt to get buy-in is in opposition to the strong design lead.

You speak of the "decision making process" as something you don't need to
communicate, but I must disagree as someone who constantly wants
transparency into the decision making process of others on my team
especially business and development. Understanding their decisions often
means different decisions from me, and when dev understands my design
decisions they can then architect the longer term program design around that
decision process as it relates to a longer vision then the current product
release.

Now back to the x-functional team and a strong design lead. I think of this
as a movie. There is a director, which has the artistic vision and the
producer which is responsible to the studio. They both share the vision and
even when the "director" has artistic license, the director still relies on
a team of co-leads to get a project off the ground. Leading is not the same
thing as an autocracy. There are many ways to lead a vision, and the best
that I have found is when you engage the entire team. Not just wait for
their response as you describe below, but you should engage them, not just
for "buy-in" but because they offer ideas and expertise that no one person
should or could have.

Examples of strong x-functional design teams:
IDEO and Apple ... Yes there is a strong lead, but their teams are very
x-functional in nature. It is the basis of what IDEO calls the Deep Dive.

Now lets work at prototyping as your only design deliverable ...
I find prototypes good for depth, but not good for breadth. If you have more
than 1 direction that you are working on at a time prototypes become hard to
manage. What do I mean by breadth? I mean solutions' frameworks. This is why
sketching, flow modeling and other non-protoype methods allow for the
flexibilty that is required to get enough breadth at each area of iteration.
Maybe I'm splitting hairs, but no more or less than you have done in this
thread.

Anyway, I do have to say that maybe there is just something about personal
style to all this. My experience in my environments (which is probably a
factor to the decision of how to do process) ... Is that the more you build
bridges with the x-functional team, the more you get what you want. Now,
these are not obviously design-centric organizations, but I think for the
vast majority of the people on this list who don't work for design-centric
organizations, it is a good way to go.

Just something to think about Andrei, is that your world is still a luxury
for many of the practitioners out there, especially those of us working
"in-house"

-- dave

31 Jan 2005 - 8:49pm
Andrei Herasimchuk
2004

David Heller wrote:

> You speak of the "decision making process" as something you don't need to
> communicate, but I must disagree as someone who constantly wants
> transparency into the decision making process of others on my team
> especially business and development.

That's not quite what I said. I said:

"I don't actually need anyone to understand the 'decision making
process' except those that feel like they have a vested interest in it."

It just means I don't like wasting my time with people who aren't
interested in what I do, or who can help me with what I do. If the
number of people on a project with a "vested interest" is 2, then its 2.
If 30 people have a "vested interest" in what I'm doing, then its 30. If
someone is interested, then I engage with them fully. It's just there's
a lot to do on a project so I don't actively seek out anyone who isn't
intimately tied to the process of design and shows no interest on their own.

That is a personal style approach. It's nothing more.

> Leading is not the same thing as an autocracy.

Where did I say it was? That's quite a leap there.

> There are many ways to lead a vision, and the best
> that I have found is when you engage the entire team.

At what point did I imply I don't do that? I just don't actively engage
people who don't have a vested interest in what I'm doing. I fully
engage members of the design and certain members of the engineering and
product teams. Those people have a vested interest.

You seem to have an issue with my statement about certain times where I
like to make a decision regardless if everyone (even on my team) agrees
with it. That's just the nature of the beast. I hope it happens little
and infrequent on any project, but it can and that's my personal opinion
about how to move forward.

> Examples of strong x-functional design teams:
> IDEO and Apple ... Yes there is a strong lead, but their teams are very
> x-functional in nature. It is the basis of what IDEO calls the Deep Dive.

I'm not sure how you would assume what I said is counter to what you
just wrote. Further, maybe you should define the depth of "x-functional"
as it might not be as large as you make it out to be.

> Now lets work at prototyping as your only design deliverable ...

Again, where did I say "only design deliverable"? Please don't put words
in my mouth.

> I find prototypes good for depth, but not good for breadth.

I guess we'll have to disagree on this point, as that's not been my
experience at all.

> If you have more
> than 1 direction that you are working on at a time prototypes become hard to
> manage.

Simply not true. Anything that requires iteration and multiple versions
can be hard to manage. It all tends to come down to where you invest
your time.

In fact, I find prototypes help me work through all sorts of variations
on solving problems. And I find they do so *faster* than any other method.

Read up on how Tyson built his new vacuum by the way. He made something
on the order of 4,000 plus working prototypes, creating variations,
iterations, complete architectural changes. The whole lot. To claim
prototypes don't give you breadth on choices for design is just inaccurate.

> What do I mean by breadth? I mean solutions' frameworks. This is why
> sketching, flow modeling and other non-protoype methods allow for the
> flexibilty that is required to get enough breadth at each area of iteration.

Sketching (which I do a lot of FWIW) will only get you so far, as will
flow modeling and whatever "other non-prototype methods" means. The only
real way to know if a framework will handle what you are going to throw
at it is to build an accurate enough prototype with enough of the guts
reflected in that framework. Otherwise, the best laid plans with
frameworks can hit huge brick walls when certain details might not be
accounted for from lack of depth in something like a sketch or flow model.

> Maybe I'm splitting hairs, but no more or less than you have done in this
> thread.

I'm not sure you're splitting hairs so much as putting meaning into my
description of my process that I don't believe is there.

> Anyway, I do have to say that maybe there is just something about personal
> style to all this. My experience in my environments (which is probably a
> factor to the decision of how to do process) ... Is that the more you build
> bridges with the x-functional team, the more you get what you want.

Again, where on earth did I say something that implies what I do doesn't
aim to achieve this goal?

All I have said so far is that I find building fully formed prototypes
does the task of buy-in (and sure, even building bridges) *better* than
any other deliverable I have in my toolset. It solves all sorts of
communication problems within th eteam by giving them something concrete
to work with, allows designers to work through problems in a manner they
tend to enjoy more, points out in explicit detail what works and what
doesn't, and even lets you get the kind feedback from users that is
crucial to the design process that won't get from sketches, flow
diagrams, or crude diagrams.

That is *my* claim. You disagree? Fine. Disagree.

> Just something to think about Andrei, is that your world is still a luxury
> for many of the practitioners out there, especially those of us working
> "in-house"

This is a snippy way to end a message. I have no idea why you seem so
agitated about my remarks. You seem to disagree with my answers. That's
your prerogative. But you made logical leaps in my approach that I don't
believe was there, and now seem annoyed with my answers which you asked
for. You asked me for some of my answers and I gave them to you.

Andrei

31 Jan 2005 - 10:31pm
Dave Malouf
2005

On 1/31/05 8:49 PM, "Andrei Herasimchuk" <andrei at designbyfire.com> wrote:

>> Just something to think about Andrei, is that your world is still a luxury
>> for many of the practitioners out there, especially those of us working
>> "in-house"
>
> This is a snippy way to end a message. I have no idea why you seem so
> agitated about my remarks. You seem to disagree with my answers. That's
> your prerogative. But you made logical leaps in my approach that I don't
> believe was there, and now seem annoyed with my answers which you asked
> for. You asked me for some of my answers and I gave them to you.

I can see how you might interpret what I said as snippy. I apologize that
wasn't my intention.

What I was trying to say was that different environments have different
needs. But even that point doesn't seem to be warranted based on the whole
of your response.

I think we just missed each other doing the same thing. Each leaping from
the other. That being said I think I see the following statements of
agreement:

1. design requires strong leadership
2. iterative prototyping is an invaluable communication tool
3. it is important to engage invested team members

Where I think we disagree is ...
In some cases, and I can only speak of my current situation, engagement of
the invested x-functional team needs to be formalized. In fact this is part
of a process I am working on to transition my very non-design oriented
organization into one that at least has the three legged stool in balance. I
think that many are in a similar position on this list--fighting for any
sort of design-centered approach.

-- dave

1 Feb 2005 - 6:25am
Lada Gorlenko
2004

DH> 3. it is important to engage invested team members

I would take it further. Usability heuristic #1: "Speak thy user's
language". In my work (large projects, big teams, difficult clients),
there is no single way to communicate design effectively to every
stakeholder, especially when a designer faces a few dozens of highly
opinionated invested team members in the life of a project.

To people who foot the bill, design is best communicated in a
spreadsheet: this is what it takes to do your critical tasks now, and
these are the same tasks done twice as fast with the new interface;
this is how much it will cost you if someone decides to suit you for
non-accessible application; this is how much you spend on training
today, and this is how much you will have to spend tomorrow.

Try talking to users in the language of scenarios; to system
architects in boxes, arrows, swimlanes, and server calls; and to
developers in prototypes and code. Oh, project managers... Try talking
to project managers in a nice soothing voice of a shrink they
desperately need for the last 20 years and have no time to visit.
Everyone likes pretty picture, so if you have pretty pictures, show
a couple to everyone. But do the talk in their language. See what
happens in your case.

Lada

1 Feb 2005 - 1:30pm
Andrei Herasimchuk
2004

On Feb 1, 2005, at 3:25 AM, Lada Gorlenko wrote:

> In my work (large projects, big teams, difficult clients),
> there is no single way to communicate design effectively to every
> stakeholder, especially when a designer faces a few dozens of highly
> opinionated invested team members in the life of a project.

I have to say I disagree with this. Just like a test for a concept car
communicates the design... because it *is* the design... so does a well
done prototype. You want buy in? You want articulated communication
about the design? Build it. Amazing what happens when people (both end
users and other team members) see and get a feel for the design before
they have yet to build it.

> Everyone likes pretty picture, so if you have pretty pictures, show
> a couple to everyone. But do the talk in their language. See what
> happens in your case.

I largely agree with this last sentiment about speaking others
language, but don't underestimate the power to let your design speak
for itself. If it's not doing that, people need to consider either
their design's aren't strong enough, or they talking around the design
by focusing too much energy on describing rather than building it.

Andrei

1 Feb 2005 - 3:11pm
Lada Gorlenko
2004

AH> I largely agree with this last sentiment about speaking others
AH> language, but don't underestimate the power to let your design speak
AH> for itself. If it's not doing that, people need to consider either
AH> their design's aren't strong enough, or they talking around the design
AH> by focusing too much energy on describing rather than building it.

The power of a good prototype should not be underestimated, I agree.
At the same time, it's not everything.

Yesterday, a System Architect shook my hand and said he would wait for
me to finish conceptual design because he wants the system to "emerge
from the interface design, not the other way around". I told him that
no other System Architect had ever said those words to me. He replied
that no other designer had properly communicated a design to him in
UML. I was deadly flattered :-)

Lada

1 Feb 2005 - 8:15pm
Jim Leftwich
2004

What a great collection of interesting threads currently on the list.
I'm afraid I don't have the time to regularly read through all of
these, but I did this one and found a number of things I'd like to
comment upon.

I truly enjoy and agree with so very much Andrei Herasimchuk says (oh,
and by the way, it's about time we had another Bay Area get-together at
the Hookah Bar in Sunnyvale!). I have always believed in the speed,
breadth of integrative power, and just sheer purity that a single
strong design lead can bring to a problem. I'd qualify that further in
saying that similarly strong leads in all the necessary aspects of
product or system development (that understand the value of the others
- i.e.: engineering, business, etc.) is even more powerful, but in my
long career, fairly rare. What separates truly extraordinary and
transcendent products or systems from the merely adequate (I won't even
talk about poor efforts) is vision. Until such time that the
communication and coordination between *separate minds* can reach the
speed and integration of neurons within a single mind with vision and
experience, the latter will always be capable of creating and
*inspired* solution.

The higher up the food chain this capability and leadership resides (or
is consulting into), the greater the likelihood of an inspired and
elegant solution. Now this doesn't by any means insure larger business
success, because there are many extenuating and complex forces at play
in the product world. It also doesn't imply that such a leader is
always *right*, but in the long term, and especially when it comes to
significant or revolutionary *innovation* (as opposed to the
overwhelming majority of development that is merely "me too" or
evolutionary feature creep), a design leader with vision will very
often drive a product or system to greater and more successful heights.

I ceased arguing about this years ago when my body of work and track
record had piled up to a point where it could speak for itself. But it
is true that I started my interaction design career in the early 1980s
with the idea that such a thing was not only possible, but provable. I
guess I'll have to blame a design education where the heros were the
Bauhaus designers and egoist architects like Frank Lloyd Wright, and
maybe even good ol' Howard Roark.

While it's true that many design group processes have yielded great and
significant successes, it's also true that I've been brought in by
clients after some of the most famous of these have taken their whack
at it. I've also witnessed internal development processes that more
closely resembled a bunch of monkeys attempting to breed a football,
than getting on with real and inspired design solutions. This is just
a fact of group dynamics.

Now, there's one statement Andrei H. made that I have to not simply
disagree with, but claim outright disproof of:

> What I can tell you is that a prototype can't be simple wireframes or
> flow diagrams or the like.

In over twenty years, and dozens of successful and complex projects,
ranging from room-sized machines, to OS GUIs, to handheld and wearable
devices, to medical systems, military devices and systems, financial
software, interactive television systems, and more, ninety-nine percent
of my design work and iterative tools have consisted of just
storyboarded thumbnails and wireframe diagrams. I couldn't count the
number of projects where I didn't have an opportunity to physically
interact with the system until it was manufactured.... and then went on
to win numerous design awards for its design and usability, and great
economic and usability success in the global marketplace.

Okay, so am I saying prototyping is not worth it? Absolutely not. You
see, when I started, there really were no prototyping tools of enough
efficiency to be worth it. So I learned very early on to work in
wireframes and thumbnails. And I learned to use these as the driving
force of the projects, and as communication tools for interacting with
the other developers and teammembers. In the early days, say from the
mid-1980s to the mid-1990s, this was also efficient, as I had primarily
only my own time and effort to spend on a project, and I wanted to make
certain that I was spending my time pumping detail and functionality
and specification into the project, rather than producing a
dog-and-pony show. Nowadays, another factor is coming into play -
greatly compressed (and ever-accelerating) time cycles. Projects that
used to take a year or two to create, are now regularly required to be
finished in three months (at least the design phase). This means that
as designers, you don't have one second to lose. If you're burning
your effort on programming mockups (unless you're truly as fast as
wireframes and storyboards, which I've not yet seen), then more power
to you. But documents have a number of distinct advantages, in that
they're more compact, provide more overview as to interrelationships
*across the entire architecture*, and leave you with a document of your
design that's more portable and accessible than a prototype.
Particularly when showing a new client or team the *whole complexity*
of what you've designed in the past.

Also, I have the ability to envision and play out interaction in my
head. I guess this isn't a universal capability, but I'm certain that
many have that ability because I've met them. Beethoven was deaf,
after all. The human brain is capable of many different ways and
talents of approaching problems. Bottom line here is that I mostly
object to people saying something "can't be done" or "has to be done
this way." I'm not claiming that everybody can design the way I do,
but I am saying that it's possible, and have proof of its advantages
and successes.

Some would say that interactive mockups are necessary as persuasion
tools. This may hold for some, or even most people. Personally, I
just push it through with my own force of personality. It's not always
pretty, but it has always gotten the job done. And in the vast
majority of cases, was later recognized as the right thing to do by
those that might otherwise have been nervous at the time. What will
establish this trust with clients or other teammembers, however, is
proof of your past successes. You have to document your work and
successes as you go. No other means provides as much throw-weight, if
you want to take Andrei's and my approach to design.

For anyone traveling to Montreal next month to the IA Summit 2005, I'll
be presenting a retrospective of my twenty year career and lessons
learned in interaction design and user experience, along with a
companion presentation being given by Bill DeRouchey of Ziba Design in
Portland. It's the best way for me to give specific examples of the
kinds of things I'm describing above.

Jim

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
James Leftwich, IDSA
Orbit Interaction
Palo Alto, California
650.325.1935 office
650.387.2550 cell
jleft at orbitnet.com
http://www.orbitnet.com/
http://www.anigami.com/jimwich.html
http://www.fotolog.net/jimwich
http://www.fotolog.net/faces

3 Feb 2005 - 1:30am
Andrei Herasimchuk
2004

On Feb 1, 2005, at 5:15 PM, Jim Leftwich wrote:

> Now, there's one statement Andrei H. made that I have to not simply
> disagree with, but claim outright disproof of:
>
>> What I can tell you is that a prototype can't be simple wireframes or
>> flow diagrams or the like.
>
> In over twenty years, and dozens of successful and complex projects,
> ranging from room-sized machines, to OS GUIs, to handheld and wearable
> devices, to medical systems, military devices and systems, financial
> software, interactive television systems, and more, ninety-nine
> percent of my design work and iterative tools have consisted of just
> storyboarded thumbnails and wireframe diagrams.

99%? So you delivered no final artwork, icons, spec'd layout or
documentation on how the product works ever? I think you're being coy
with me, Jim. 8^)

By the way, I'm not sure how what I said translates to not using
wireframes and storyboards. Far more preferable tools by me than other
tools. All I did was set parameters for a prototype is not in the
context of my message. IOW, if you use just wireframes and storyboards,
great, go right ahead... Just don't call them a prototype while I'm in
the room because I'll disagree with you in front of everybody. 8^)

> I couldn't count the number of projects where I didn't have an
> opportunity to physically interact with the system until it was
> manufactured.... and then went on to win numerous design awards for
> its design and usability, and great economic and usability success in
> the global marketplace.

Ok... seriously. I think I know what you are saying, but this statement
makes it sound like you basically let someone else do all the final
design work for you. I know that's not what you mean, so maybe you
might want to clarify it a bit more?

> You see, when I started, there really were no prototyping tools of
> enough efficiency to be worth it.

I want to make sure that I'm not giving off the impression that the
tools today are any better. I used to use Director for a lot of this
work. Lately I'm getting help from folks who know Flash better than I
do. Quite frankly, both tools are woefully inadequate for want I want
to do, but what I want is a very niche product that no one seems has
any market value to produce. So one learns to cope with what one has
available.

> So I learned very early on to work in wireframes and thumbnails. And
> I learned to use these as the driving force of the projects, and as
> communication tools for interacting with the other developers and
> teammembers.

I also want to make sure people know that I don't devalue those things.
I use them constantly myself. I'm just claiming given a range of tools
and a preference for an ideal, I find a certain set of them work better
for the largest set of project types and team styles when it comes to
driving design decisions and helping in team communication.

> Also, I have the ability to envision and play out interaction in my
> head. I guess this isn't a universal capability, but I'm certain that
> many have that ability because I've met them.

Define "many."

> Bottom line here is that I mostly object to people saying something
> "can't be done" or "has to be done this way." I'm not claiming that
> everybody can design the way I do, but I am saying that it's possible,
> and have proof of its advantages and successes.

To lighten the mood... I'm not claiming that people should design the
way I do or it has to be done a certain way. However, I will claim that
if we go head to head with an employer or a contract job, and they see
how my process works as opposed to what you've just described... I'm
willing to bet I'll win the contract. 8^)

> Some would say that interactive mockups are necessary as persuasion
> tools. This may hold for some, or even most people. Personally, I
> just push it through with my own force of personality.

Imagine how large that cult of personality would be with a well formed
prototype behind it. Having had drinks with you, I know both our egos
can easily fill the room. I'll just be packing a larger gun than you.

> What will establish this trust with clients or other teammembers,
> however, is proof of your past successes. You have to document your
> work and successes as you go. No other means provides as much
> throw-weight, if you want to take Andrei's and my approach to design.

Largely agree with this. The hardest thing to do is learning how to
build the small successes over time so that you have a body of work for
exactly this purpose.

Andrei

3 Feb 2005 - 8:18am
Jonas Löwgren
2003

I may have been missing parts of this thread, but apart from persuasive
value there is also the properties of different expressive materials in
the hands of the single designer.

When designing digital stuff with its highly interactive behavior and
temporal flows, I typically find prototype implementations important.
They talk back to me in a way that thumbnail sketches or even detailed
static sketches don't. They form a responsive material and show me ways
forward in the design process.

Personally, I find both pencil sketches and implementation sketches
necessary.

But maybe this is all off topic.

Regards,
Jonas Löwgren

----
Arts and Communication
Malmö University, SE-205 06 Malmö, Sweden

phone +46 7039 17854
web http://webzone.k3.mah.se/k3jolo

Syndicate content Get the feed