[IxDA Discuss] I am not just a designer; I am a problem solver

Sun Jun 24 10:25:27 PDT 2007

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
>