I am not just a designer; I am a problem solver

23 Jun 2007 - 5:59pm
7 years ago
24 replies
578 reads
Dave Cortright
2005

One concept I've been kicking around for a while is a broader definition of
"design". A mentor and colleague of mine—Phil Haine over at Obvious
Design—has been working a similar idea that he calls the design pyramid. The
basic premise is that there are multiple stages of creating a new product
that includes information gathering, problem definition, and refinement, and
that these steps are required before you even get to design. Each of those
stages benefits heavily from having "design thinking" (for lack of a better
term) applied. All too often, designers are not brought in until the "design
phase" when they are handed the results of these early stages and are
expected to take them as gospel and produce a brilliant design from that.

But the foundation of the pyramid is not solid. The problem definition
includes language that forces particular solutions, or the premise of the
user need is suspect or even missing altogether. And too often, not nearly
enough time and due diligence is put into the foundational work up-front, so
that during the design and even implementation and testing, the
foundation—requirements, user needs, and even vision itself—changes.

I'm not sure if I'm being overly pessimistic here, or just realistic. But
either way, I'm thinking of pitching my role to the team as a *problem
solver*. In the early stages, I'm the *problem definer* who can gather
information and pull it together into understanding of users and their unmet
needs and desires. From there, I can help generate product requirements with
each one directly linked to an observed user need, and each one also phrased
in such a way as to leave the actual solution/implementation details up to
the designers and developers. And finally, I can test the requirements, make
sure they form a cohesive vision, and spend time up-front to iterate on
them, plug any holes, fix any inconsistencies, sell the vision to the team
and execs and generally make sure that they will stand as is with little to
no modifications throughout the entire project.

With that done, I become the *solution designer*. I take the vision and
requirements, brainstorm a myriad of ways to solve the problem, mock up,
prototype, review, test, revise… you know, all the good stuff we do today.
But with the advantage that I'm not using my design time to help the team
feel around in the dark trying to find the right design by producing and
eliminating all of the wrong ones.

What do you all think of this? Do you think the problem definer should be a
different person than the solution designer? Is there a way to frame this to
help get acceptance of the idea on project teams? Do you already feel your
organization is doing this well? Looking forward to your diverse and
insightful comments!

·Dave

Comments

24 Jun 2007 - 11:29am
Charles Zicari
2007

This strikes me as going way to broad in your definition. Unless your
work environment is a self-aware bureaucracy, I think you'll have a
hell of a time positioning yourself in the role of solution designer
/ problem solver. I come from the agency world where every discipline
would consider themselves "problem solvers" of some sort, with each
solving a particular type of problem (information architecture,
visual design, copywriting, project and account management,
developer, receptionist, refrigerator stocking, etc).

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://beta.ixda.org/discuss?post=17551

24 Jun 2007 - 11:56am
mtumi
2004

Well the problem is if you're the problem solver, what's everyone
else? Assistants to the problem solver?

I agree with you in that designers are too often seen as prettifying
a solution, whereas a good designer takes the content and
functionality into account in the course of putting the visual design
together.

Companies that have someone with little or no visual training putting
together wireframes can really miss the boat here, because even if
that person is just positioning rectangles with labels on the page,
they are now invested in the placement of those rectangles. I think
a lot of design error is introduced in the gap between the wireframer
(who could be a product manager, an information architect, etc) and
the visual designer.

I would also agree with you that I think the better solution will
come from the person who is working on every aspect of the product,
assuming they are well-informed on what they are trying to do in each
stage of design/development. I'm definitely in favor of a more
holistic view of interaction design, with the interaction designer
being someone who is more like an architect, and has the engineering
knowledge to make the structure stand, the aesthetic skill to make it
attractive, and the functional knowhow to make it work as a hospital/
house/apartment building/whatever.

So functionally, I am in complete agreement with that being the role
of the designer. Politically/organizationally, it would seem to me
if you walk into a room and tell everyone else you're going to be the
"problem definer" and then the "problem solver", you are going to be
shooting yourself in the foot.

Michael

On Jun 23, 2007, at 6:59 PM, David Cortright wrote:

> One concept I've been kicking around for a while is a broader
> definition of
> "design". A mentor and colleague of mine—Phil Haine over at Obvious
> Design—has been working a similar idea that he calls the design
> pyramid. The
> basic premise is that there are multiple stages of creating a new
> product
> that includes information gathering, problem definition, and
> refinement, and
> that these steps are required before you even get to design. Each
> of those
> stages benefits heavily from having "design thinking" (for lack of
> a better
> term) applied. All too often, designers are not brought in until
> the "design
> phase" when they are handed the results of these early stages and are
> expected to take them as gospel and produce a brilliant design from
> that.
>
> But the foundation of the pyramid is not solid. The problem definition
> includes language that forces particular solutions, or the premise
> of the
> user need is suspect or even missing altogether. And too often, not
> nearly
> enough time and due diligence is put into the foundational work up-
> front, so
> that during the design and even implementation and testing, the
> foundation—requirements, user needs, and even vision itself—changes.
>
> I'm not sure if I'm being overly pessimistic here, or just
> realistic. But
> either way, I'm thinking of pitching my role to the team as a *problem
> solver*. In the early stages, I'm the *problem definer* who can gather
> information and pull it together into understanding of users and
> their unmet
> needs and desires. From there, I can help generate product
> requirements with
> each one directly linked to an observed user need, and each one
> also phrased
> in such a way as to leave the actual solution/implementation
> details up to
> the designers and developers. And finally, I can test the
> requirements, make
> sure they form a cohesive vision, and spend time up-front to
> iterate on
> them, plug any holes, fix any inconsistencies, sell the vision to
> the team
> and execs and generally make sure that they will stand as is with
> little to
> no modifications throughout the entire project.
>
> With that done, I become the *solution designer*. I take the vision
> and
> requirements, brainstorm a myriad of ways to solve the problem,
> mock up,
> prototype, review, test, revise… you know, all the good stuff we do
> today.
> But with the advantage that I'm not using my design time to help
> the team
> feel around in the dark trying to find the right design by
> producing and
> eliminating all of the wrong ones.
>
> What do you all think of this? Do you think the problem definer
> should be a
> different person than the solution designer? Is there a way to
> frame this to
> help get acceptance of the idea on project teams? Do you already
> feel your
> organization is doing this well? Looking forward to your diverse and
> insightful comments!
>
> ·Dave
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org

24 Jun 2007 - 12:25pm
Jeff Axup
2006

Hi David,

It's an interesting question that you bring up, and one that I've kicked
around before. I've only got a moment, so I'll just toss out a few related
ideas to consider:

- A problem and a solution appear to have a direct logical and
directional relationship. However, often the problem is defined after you
have a technology solution (we might prefer otherwise, but it is a fact of
life). The problem and solution often iterate, so that both benefit from
further consideration of the other. They may happen in either direction.
- Socio-technical systems are not static. This is one of the reasons
groupware is so hard to build. Your problem statement will shift on you as
soon as it's defined, because it's based on human needs, social behavior and
collaboratively determined meaning.
- What is a problem to one person is not a problem to another person.
There is cultural variation and personal variation.
- A solution to one problem is a cause of another problem - e.g.
automobiles and pollution.
- Who is not a "problem solver"? It's similar to the question of "who
is not a knowledge worker"? The employee at Subway is a great solver. I'm
hungry, she produces the solution of a nice custom-designed sandwich. We all
make money because we solve problems for others. It's just some problems are
a bit more complex or require more training. We haven't found a good
algorithm for design yet, and some might claim we never will (which is
another interesting discussion).

Roughly speaking I agree with you, that we're a certain style of problem
solver for a certain domain of problems. Necessity is the mother of
invention.

-Jeff
____________________________________________________________________________
Jeff Axup, Ph.D.
Principal Consultant, Mobile Community Design Consulting, San Diego

Research: Mobile Group Research Methods, Social Networks, Group Usability
E-mail: axup <at> userdesign.com
Blog: http://mobilecommunitydesign.com
Moblog: http://memeaddict.blogspot.com
____________________________________________________________________________

On 6/24/07, Michael Tuminello <mt at motiontek.com> wrote:
>
> Well the problem is if you're the problem solver, what's everyone
> else? Assistants to the problem solver?
>
> I agree with you in that designers are too often seen as prettifying
> a solution, whereas a good designer takes the content and
> functionality into account in the course of putting the visual design
> together.
>
> Companies that have someone with little or no visual training putting
> together wireframes can really miss the boat here, because even if
> that person is just positioning rectangles with labels on the page,
> they are now invested in the placement of those rectangles. I think
> a lot of design error is introduced in the gap between the wireframer
> (who could be a product manager, an information architect, etc) and
> the visual designer.
>
> I would also agree with you that I think the better solution will
> come from the person who is working on every aspect of the product,
> assuming they are well-informed on what they are trying to do in each
> stage of design/development. I'm definitely in favor of a more
> holistic view of interaction design, with the interaction designer
> being someone who is more like an architect, and has the engineering
> knowledge to make the structure stand, the aesthetic skill to make it
> attractive, and the functional knowhow to make it work as a hospital/
> house/apartment building/whatever.
>
> So functionally, I am in complete agreement with that being the role
> of the designer. Politically/organizationally, it would seem to me
> if you walk into a room and tell everyone else you're going to be the
> "problem definer" and then the "problem solver", you are going to be
> shooting yourself in the foot.
>
> Michael
>
>
>
> On Jun 23, 2007, at 6:59 PM, David Cortright wrote:
>
> > One concept I've been kicking around for a while is a broader
> > definition of
> > "design". A mentor and colleague of mine—Phil Haine over at Obvious
> > Design—has been working a similar idea that he calls the design
> > pyramid. The
> > basic premise is that there are multiple stages of creating a new
> > product
> > that includes information gathering, problem definition, and
> > refinement, and
> > that these steps are required before you even get to design. Each
> > of those
> > stages benefits heavily from having "design thinking" (for lack of
> > a better
> > term) applied. All too often, designers are not brought in until
> > the "design
> > phase" when they are handed the results of these early stages and are
> > expected to take them as gospel and produce a brilliant design from
> > that.
> >
> > But the foundation of the pyramid is not solid. The problem definition
> > includes language that forces particular solutions, or the premise
> > of the
> > user need is suspect or even missing altogether. And too often, not
> > nearly
> > enough time and due diligence is put into the foundational work up-
> > front, so
> > that during the design and even implementation and testing, the
> > foundation—requirements, user needs, and even vision itself—changes.
> >
> > I'm not sure if I'm being overly pessimistic here, or just
> > realistic. But
> > either way, I'm thinking of pitching my role to the team as a *problem
> > solver*. In the early stages, I'm the *problem definer* who can gather
> > information and pull it together into understanding of users and
> > their unmet
> > needs and desires. From there, I can help generate product
> > requirements with
> > each one directly linked to an observed user need, and each one
> > also phrased
> > in such a way as to leave the actual solution/implementation
> > details up to
> > the designers and developers. And finally, I can test the
> > requirements, make
> > sure they form a cohesive vision, and spend time up-front to
> > iterate on
> > them, plug any holes, fix any inconsistencies, sell the vision to
> > the team
> > and execs and generally make sure that they will stand as is with
> > little to
> > no modifications throughout the entire project.
> >
> > With that done, I become the *solution designer*. I take the vision
> > and
> > requirements, brainstorm a myriad of ways to solve the problem,
> > mock up,
> > prototype, review, test, revise… you know, all the good stuff we do
> > today.
> > But with the advantage that I'm not using my design time to help
> > the team
> > feel around in the dark trying to find the right design by
> > producing and
> > eliminating all of the wrong ones.
> >
> > What do you all think of this? Do you think the problem definer
> > should be a
> > different person than the solution designer? Is there a way to
> > frame this to
> > help get acceptance of the idea on project teams? Do you already
> > feel your
> > organization is doing this well? Looking forward to your diverse and
> > insightful comments!
> >
> > ·Dave
> > ________________________________________________________________
> > Welcome to the Interaction Design Association (IxDA)!
> > To post to this list ....... discuss at ixda.org
> > List Guidelines ............ http://listguide.ixda.org/
> > List Help .................. http://listhelp.ixda.org/
> > (Un)Subscription Options ... http://subscription-options.ixda.org/
> > Announcements List ......... http://subscribe-announce.ixda.org/
> > Questions .................. lists at ixda.org
> > Home ....................... http://ixda.org/
> > Resource Library ........... http://resources.ixda.org
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

24 Jun 2007 - 12:28pm
Ari
2006

at my company, i'm viewed as a problem creator! the developers cringe when
they see my specs and prototypes...

On 6/24/07, Jeff Axup <axup at userdesign.com> wrote:
>
> Hi David,
>
> It's an interesting question that you bring up, and one that I've kicked
> around before. I've only got a moment, so I'll just toss out a few related
> ideas to consider:
>
>
> - A problem and a solution appear to have a direct logical and
> directional relationship. However, often the problem is defined after
> you
> have a technology solution (we might prefer otherwise, but it is a fact
> of
> life). The problem and solution often iterate, so that both benefit
> from
> further consideration of the other. They may happen in either
> direction.
> - Socio-technical systems are not static. This is one of the reasons
> groupware is so hard to build. Your problem statement will shift on you
> as
> soon as it's defined, because it's based on human needs, social
> behavior and
> collaboratively determined meaning.
> - What is a problem to one person is not a problem to another person.
> There is cultural variation and personal variation.
> - A solution to one problem is a cause of another problem - e.g.
> automobiles and pollution.
> - Who is not a "problem solver"? It's similar to the question of "who
> is not a knowledge worker"? The employee at Subway is a great solver.
> I'm
> hungry, she produces the solution of a nice custom-designed sandwich.
> We all
> make money because we solve problems for others. It's just some
> problems are
> a bit more complex or require more training. We haven't found a good
> algorithm for design yet, and some might claim we never will (which is
> another interesting discussion).
>
> Roughly speaking I agree with you, that we're a certain style of problem
> solver for a certain domain of problems. Necessity is the mother of
> invention.
>
> -Jeff
> ____________________________________________________________
> ________________
> Jeff Axup, Ph.D.
> Principal Consultant, Mobile Community Design Consulting, San Diego
>
> Research: Mobile Group Research Methods, Social Networks, Group
> Usability
> E-mail: axup <at> userdesign.com
> Blog: http://mobilecommunitydesign.com
> Moblog: http://memeaddict.blogspot.com
> ____________________________________________________________
> ________________
>
>
> On 6/24/07, Michael Tuminello <mt at motiontek.com> wrote:
> >
> > Well the problem is if you're the problem solver, what's everyone
> > else? Assistants to the problem solver?
> >
> > I agree with you in that designers are too often seen as prettifying
> > a solution, whereas a good designer takes the content and
> > functionality into account in the course of putting the visual design
> > together.
> >
> > Companies that have someone with little or no visual training putting
> > together wireframes can really miss the boat here, because even if
> > that person is just positioning rectangles with labels on the page,
> > they are now invested in the placement of those rectangles. I think
> > a lot of design error is introduced in the gap between the wireframer
> > (who could be a product manager, an information architect, etc) and
> > the visual designer.
> >
> > I would also agree with you that I think the better solution will
> > come from the person who is working on every aspect of the product,
> > assuming they are well-informed on what they are trying to do in each
> > stage of design/development. I'm definitely in favor of a more
> > holistic view of interaction design, with the interaction designer
> > being someone who is more like an architect, and has the engineering
> > knowledge to make the structure stand, the aesthetic skill to make it
> > attractive, and the functional knowhow to make it work as a hospital/
> > house/apartment building/whatever.
> >
> > So functionally, I am in complete agreement with that being the role
> > of the designer. Politically/organizationally, it would seem to me
> > if you walk into a room and tell everyone else you're going to be the
> > "problem definer" and then the "problem solver", you are going to be
> > shooting yourself in the foot.
> >
> > Michael
> >
> >
> >
> > On Jun 23, 2007, at 6:59 PM, David Cortright wrote:
> >
> > > One concept I've been kicking around for a while is a broader
> > > definition of
> > > "design". A mentor and colleague of mine—Phil Haine over at Obvious
> > > Design—has been working a similar idea that he calls the design
> > > pyramid. The
> > > basic premise is that there are multiple stages of creating a new
> > > product
> > > that includes information gathering, problem definition, and
> > > refinement, and
> > > that these steps are required before you even get to design. Each
> > > of those
> > > stages benefits heavily from having "design thinking" (for lack of
> > > a better
> > > term) applied. All too often, designers are not brought in until
> > > the "design
> > > phase" when they are handed the results of these early stages and are
> > > expected to take them as gospel and produce a brilliant design from
> > > that.
> > >
> > > But the foundation of the pyramid is not solid. The problem definition
> > > includes language that forces particular solutions, or the premise
> > > of the
> > > user need is suspect or even missing altogether. And too often, not
> > > nearly
> > > enough time and due diligence is put into the foundational work up-
> > > front, so
> > > that during the design and even implementation and testing, the
> > > foundation—requirements, user needs, and even vision itself—changes.
> > >
> > > I'm not sure if I'm being overly pessimistic here, or just
> > > realistic. But
> > > either way, I'm thinking of pitching my role to the team as a *problem
> > > solver*. In the early stages, I'm the *problem definer* who can gather
> > > information and pull it together into understanding of users and
> > > their unmet
> > > needs and desires. From there, I can help generate product
> > > requirements with
> > > each one directly linked to an observed user need, and each one
> > > also phrased
> > > in such a way as to leave the actual solution/implementation
> > > details up to
> > > the designers and developers. And finally, I can test the
> > > requirements, make
> > > sure they form a cohesive vision, and spend time up-front to
> > > iterate on
> > > them, plug any holes, fix any inconsistencies, sell the vision to
> > > the team
> > > and execs and generally make sure that they will stand as is with
> > > little to
> > > no modifications throughout the entire project.
> > >
> > > With that done, I become the *solution designer*. I take the vision
> > > and
> > > requirements, brainstorm a myriad of ways to solve the problem,
> > > mock up,
> > > prototype, review, test, revise… you know, all the good stuff we do
> > > today.
> > > But with the advantage that I'm not using my design time to help
> > > the team
> > > feel around in the dark trying to find the right design by
> > > producing and
> > > eliminating all of the wrong ones.
> > >
> > > What do you all think of this? Do you think the problem definer
> > > should be a
> > > different person than the solution designer? Is there a way to
> > > frame this to
> > > help get acceptance of the idea on project teams? Do you already
> > > feel your
> > > organization is doing this well? Looking forward to your diverse and
> > > insightful comments!
> > >
> > > ·Dave
> > > ________________________________________________________________
> > > Welcome to the Interaction Design Association (IxDA)!
> > > To post to this list ....... discuss at ixda.org
> > > List Guidelines ............ http://listguide.ixda.org/
> > > List Help .................. http://listhelp.ixda.org/
> > > (Un)Subscription Options ... http://subscription-options.ixda.org/
> > > Announcements List ......... http://subscribe-announce.ixda.org/
> > > Questions .................. lists at ixda.org
> > > Home ....................... http://ixda.org/
> > > Resource Library ........... http://resources.ixda.org
> >
> > ________________________________________________________________
> > Welcome to the Interaction Design Association (IxDA)!
> > To post to this list ....... discuss at ixda.org
> > List Guidelines ............ http://listguide.ixda.org/
> > List Help .................. http://listhelp.ixda.org/
> > (Un)Subscription Options ... http://subscription-options.ixda.org/
> > Announcements List ......... http://subscribe-announce.ixda.org/
> > Questions .................. lists at ixda.org
> > Home ....................... http://ixda.org/
> > Resource Library ........... http://resources.ixda.org
> >
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

--
--------------------------------------------------
www.flyingyogi.com
--------------------------------------------------

24 Jun 2007 - 12:34pm
Jeffrey D. Gimzek
2007

On Jun 24, 2007, at 10:28 AM, Ari Feldman wrote:

> at my company, i'm viewed as a problem creator! the developers
> cringe when
> they see my specs and prototypes...

snark !

i thought being a "problem solver" has ALWAYS the definition of
"designer"

if we were just making pretty things we would be "artists"

> On 6/24/07, Jeff Axup <axup at userdesign.com> wrote:
>>
>> Hi David,
>>
>> It's an interesting question that you bring up, and one that I've
>> kicked
>> around before. I've only got a moment, so I'll just toss out a few
>> related
>> ideas to consider:
>>
>>
>> - A problem and a solution appear to have a direct logical and
>> directional relationship. However, often the problem is defined
>> after
>> you
>> have a technology solution (we might prefer otherwise, but it
>> is a fact
>> of
>> life). The problem and solution often iterate, so that both
>> benefit
>> from
>> further consideration of the other. They may happen in either
>> direction.
>> - Socio-technical systems are not static. This is one of the
>> reasons
>> groupware is so hard to build. Your problem statement will
>> shift on you
>> as
>> soon as it's defined, because it's based on human needs, social
>> behavior and
>> collaboratively determined meaning.
>> - What is a problem to one person is not a problem to another
>> person.
>> There is cultural variation and personal variation.
>> - A solution to one problem is a cause of another problem - e.g.
>> automobiles and pollution.
>> - Who is not a "problem solver"? It's similar to the question
>> of "who
>> is not a knowledge worker"? The employee at Subway is a great
>> solver.
>> I'm
>> hungry, she produces the solution of a nice custom-designed
>> sandwich.
>> We all
>> make money because we solve problems for others. It's just some
>> problems are
>> a bit more complex or require more training. We haven't found a
>> good
>> algorithm for design yet, and some might claim we never will
>> (which is
>> another interesting discussion).
>>
>> Roughly speaking I agree with you, that we're a certain style of
>> problem
>> solver for a certain domain of problems. Necessity is the mother of
>> invention.
>>
>> -Jeff
>> ____________________________________________________________
>> ________________
>> Jeff Axup, Ph.D.
>> Principal Consultant, Mobile Community Design Consulting, San Diego
>>
>> Research: Mobile Group Research Methods, Social Networks, Group
>> Usability
>> E-mail: axup <at> userdesign.com
>> Blog: http://mobilecommunitydesign.com
>> Moblog: http://memeaddict.blogspot.com
>> ____________________________________________________________
>> ________________
>>
>>
>> On 6/24/07, Michael Tuminello <mt at motiontek.com> wrote:
>>>
>>> Well the problem is if you're the problem solver, what's everyone
>>> else? Assistants to the problem solver?
>>>
>>> I agree with you in that designers are too often seen as prettifying
>>> a solution, whereas a good designer takes the content and
>>> functionality into account in the course of putting the visual
>>> design
>>> together.
>>>
>>> Companies that have someone with little or no visual training
>>> putting
>>> together wireframes can really miss the boat here, because even if
>>> that person is just positioning rectangles with labels on the page,
>>> they are now invested in the placement of those rectangles. I
>>> think
>>> a lot of design error is introduced in the gap between the
>>> wireframer
>>> (who could be a product manager, an information architect, etc) and
>>> the visual designer.
>>>
>>> I would also agree with you that I think the better solution will
>>> come from the person who is working on every aspect of the product,
>>> assuming they are well-informed on what they are trying to do in
>>> each
>>> stage of design/development. I'm definitely in favor of a more
>>> holistic view of interaction design, with the interaction designer
>>> being someone who is more like an architect, and has the engineering
>>> knowledge to make the structure stand, the aesthetic skill to
>>> make it
>>> attractive, and the functional knowhow to make it work as a
>>> hospital/
>>> house/apartment building/whatever.
>>>
>>> So functionally, I am in complete agreement with that being the role
>>> of the designer. Politically/organizationally, it would seem to me
>>> if you walk into a room and tell everyone else you're going to be
>>> the
>>> "problem definer" and then the "problem solver", you are going to be
>>> shooting yourself in the foot.
>>>
>>> Michael
>>>
>>>
>>>
>>> On Jun 23, 2007, at 6:59 PM, David Cortright wrote:
>>>
>>>> One concept I've been kicking around for a while is a broader
>>>> definition of
>>>> "design". A mentor and colleague of mine—Phil Haine over at Obvious
>>>> Design—has been working a similar idea that he calls the design
>>>> pyramid. The
>>>> basic premise is that there are multiple stages of creating a new
>>>> product
>>>> that includes information gathering, problem definition, and
>>>> refinement, and
>>>> that these steps are required before you even get to design. Each
>>>> of those
>>>> stages benefits heavily from having "design thinking" (for lack of
>>>> a better
>>>> term) applied. All too often, designers are not brought in until
>>>> the "design
>>>> phase" when they are handed the results of these early stages
>>>> and are
>>>> expected to take them as gospel and produce a brilliant design from
>>>> that.
>>>>
>>>> But the foundation of the pyramid is not solid. The problem
>>>> definition
>>>> includes language that forces particular solutions, or the premise
>>>> of the
>>>> user need is suspect or even missing altogether. And too often, not
>>>> nearly
>>>> enough time and due diligence is put into the foundational work up-
>>>> front, so
>>>> that during the design and even implementation and testing, the
>>>> foundation—requirements, user needs, and even vision itself—
>>>> changes.
>>>>
>>>> I'm not sure if I'm being overly pessimistic here, or just
>>>> realistic. But
>>>> either way, I'm thinking of pitching my role to the team as a
>>>> *problem
>>>> solver*. In the early stages, I'm the *problem definer* who can
>>>> gather
>>>> information and pull it together into understanding of users and
>>>> their unmet
>>>> needs and desires. From there, I can help generate product
>>>> requirements with
>>>> each one directly linked to an observed user need, and each one
>>>> also phrased
>>>> in such a way as to leave the actual solution/implementation
>>>> details up to
>>>> the designers and developers. And finally, I can test the
>>>> requirements, make
>>>> sure they form a cohesive vision, and spend time up-front to
>>>> iterate on
>>>> them, plug any holes, fix any inconsistencies, sell the vision to
>>>> the team
>>>> and execs and generally make sure that they will stand as is with
>>>> little to
>>>> no modifications throughout the entire project.
>>>>
>>>> With that done, I become the *solution designer*. I take the vision
>>>> and
>>>> requirements, brainstorm a myriad of ways to solve the problem,
>>>> mock up,
>>>> prototype, review, test, revise… you know, all the good stuff we do
>>>> today.
>>>> But with the advantage that I'm not using my design time to help
>>>> the team
>>>> feel around in the dark trying to find the right design by
>>>> producing and
>>>> eliminating all of the wrong ones.
>>>>
>>>> What do you all think of this? Do you think the problem definer
>>>> should be a
>>>> different person than the solution designer? Is there a way to
>>>> frame this to
>>>> help get acceptance of the idea on project teams? Do you already
>>>> feel your
>>>> organization is doing this well? Looking forward to your diverse
>>>> and
>>>> insightful comments!
>>>>
>>>> ·Dave
>>>> ________________________________________________________________
>>>> Welcome to the Interaction Design Association (IxDA)!
>>>> To post to this list ....... discuss at ixda.org
>>>> List Guidelines ............ http://listguide.ixda.org/
>>>> List Help .................. http://listhelp.ixda.org/
>>>> (Un)Subscription Options ... http://subscription-options.ixda.org/
>>>> Announcements List ......... http://subscribe-announce.ixda.org/
>>>> Questions .................. lists at ixda.org
>>>> Home ....................... http://ixda.org/
>>>> Resource Library ........... http://resources.ixda.org
>>>
>>> ________________________________________________________________
>>> Welcome to the Interaction Design Association (IxDA)!
>>> To post to this list ....... discuss at ixda.org
>>> List Guidelines ............ http://listguide.ixda.org/
>>> List Help .................. http://listhelp.ixda.org/
>>> (Un)Subscription Options ... http://subscription-options.ixda.org/
>>> Announcements List ......... http://subscribe-announce.ixda.org/
>>> Questions .................. lists at ixda.org
>>> Home ....................... http://ixda.org/
>>> Resource Library ........... http://resources.ixda.org
>>>
>> ________________________________________________________________
>> Welcome to the Interaction Design Association (IxDA)!
>> To post to this list ....... discuss at ixda.org
>> List Guidelines ............ http://listguide.ixda.org/
>> List Help .................. http://listhelp.ixda.org/
>> (Un)Subscription Options ... http://subscription-options.ixda.org/
>> Announcements List ......... http://subscribe-announce.ixda.org/
>> Questions .................. lists at ixda.org
>> Home ....................... http://ixda.org/
>> Resource Library ........... http://resources.ixda.org
>>
>
>
>
> --
> --------------------------------------------------
> www.flyingyogi.com
> --------------------------------------------------
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org

24 Jun 2007 - 2:13pm
Mark Schraad
2006

On Jun 24, 2007, at 1:34 PM, Jeffrey D. Gimzek wrote:

> snark !
>
> i thought being a "problem solver" has ALWAYS the definition of
> "designer"
>

There are may cake decorators out there...

>
> if we were just making pretty things we would be "artists"

24 Jun 2007 - 3:48pm
Josh
2006

When hiring, I'm always on the lookout for creative problem solvers. I'd
prefer to hire someone with the following traits than specific technical
expertise.

People who:

* Are confident enough in their ability to solve problems that they don't
need to know all of the answers ahead of time. The alternative are people
who get disoriented when presented situations that don't go by the book.
* Know where to look/who to ask to find answers to problems.
* Are execution oriented. Know that nothing matters if work doesn't get
done.
* Are actively trying to grow/learn more/experience more in their chosen
field.

I've always considered the job to be like putting together a big puzzle. The
right solution is out there. It just takes the right combination of people,
technology and design to find it.

--
Josh Viney
EastMedia Group
http://www.eastmedia.com

24 Jun 2007 - 6:25pm
Dave Malouf
2005

I'm going to go w/ the "way too broad".
There are many many problem solvers in the world. We are not the only
ones. Designers DO do problem solving, but do it in a specific way (or
collection of specific ways) and with a particular pov (historically
created). Engineers, Business Analysts, and many more are problem
solvers in our space. Even Product Managers are problem solvers and
marketers etc.

Also, design does not exist w/o an eye (ear, nose, tongue, hand) on
aesthetics. That is not the same thing as "pretty things", but it
is connected to engaging (hopefully) positive emotional responses.
Other problem solvers using aren't concerned w/ any other emotion
except satisfaction.

All problem solvers who do their job well (and there are examples of
all the above who do) consider the business. Not all equally well
consider the end user.

-- dave

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://beta.ixda.org/discuss?post=17551

24 Jun 2007 - 6:43pm
Chris McLay
2005

There is a good discussion of this in "Thoughtful Interaction
Design" by Jonas Lowgren and Erik Stolterman. I recommend reading
it, as it will assist in your dilemma.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://beta.ixda.org/discuss?post=17551

24 Jun 2007 - 6:45pm
natekendrick
2005

Problem solving is not a role. It is a task or activity that every
living organism does (albeit consciously or not).

I think the real point here is that there is a real meme lately of
"everyone designs" or "design (thinking) helps everywhere".

Does a designer by trade want to be a part of every step within a
product? Umm... I know I don't. I'd rather everyone involved
understand design (thinking), its uses, and use it in some limited
fashion to help them get their own job done. But everyone is not a
designer, nor should the designer do everyone's job (aka, solution
designer).

-N

On Jun 23, 2007, at 3:59 PM, David Cortright wrote:
> One concept I've been kicking around for a while is a broader
> definition of
> "design". A mentor and colleague of mine—Phil Haine over at Obvious
> Design—has been working a similar idea that he calls the design
> pyramid. The
> basic premise is that there are multiple stages of creating a new
> product
> that includes information gathering, problem definition, and
> refinement, and
> that these steps are required before you even get to design. Each
> of those
> stages benefits heavily from having "design thinking" (for lack of
> a better
> term) applied. All too often, designers are not brought in until
> the "design
> phase" when they are handed the results of these early stages and are
> expected to take them as gospel and produce a brilliant design from
> that.
>
> But the foundation of the pyramid is not solid. The problem definition
> includes language that forces particular solutions, or the premise
> of the
> user need is suspect or even missing altogether. And too often, not
> nearly
> enough time and due diligence is put into the foundational work up-
> front, so
> that during the design and even implementation and testing, the
> foundation—requirements, user needs, and even vision itself—changes.
>
> I'm not sure if I'm being overly pessimistic here, or just
> realistic. But
> either way, I'm thinking of pitching my role to the team as a *problem
> solver*. In the early stages, I'm the *problem definer* who can gather
> information and pull it together into understanding of users and
> their unmet
> needs and desires. From there, I can help generate product
> requirements with
> each one directly linked to an observed user need, and each one
> also phrased
> in such a way as to leave the actual solution/implementation
> details up to
> the designers and developers. And finally, I can test the
> requirements, make
> sure they form a cohesive vision, and spend time up-front to
> iterate on
> them, plug any holes, fix any inconsistencies, sell the vision to
> the team
> and execs and generally make sure that they will stand as is with
> little to
> no modifications throughout the entire project.
>
> With that done, I become the *solution designer*. I take the vision
> and
> requirements, brainstorm a myriad of ways to solve the problem,
> mock up,
> prototype, review, test, revise… you know, all the good stuff we do
> today.
> But with the advantage that I'm not using my design time to help
> the team
> feel around in the dark trying to find the right design by
> producing and
> eliminating all of the wrong ones.
>
> What do you all think of this? Do you think the problem definer
> should be a
> different person than the solution designer? Is there a way to
> frame this to
> help get acceptance of the idea on project teams? Do you already
> feel your
> organization is doing this well? Looking forward to your diverse and
> insightful comments!
>
> ·Dave

24 Jun 2007 - 7:40pm
Mark Schraad
2006

Great, great book. Worth reading a couple of time in spite of the
time it takes. I contains a lot of provoking thought... very dense
with information.

Mark

On Jun 24, 2007, at 7:43 PM, Chris McLay wrote:

> There is a good discussion of this in "Thoughtful Interaction
> Design" by Jonas Lowgren and Erik Stolterman. I recommend reading
> it, as it will assist in your dilemma.

25 Jun 2007 - 9:36am
Greg Petroff
2004

One of the interesting components of the design process is not problem
solving but what Patrick Whitney of the IIT ID school calls "options
finding". That's where at the begining of a process a designer can
add alot of impact. The "Make to think" rapid iteration aspects of
design process can be a very useful method for defining what problem
you are trying to solve and setting up clear pricinciples to carry
out through a project.

-greg

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://beta.ixda.org/discuss?post=17551

25 Jun 2007 - 9:44am
Mark Schraad
2006

I have found that getting consensus on the definition of the problem is the most difficult step. Many, many designers assume that the problem they are presented with is correct - and often it is not. Once the problem is determined and everyone agrees - projects just seem to fly.

On Monday, June 25, 2007, at 10:38AM, "greg" <greg.petroff at sap.com> wrote:
>One of the interesting components of the design process is not problem
>solving but what Patrick Whitney of the IIT ID school calls "options
>finding". That's where at the begining of a process a designer can
>add alot of impact. The "Make to think" rapid iteration aspects of
>design process can be a very useful method for defining what problem
>you are trying to solve and setting up clear pricinciples to carry
>out through a project.
>
>-greg
>
>

25 Jun 2007 - 10:00am
Dan Saffer
2003

About Face 3 (which I am reading and enjoying) has a diagram (1-1)
about how design and designers have evolved in product design from
not being involved at all to being stylists that come in at the end
of the process to being involved in "product definition." Might want
to check that out.

Dan

25 Jun 2007 - 10:59am
.pauric
2006

"Do you think the problem definer should be a different person than
the solution designer?"

Yes, no one is perfect. Anything overlooked in the definition scope
will not be caught by the same set of eyes when defining the
solution. Single point of failure.

A classic example is that of the Hubble Telescope mirror where the
same tool that created the mirror was used to test that the mirror
was up to spec.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://beta.ixda.org/discuss?post=17551

25 Jun 2007 - 12:03pm
Will Parker
2007

On Jun 25, 2007, at 8:59 AM, pauric wrote:

> "Do you think the problem definer should be a different person than
> the solution designer?"
>
> Yes, no one is perfect. Anything overlooked in the definition scope
> will not be caught by the same set of eyes when defining the
> solution. Single point of failure.
>
> A classic example is that of the Hubble Telescope mirror where the
> same tool that created the mirror was used to test that the mirror
> was up to spec.

Actually, I think you meant "was NOT up to spec".

The core mis-assumption in that case was that the tool was up to
spec, and therefore could be used in both the production and testing
phases. Nobody bothered to check the validity of the spec, however.

I worked for a company with that problem a few years ago. Three PMs
were each responsible for different sections of each of three inter-
related specs, so NOBODY actually 'owned' the specs. Turns out that
there was a serious omission in one of the specs, and no-one noticed
because each of the troika assumed that issue was covered adequately
in the sections they didn't own. When I pointed out that this flawed
spec had been sent off to hardware manufacturers months ago, and we
were about to start trials with said hardware, the project got
postponed and I (coincidentally) got laid off.

In other words, a single point of failure isn't always the surest way
to disaster. Sometimes it's easier to get to Project Armageddon when
multiple people are involved.

The primary source of design flaws I see is this -- nobody 'owns' the
whole design. By this I mean that on most projects, no one person has
the oversight to see all the planning and the authority to impose
decisions (when necessary) on the rest of the team to insure project
success.

I think the division between 'problem definer' and 'solution
designer' is a false one -- in fact, those two role descriptions
don't seem particularly interesting (to me) in the design process.
Once you've done the research on your audience and your problem,
talented designers, alone or as a group, can and usually do fill both
roles. The IxD/IA practitioners among them can play along, but
ideally do so in the role of editor-in-chief, keeping the whole pack
targeted on achieving the customer-facing goals.

- Will

Will Parker
wparker at ChannelingDesign.com

“I wish developing great products was as easy as writing a check. If
that were the case, then Microsoft would have great products.” -
Steve Jobs

25 Jun 2007 - 12:07pm
David Walker
2007

Yes! There is a great description of this iterative process in a book by
J.V Matson: "Using Intelligent Fast Failure: The Art of Innovation".
Creative people - artists, authors, designers - tend to circle their
problems instead of going directly to the "obvious" solutions. There is an
aspect of enjoyment. Innovators tend to describe the process of
problem-solving as enjoyable.

Developers also create, but in my experience they derive enjoyment from the
creation of elegant object-oriented structures, not interactive nor visual
designs.

- Dave

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of greg
Sent: Monday, June 25, 2007 10:36 AM
To: discuss at lists.interactiondesigners.com
Subject: Re: [IxDA Discuss] I am not just a designer; I am a problem solver

One of the interesting components of the design process is not problem
solving but what Patrick Whitney of the IIT ID school calls "options
finding". That's where at the begining of a process a designer can
add alot of impact. The "Make to think" rapid iteration aspects of
design process can be a very useful method for defining what problem
you are trying to solve and setting up clear pricinciples to carry
out through a project.

-greg

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://beta.ixda.org/discuss?post=17551

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://beta.ixda.org/guidelines
List Help .................. http://beta.ixda.org/help
Unsubscribe ................ http://beta.ixda.org/unsubscribe
Questions .................. list at ixda.org
Home ....................... http://beta.ixda.org

25 Jun 2007 - 12:08pm
Ari
2006

i tend to agree with this approach.
at my company, i own the specs but they are guidelines, not canon as there
are limitations on the backend i'm not aware or more often, time
constraints. thus, specs (and my specs are massive yet constantly updated)
are collaboratively discussed to get to the desired end.

someone must own the process and the 'big picture' while not working within
a vacuum. they must see all sides and work to come up with the best solution
given time, user experience and resources.

On 6/25/07, Will Parker <wparker at channelingdesign.com> wrote:
>
> On Jun 25, 2007, at 8:59 AM, pauric wrote:
>
> > "Do you think the problem definer should be a different person than
> > the solution designer?"
> >
> > Yes, no one is perfect. Anything overlooked in the definition scope
> > will not be caught by the same set of eyes when defining the
> > solution. Single point of failure.
> >
> > A classic example is that of the Hubble Telescope mirror where the
> > same tool that created the mirror was used to test that the mirror
> > was up to spec.
>
> Actually, I think you meant "was NOT up to spec".
>
> The core mis-assumption in that case was that the tool was up to
> spec, and therefore could be used in both the production and testing
> phases. Nobody bothered to check the validity of the spec, however.
>
> I worked for a company with that problem a few years ago. Three PMs
> were each responsible for different sections of each of three inter-
> related specs, so NOBODY actually 'owned' the specs. Turns out that
> there was a serious omission in one of the specs, and no-one noticed
> because each of the troika assumed that issue was covered adequately
> in the sections they didn't own. When I pointed out that this flawed
> spec had been sent off to hardware manufacturers months ago, and we
> were about to start trials with said hardware, the project got
> postponed and I (coincidentally) got laid off.
>
> In other words, a single point of failure isn't always the surest way
> to disaster. Sometimes it's easier to get to Project Armageddon when
> multiple people are involved.
>
> The primary source of design flaws I see is this -- nobody 'owns' the
> whole design. By this I mean that on most projects, no one person has
> the oversight to see all the planning and the authority to impose
> decisions (when necessary) on the rest of the team to insure project
> success.
>
> I think the division between 'problem definer' and 'solution
> designer' is a false one -- in fact, those two role descriptions
> don't seem particularly interesting (to me) in the design process.
> Once you've done the research on your audience and your problem,
> talented designers, alone or as a group, can and usually do fill both
> roles. The IxD/IA practitioners among them can play along, but
> ideally do so in the role of editor-in-chief, keeping the whole pack
> targeted on achieving the customer-facing goals.
>
> - Will
>
> Will Parker
> wparker at ChannelingDesign.com
>
> "I wish developing great products was as easy as writing a check. If
> that were the case, then Microsoft would have great products." -
> Steve Jobs
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://beta.ixda.org/guidelines
> List Help .................. http://beta.ixda.org/help
> Unsubscribe ................ http://beta.ixda.org/unsubscribe
> Questions .................. list at ixda.org
> Home ....................... http://beta.ixda.org
>

--
--------------------------------------------------
www.flyingyogi.com
--------------------------------------------------

25 Jun 2007 - 12:17pm
LukeW
2004

"I'm a problem solver. That's really all design is -problem solving.
Sometimes a client will bring me a project that has virtually no
problem to solve so I create one."

http://www.designerslashmodel.com/

(trust me, watch this video.)

::
:: Luke Wroblewski -[ www.lukew.com ]
:: Principal/Founder, LukeW Interface Designs
:: luke at lukew.com | 408.513.7207
::
:: Blog: http://www.lukew.com/ff/
:: Book: http://www.lukew.com/resources/site_seeing.html
::

25 Jun 2007 - 1:40pm
Steven Chalmers
2007

Luke, I love it. Well worth watching.

25 Jun 2007 - 1:13pm
Will Parker
2007

> On 6/25/07, Will Parker <wparker at channelingdesign.com> wrote:
>
> The primary source of design flaws I see is this -- nobody 'owns' the
> whole design. By this I mean that on most projects, no one person has
> the oversight to see all the planning and the authority to impose
> decisions (when necessary) on the rest of the team to insure project
> success.
>
> I think the division between 'problem definer' and 'solution
> designer' is a false one -- in fact, those two role descriptions
> don't seem particularly interesting (to me) in the design process.
> Once you've done the research on your audience and your problem,
> talented designers, alone or as a group, can and usually do fill both
> roles. The IxD/IA practitioners among them can play along, but
> ideally do so in the role of editor-in-chief, keeping the whole pack
> targeted on achieving the customer-facing goals.

On Jun 25, 2007, at 10:08 AM, Ari Feldman wrote:

> i tend to agree with this approach.
>
> at my company, i own the specs but they are guidelines, not canon
> as there are limitations on the backend i'm not aware or more
> often, time constraints. thus, specs (and my specs are massive yet
> constantly updated) are collaboratively discussed to get to the
> desired end.

Sort of like The Pirate Code? "Not so much rules as ... guidelines" };->

I'm very much in favor of huge, massively detailed specs, but then
I'm used to huge massive application suites with delivery cycles
measured in years. I am currently working on advertising microsites
with conception to lights-out in under a month, so I'm being schooled
otherwise.

I'm now working on more bottom-up control by educating the rest of my
group on general usable-design principles so we can avoid little
problems like 'no link to home page/view' and 'don't try to sell the
customer accessories for a device they haven't bought yet'.

> someone must own the process and the 'big picture' while not
> working within a vacuum. they must see all sides and work to come
> up with the best solution given time, user experience and resources.

In the Mac Office group at Microsoft, I saw several talented PMs plus
one determined usability engineer enforce top-down design order with
great success, but this isn't the only fruitful model.

In my current job, I'm not in the established 'design group', but I'm
insisting on sitting in on early design briefs -- ostensibly so I can
start working on catching design bugs, but actually so I can start
debugging the design process.

- Will

Will Parker
wparker at ChannelingDesign.com

“I wish developing great products was as easy as writing a check. If
that were the case, then Microsoft would have great products.” -
Steve Jobs

25 Jun 2007 - 1:43pm
Ari
2006

On 6/25/07, Will Parker <wparker at channelingdesign.com> wrote:
>
>
> On 6/25/07, Will Parker <wparker at channelingdesign.com> wrote:
> >
> >
> > The primary source of design flaws I see is this -- nobody 'owns' the
> > whole design. By this I mean that on most projects, no one person has
> > the oversight to see all the planning and the authority to impose
> > decisions (when necessary) on the rest of the team to insure project
> > success.
> >
> > I think the division between 'problem definer' and 'solution
> > designer' is a false one -- in fact, those two role descriptions
> > don't seem particularly interesting (to me) in the design process.
> > Once you've done the research on your audience and your problem,
> > talented designers, alone or as a group, can and usually do fill both
> > roles. The IxD/IA practitioners among them can play along, but
> > ideally do so in the role of editor-in-chief, keeping the whole pack
> > targeted on achieving the customer-facing goals.
>
>
>
> On Jun 25, 2007, at 10:08 AM, Ari Feldman wrote:
>
>
>
> i tend to agree with this approach.
>
> at my company, i own the specs but they are guidelines, not canon as there
> are limitations on the backend i'm not aware or more often, time
> constraints. thus, specs (and my specs are massive yet constantly updated)
> are collaboratively discussed to get to the desired end.
>
>
>
> Sort of like The Pirate Code? "Not so much rules as ... guidelines" };->
>

they have to be. unless i'm a client, then they're rules. but when working
to get a product done, you learn to be less rigid.

I'm very much in favor of huge, massively detailed specs, but then I'm used
> to huge massive application suites with delivery cycles measured in years. I
> am currently working on advertising microsites with conception to lights-out
> in under a month, so I'm being schooled otherwise.
>

of course. when i worked on small projects, my specs were small. now i'm
working on a massive, massive application so the documentation has to be
extensive since generations of product releases and ideas need to be
tracked.

I'm now working on more bottom-up control by educating the rest of my group
> on general usable-design principles so we can avoid little problems like 'no
> link to home page/view' and 'don't try to sell the customer accessories for
> a device they haven't bought yet'.
>

sure.

someone must own the process and the 'big picture' while not working within
> a vacuum. they must see all sides and work to come up with the best solution
> given time, user experience and resources.
>
>
>
> In the Mac Office group at Microsoft, I saw several talented PMs plus one
> determined usability engineer enforce top-down design order with great
> success, but this isn't the only fruitful model.
>

agreed.

In my current job, I'm not in the established 'design group', but I'm
> insisting on sitting in on early design briefs -- ostensibly so I can start
> working on catching design bugs, but actually so I can start debugging the
> design process.
>

gotcha. in my job, i'm UI guy and head of product all-in-one.

- Will
>
> Will Parker
> wparker at ChannelingDesign.com
>
>
> "*I wish developing great products was as easy as writing a check. If that
> were the case, then Microsoft would have great products*." - Steve Jobs
>
>
>

--
--------------------------------------------------
www.flyingyogi.com
--------------------------------------------------

25 Jun 2007 - 2:56pm
Jeff Howard
2004

In Malcolm McCullough's Digital Dround, he brings up the point that
the worst misstep you can make in design is to solve the wrong
problem. He puts forth "problem seeking" as a complement to problem
solving.

"Because problems are seldom determinate in any case, this seeking
tends to involve selective attention to the more telling aspects of a
situation. Designs become distintuished by which considerations have
been given attention, among an excess of possibilties. [167]"

Many disciplines solve problems by focusing on the decision between a
range of options. What designers bring to the table is the ability to
look at a situation and generate new options.

// jeff

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://beta.ixda.org/discuss?post=17551

27 Jun 2007 - 11:06am
DrWex
2006

For several years I've used a set of four 'D's to describe what I do:
Discover, Define, Design, Deliver. I think I got this four-part
description originally from discussions with Aaron Marcus but in the
years since I see it's spread all over the Web.

Discovery refers to the parts of our work that go into figuring out
what the problem is. User interviews and observational methods.

Define refers to the process of turning observational data into
communication forms the appropriate audiences can understand, like
writing requirements for PMs, tech specs for developers, powerpoint
presentations, etc.

Design we could probably argue about forever, but when I say it I'm
referring to the production of various design artifacts from pencil
sketches and storyboards to IA diagrams and detailed screen images.

Deliver for me covers the integration of UX ideas, concepts and
practices into the surrounding (or "hosting" if you will) development
method. Frankly, there's no point in spending time making personas if
nobody's going to look at them and use them. And so on. I have tended
to work more on software products than Web sites or applications and
I'm often in a situation where development and QA teams are large and
IxDA resources are think on the ground. I try to fit what I know (a
toolkit of best practices, if you will) into what the company expects
its dev organization to do.

I respectfully disagree that this is beyond the scope of any one
person. Ideally, of course, we'd have a team and people would develop
a variety of expertises. But when I'm the one guy doing interaction
design then my choices are 'do it all' or 'leave it un-done.'

Best,
--Alan

Syndicate content Get the feed