agile-usability : Messages : 6660-6689 of 7636

On Dec 6, 2009, at 11:10 AM, Ron Jeffries wrote:

0 < p < 1

One vibe I sometimes get here is "I am the designer and you mere
humans should just take what I say as true." My points are two:

1. Even if what such a person says is true, it will require
discussion in order to get people to accept it as true;

2. That discussion needs to be sincerely respectful, especially when
being held with the person paying for the project.

So one best practice (for lack of better term, though I despise the notion of 'best practices') we've found amongst the best teams: They resist making recommendations for changes in the design.

Think of this progression:

Observation - You see something that strikes you as important. Maybe it's a user behavior. Maybe it's a report from a customer. Maybe it's something a competitor has done.

Inference - You form an explanation as to what the observation means. If the user is clicking on the wrong thing, you decide they must not know what the button means. If the report from the customer says that they are getting a certain error message, you decide they must have run into a specific bug.

Opinion - You form a reason as to why this should be addressed. If the user doesn't know what the button means, you must think about alternative button labels and, perhaps, some explanatory text.

Recommendation - You describe to the team what the change should be. If you need to change the button label, you propose a new label and prompt.

Decision - The team decides the change is worth making.

One thing we've observed in our research of the best teams vs. those that struggle to produce great designs is that the latter group rushes through these five steps in the progression really, really fast.

However, the best teams take their time, often questioning the initial inferences that come from the observations, looking for alternative explanations. They often put together explorations to look to eliminate unlikely inferences and gather more information. By the time they get to the recommendation, they've not only convinced others, they've convinced themselves they've got the right solution.

The other interesting distinction between the struggling teams and the best teams: the progression for the struggling teams is often done solo, where the progression for the best teams is a team effort, practically every step of the way. As we observed the teams in action, this difference really jumped out at us.

So, I agree with you 100%. The vibe you describe is far more common in the struggling teams than in the best teams.

Jared

Jared M. Spool

User Interface Engineering

510 Turnpike St., Suite 102, North Andover, MA 01845

e: jspool@... p: +1 978 327 5561

http://uie.com Blog: http://uie.com/brainsparks Twitter: @jmspool

#6661

From: mark schraad <mschraad@...>
Date: Sun Dec 6, 2009 7:42 pm
Subject: Re: Agile vs. Creativity

mschraad333

You can point that in pretty much any direction Ron. As I have said before, the larger debate is in defining who makes the call. Non designers making design decisions will always be a trouble spot. I am accustom to hearing that same sort of attitude, but not from designers. I have been very fortunate to work with humble and evidence driven designers in my career. My experience with ego driven prima donna designers is very limited. The key to avoiding this situation is to lay a foundation of mutual respect for the various areas of expertise on the team, listening closely to what your experts advise... and if you make a decision counter to that recommendation, explain your reasoning.

Mark

On Dec 6, 2009, at 1:10 PM, Ron Jeffries wrote:

One vibe I sometimes get here is "I am the designer and you mere
humans should just take what I say as true." My points are two:

#6662

From: "Mike Dwyer" <mdwyer@...>
Date: Sun Dec 6, 2009 9:16 pm
Subject: Re: Agile vs. Creativity

protraveler1

Jared
Your comments are applicable to many of the conversations on other groups.
The identification of struggling teams could also apply to struggling groups where the appearance of non collaborative, knee jerk response / rejection of honest respectful discussion is becoming the norm. We all suffer from it.

Sent via BlackBerry by AT&T

From: Jared Spool <jspool@...>

Date: Sun, 6 Dec 2009 11:30:28 -0800

To: <agile-usability@yahoogroups.com>; Ron Jeffries<ronjeffries@...>

Subject: Re: [agile-usability] Agile vs. Creativity

On Dec 6, 2009, at 11:10 AM, Ron Jeffries wrote:

0 < p < 1

One vibe I sometimes get here is "I am the designer and you mere
humans should just take what I say as true." My points are two:

1. Even if what such a person says is true, it will require
discussion in order to get people to accept it as true;

2. That discussion needs to be sincerely respectful, especially when
being held with the person paying for the project.

So one best practice (for lack of better term, though I despise the notion of 'best practices') we've found amongst the best teams: They resist making recommendations for changes in the design.

Think of this progression:

Observation - You see something that strikes you as important. Maybe it's a user behavior. Maybe it's a report from a customer. Maybe it's something a competitor has done.

Opinion - You form a reason as to why this should be addressed. If the user doesn't know what the button means, you must think about alternative button labels and, perhaps, some explanatory text.

Recommendation - You describe to the team what the change should be. If you need to change the button label, you propose a new label and prompt.

Decision - The team decides the change is worth making.

So, I agree with you 100%. The vibe you describe is far more common in the struggling teams than in the best teams.

Jared

Jared M. Spool

User Interface Engineering

510 Turnpike St., Suite 102, North Andover, MA 01845

e: jspool@... p: +1 978 327 5561

http://uie.com Blog: http://uie.com/brainsparks Twitter: @jmspool

#6663

From: chris@...
Date: Sun Dec 6, 2009 9:53 pm
Subject: Re: Agile vs. Creativity

cpehura

Personally I've found that having honest discussions can be very painful to endure. Feelings will be hurt. If they're not, either it's really not an honest discussion or you are talking to the wrong people. Once the dust settles, people are much more civil to eachother.

Sent via BlackBerry from T-Mobile

From: "Mike Dwyer" <mdwyer@...>

Date: Sun, 6 Dec 2009 21:16:33 +0000

To: <agile-usability@yahoogroups.com>

Subject: Re: [agile-usability] Agile vs. Creativity

Sent via BlackBerry by AT&T

From: Jared Spool <jspool@...>

Date: Sun, 6 Dec 2009 11:30:28 -0800

To: <agile-usability@yahoogroups.com>; Ron Jeffries<ronjeffries@acm.org>

Subject: Re: [agile-usability] Agile vs. Creativity

On Dec 6, 2009, at 11:10 AM, Ron Jeffries wrote:

0 < p < 1

One vibe I sometimes get here is "I am the designer and you mere
humans should just take what I say as true." My points are two:

1. Even if what such a person says is true, it will require
discussion in order to get people to accept it as true;

2. That discussion needs to be sincerely respectful, especially when
being held with the person paying for the project.

So one best practice (for lack of better term, though I despise the notion of 'best practices') we've found amongst the best teams: They resist making recommendations for changes in the design.

Think of this progression:

Observation - You see something that strikes you as important. Maybe it's a user behavior. Maybe it's a report from a customer. Maybe it's something a competitor has done.

Opinion - You form a reason as to why this should be addressed. If the user doesn't know what the button means, you must think about alternative button labels and, perhaps, some explanatory text.

Recommendation - You describe to the team what the change should be. If you nee d to change the button label, you propose a new label and prompt.

Decision - The team decides the change is worth making.

So, I agree with you 100%. The vibe you describe is far more common in the struggling teams than in the best teams.

Jared

Jared M. Spool

User Interface Engineering

510 Turnpike St., Suite 102, North Andover, MA 01845

e: jspool@... p: +1 978 327 5561

http://uie.com Blog: http://uie.com/brainsparks Twitter: @jmspool

#6664

From: Ron Jeffries <ronjeffries@...>
Date: Sun Dec 6, 2009 10:48 pm
Subject: Re: Agile vs. Creativity

ronaldejeffries

Hello, Chris.  On Sunday, December 6, 2009, at 4:53:20 PM, you
wrote:

> Personally I've found that having honest discussions can be very
> painful to endure. Feelings will be hurt. If they're not, either
> it's really not an honest discussion or you are talking to the
> wrong people. Once the dust settles, people are much more civil to eachother.

Really? Why do you find it necessary to hurt people's feelings so
often? Or why do yours get hurt so often?

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Hold on to your dream.  --ELO

#6665

From: Jared Spool <jspool@...>
Date: Sun Dec 6, 2009 11:24 pm
Subject: Re: Agile vs. Creativity

jmspool

On Dec 6, 2009, at 1:53 PM, chris@... wrote:

Personally I've found that having honest discussions can be very painful to endure. Feelings will be hurt. If they're not, either it's really not an honest discussion or you are talking to the wrong people. Once the dust settles, people are much more civil to eachother.

Ron is right. This does suggest that something else is wrong.

From what I've observed, an 'honest discussion' is one where everyone's agenda is on the table and, hopefully, any conflicts or discontinuities in those agendas are openly discussed, respected, and reconciled.

Honest discussion does not require hurting feelings, unless there's a deeper interpersonal issue, in my experience.

Jared

#6666

From: chris@...
Date: Sun Dec 6, 2009 11:48 pm
Subject: Re: Agile vs. Creativity

cpehura

Not what I meant. Honesty, real honesty means uncovering things that people
prefer not uncovering. "if every politician was honest, the whole political
system would break down". Myself, you can criticize me about what I say and what
I think, it doesn't bother me. If you start poking me, calling me names, or
start crowding me, then I will get a little frustrated.

I don't go out offending people either. I determine their context and discuss
things in terms of that context and very careful not to annoy or waste time.

The problem is that most people that become brutally honest and emotionally
driven take out their  emotional baggage out in view as well. They start
venting. They pretend that you are the person that wronged them, and treat you
as such. You may call it creating discomfort or hurt feelings, but these things
happen. I see this happen so often that I meet people one on one first so I can
diffuse this emotional baggage so they don't take it with them into the group
dynamics.

When dealing with raw honesty, there has to be some form of discomfort before
the comfort comes. All you can do is make the discomfort more comfortable.

Sent via BlackBerry from T-Mobile

-----Original Message-----
From: Ron Jeffries <ronjeffries@...>
Date: Sun, 6 Dec 2009 17:48:07
To: <agile-usability@yahoogroups.com>
Subject: Re: [agile-usability] Agile vs. Creativity

Hello, Chris.  On Sunday, December 6, 2009, at 4:53:20 PM, you
wrote:

> Personally I've found that having honest discussions can be very
> painful to endure. Feelings will be hurt. If they're not, either
> it's really not an honest discussion or you are talking to the
> wrong people. Once the dust settles, people are much more civil to eachother.

Really? Why do you find it necessary to hurt people's feelings so
often? Or why do yours get hurt so often?

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Hold on to your dream.  --ELO

------------------------------------

Yahoo! Groups Links

#6667

From: Scott Preece <sepreece@...>
Date: Mon Dec 7, 2009 2:06 am
Subject: Re: Agile vs. Creativity

sepreece

Hmm...

- I'm not sure what you mean by "There are no people with no clue." Are you
suggesting all opinions on technical questions should have equal weight?

- "Going off on one's own" is also ambiguous. People should be given time to do
a reasonable increment of work before getting feedback. The definition of
"reasonable increment" may vary with the kind of work - if the scope of the
specific task is more holistic, an increment may have to be broader before you
can do a meaningful review.

- On the same note, work in different domains is (or may be) different. Agile
offers some evidence that software development profits from pair programming,
for instance, but I don't know that there's any evidence that pair (or team)
design works as well as individual design. It may be that it does, but I don't
think there's any reason to assume that.

- Conversations are probably critical regardless of domain, but it may be that
the conversations should happen further apart, just because it may take more
time to apply the results of the conversations if the work has to address a
broader scope in each increment.

regards,
scott



----- Original Message ----
> From: Ron Jeffries <ronjeffries@...>
> To: agile-usability@yahoogroups.com
> Sent: Sun, December 6, 2009 11:26:06 AM
> Subject: Re: [agile-usability] Agile vs. Creativity
>
> Hello, Mike.  On Sunday, December 6, 2009, at 11:31:34 AM, you
> wrote:
>
> > At the same time people with no clue, who insist thinking their
> > opinion has equal weight as a professional, can elicit the same
> > response from most sainted practitioner.
>
> There are no people with no clue. And the person with the money,
> however p-clued, needs to be treated with respect.
>
> Ron Jeffries
> www.XProgramming.com
> www.xprogramming.com/blog
> Those who attain to any excellence commonly spend life in some single
> pursuit, for excellence is not often gained upon easier terms.
>    -- Samuel Johnson
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

#6668

From: Margaret Motamed <motamed@...>
Date: Mon Dec 7, 2009 3:06 pm
Subject: RE: Agile vs. Creativity

speechmom2001

Jared, Thank you for this – great reminder and helpful to me for some current scrum team work …

“When you're skill based, it's possible that multiple people on the team can handle a particular challenge. When you're role based, you get into ownership issues and turf wars.”

Margaret

fledgling blog‑

www.agiledreamer.com

Confidentiality notice: This message may contain confidential information. It is intended only for the person to whom it is addressed. If you are not that person, you should not use this message. We request that you notify us by replying to this message, and then delete all copies including any contained in your reply. Thank you.

#6669

From: James Page <jamespage@...>
Date: Mon Dec 7, 2009 5:26 pm
Subject: Re: Agile vs. Creativity

jamespagetemp

I think Paul Cairn of the University of York in the UK explains the issue....in his The Ghosts of Departed Qualities, The practice of developing an HCI module

The problem with HCI is that it is a design discipline not a science. So making statements that have some universal, non-contingent, falsiﬁable nature is challenging.

and he goes on to say

UCD cannot guarantee improved designs, nor can it even be said when UCD

would work well and when it wouldn’t. In that sense, UCD is something of an act of faith. The fundamental tenet of the faith is that lack of consideration of users is likely to cause problems.

If we move to agile, with its focus on the Customer, and all the team members, I wonder if it's tenet of faith can be boiled down to :-

that lack of consideration of all the stakeholders is likely to cause problems.

If the above is true, is it possible to be both considerate to the team, and at the same time considerate to the user?

I think the answer is yes. But the real question is how?

All the best

James

2009/12/6 Jared Spool <jspool@...>

On Dec 5, 2009, at 4:22 PM, mark schraad wrote:

At a base level, in order to get away from prescriptive prd's I like to move product manager towards providing the problem statement

Ah, yes. Don't tell me you need a bridge. Tell me what the valley looks like.

I think part of this problem comes from focusing on roles instead of skills. We've found, in our research that the best teams think in terms of skills and less about job titles and roles.

When you're skill based, it's possible that multiple people on the team can handle a particular challenge. When you're role based, you get into ownership issues and turf wars.

If you talk about design (or design decisions, as Jeff put it) from a skill-based perspective, then everyone on the team is doing it in some form or other.

Jared

#6670

From: Robert Gravina <robert@...>
Date: Mon Dec 7, 2009 4:44 pm
Subject: UX books for programmers

rgravina

Hello list,

We've all probably worked on (or at least been users of) your typical
database-driven web-application which basically exposes the database
tables underneath as a series of index/create/show/update/delete pages
without much thought into what the users are trying to use the system
for. They usually "work", but there is so much missed potential, users
don't really like it, and the programmer thinks there's absolutely
nothing wrong with it :) I kid! I am a programmer and like to think
that I can see that this scenario is far from perfect, and I've been
guilty of making applications like this myself too. It usually happens
because this type of interface is the simplest to create and there
wasn't any effort put into design. I'm not going to perpretrate the
myth that the programmer was so blind as to think users would love
this interface!

Let's say you're a programmer maintaining an application like this.
What can you do to transform the experience into something more
user-focused, an application which serves the *user* and not the
database? Sure, time should have been invested in understanding the
users earlier on but what can be done about it now? Which leads me to
the question I really wanted to ask....

Does anyone have any books/resources they can recommend for a)
learning the basics of UX in the context of web applications and b)
learning techniques for refactoring not-so-good UIs into something
better?

Robert

#6671

From: Jeremy Kriegel <jer@...>
Date: Mon Dec 7, 2009 6:45 pm
Subject: Re: UX books for programmers

sonojerarc

http://www.amazon.com/Inmates-Are-Running-Asylum/dp/0672316498

I liked the way the first half of The Inmates are Running the Asylum humorously sets up how to approach this problem.

-jer

"Be well, do good work & keep in touch."
� � - Garrison Keillor

On Mon, Dec 7, 2009 at 11:44 AM, Robert Gravina <robert@...> wrote:

�

Hello list,

We've all probably worked on (or at least been users of) your typical
database-driven web-application which basically exposes the database
tables underneath as a series of index/create/show/update/delete pages
without much thought into what the users are trying to use the system
for. They usually "work", but there is so much missed potential, users
don't really like it, and the programmer thinks there's absolutely
nothing wrong with it :) I kid! I am a programmer and like to think
that I can see that this scenario is far from perfect, and I've been
guilty of making applications like this myself too. It usually happens
because this type of interface is the simplest to create and there
wasn't any effort put into design. I'm not going to perpretrate the
myth that the programmer was so blind as to think users would love
this interface!

Let's say you're a programmer maintaining an application like this.
What can you do to transform the experience into something more
user-focused, an application which serves the *user* and not the
database? Sure, time should have been invested in understanding the
users earlier on but what can be done about it now? Which leads me to
the question I really wanted to ask....

Does anyone have any books/resources they can recommend for a)
learning the basics of UX in the context of web applications and b)
learning techniques for refactoring not-so-good UIs into something
better?

Robert

#6672

From: Tim Wright <sambo.shacklock@...>
Date: Mon Dec 7, 2009 7:09 pm
Subject: Re: UX books for programmers

crazy_timnz

Designing Interfaces by Tidwell might be a starter - it presents user interface patterns that you might be able to refactor around. http://designinginterfaces.com/

However, that won't help with the greater problem - an understanding of what your users are trying to achieve. Without that your re-factoring won't necessarily take you toward a better interface.

There are a couple of approaches to this. I prefer Constantine & Lockwood's approach - it's based in use case models and use cases to define the interaction necessary for a user to achieve a goal. The models used are quite abstract and, therefore, harder to explain. However, the power you get from the abstraction is quite extraordinary (and once you "get it" they're easy and fast to use too).

The more well known methodology is Cooper's Personas and Scenarios. It has the advantage that the models are quite concrete and easy to understand and use. This is discussed in the book Jeremy recommended below (which is an awesome book).

Neilson's "usability engineering" is still a classic - it's based around understanding the changes you need to make by performing usability tests. Then you can prioritize the changes with the greatest benefit to your users.

Finally, there's always Norman's "design of everyday things". This will give you a great understanding of the problem in user interface design and an appreciation of how often we get it wrong.

Tim

On Tue, Dec 8, 2009 at 7:45 AM, Jeremy Kriegel <jer@...> wrote:

I liked the way the first half of The Inmates are Running the Asylum humorously sets up how to approach this problem.

http://www.amazon.com/Inmates-Are-Running-Asylum/dp/0672316498

-jer

"Be well, do good work & keep in touch."
- Garrison Keillor

On Mon, Dec 7, 2009 at 11:44 AM, Robert Gravina <robert@...> wrote:

Hello list,

We've all probably worked on (or at least been users of) your typical
database-driven web-application which basically exposes the database
tables underneath as a series of index/create/show/update/delete pages
without much thought into what the users are trying to use the system
for. They usually "work", but there is so much missed potential, users
don't really like it, and the programmer thinks there's absolutely
nothing wrong with it :) I kid! I am a programmer and like to think
that I can see that this scenario is far from perfect, and I've been
guilty of making applications like this myself too. It usually happens
because this type of interface is the simplest to create and there
wasn't any effort put into design. I'm not going to perpretrate the
myth that the programmer was so blind as to think users would love
this interface!

Let's say you're a programmer maintaining an application like this.
What can you do to transform the experience into something more
user-focused, an application which serves the *user* and not the
database? Sure, time should have been invested in understanding the
users earlier on but what can be done about it now? Which leads me to
the question I really wanted to ask....

Does anyone have any books/resources they can recommend for a)
learning the basics of UX in the context of web applications and b)
learning techniques for refactoring not-so-good UIs into something
better?

Robert

#6673

From: "Jeanne Hallock" <jeanneh@...>
Date: Mon Dec 7, 2009 8:05 pm
Subject: Re: UX books for programmers

SarahR4888

http://www.joelonsoftware.com/printerFriendly/uibook/fog0000000249.html

Joel on Software is an extremely good (web) read for developers to get an understanding of UI:

On his home page, he has numerous blog articles under 'Software Designer' in the center green-ish column, which are more updated than the previous link. http://www.joelonsoftware.com/

#6674

From: "Peter Boersma" <peter@...>
Date: Mon Dec 7, 2009 8:59 pm
Subject: RE: UX books for programmers

pboersma12

Robert asked:
> Does anyone have any books/resources they can recommend for a)
> learning the basics of UX in the context of web applications and b)
> learning techniques for refactoring not-so-good UIs into something
> better?

for a) I'd currently recommend "Communicating Design - Developing Web Site
Documentation for Design and Planning" by Dan Brown
(http://www.communicatingdesign.com/). You can learn a lot from books like this.

but b) takes practice; I'd try and arrange a workshop where you (have
someone(*)) show the steps one could take to design a good/better interface
(user research, design, evaluate), practice it, critique it (honest feedback,
good and bad points) and have people collectively write down the lessons learned
(on a Wiki or something).

(*) For a Dutch professional training institute, I teach a 4-day course called
"Interaction Design" where I use the umbrella of User Centered Design to teach
user research, aspects of design (concepts, structure, interaction, layout,
content, visual), and many ways to evaluate a design. I recently did a shorter
version in English for Spanish Design Management students. See if you can find
someone to do it for you in 4 hours :-) (that will take me some more
practicing!)

Peter
--
Peter Boersma | Senior Interaction Designer | Info.nl
http://www.peterboersma.com/blog | http://www.info.nl

#6675

From: Carey Caulfield <carey.caulfield@...>
Date: Mon Dec 7, 2009 9:09 pm
Subject: Interaction Design Job Descriptions/Career Ladder Examples

careycaulfield

Hello!

We are in the process of updating our old job descriptions from when we were waterfall to now how we operate in Agile (Scrum).

Wondering if anyone else has had to rewrite job descriptions due to a change in process and to reflect what designers are actually now doing? Can anyone point me to or share with me any examples of interaction designer job descriptions within Agile? Any comparison from one level to another would be quite helpful as well (ie, spreadsheet comparing Associate, to Mid, to Senior and so on.)

Our career ladder is Associate, Mid, Senior, Staff and Principal UX Designer.

Kindest regards,

Carey

Reply | Messages in this Topic (1)

#6676

From: Austin Govella <austin.govella@...>
Date: Mon Dec 7, 2009 9:51 pm
Subject: Re: UX books for programmers

agovella

Robert Gravina wrote:
> Does anyone have any books/resources they can recommend for a)
> learning the basics of UX in the context of web applications and b)
> learning techniques for refactoring not-so-good UIs into something
> better?

Being lazy and not reading the rest of the responses. Apologies for
duplicates.

Krug's 'Don't Make Me Think' is the perennial favorite, and I don't
think anyone will ever write anything better. Best introduction to UX
for anyone. Half pictures and half words, plus cartoons and winning style.

Christina Wodtke and I wrote the 2nd edition of 'Information
Architecture: Blueprints for the Web' as an intro to UX for non-UX
people. We do not explicitly focus on database apps, though all of our
experience and the majority of our examples reference such. Half
pictures and half words.

Robert Hoekman's 'Designing the Obvious' takes a lot of common apps with
   database interfaces and de-engineers them and up-UXes them. Pretty
useful to see it in action. Mostly words.

--
Austin Govella

#6677

From: "joko_1.rm" <joko_1@...>
Date: Fri Dec 4, 2009 3:13 pm
Subject: Agile UX SIG London follow-up

joko_1.rm

Hi all,

On Nov 24, the Agile UX Special Interest Group London kicked off at the
Winewharf in Borough. The group consisted of mainly UX practitioners, but we
also had an agile coach and scrum masters/developers amongst us. A good mix of
backgrounds and levels of experience.

We discussed expert issues and shared experiences, but there was also a need for
an introduction to agile for UX people. The question how to introduce UX to an
agile project came up, too.

Going forward, the group suggested to combine knowledge sharing (~ a 45 min
session at the beginning) and socialising (the rest of the evening).

On the wishlist:
- workshops that introduce new techniques and ideas
- themes of the evening, eg the backlog
- experience reports: talk about your current project and get advice from the
group
- discuss recent articles or blogpost (ux bookclub style)

Additionally to the meet-ups, we discussed the idea of a one-day mini
conference, or an agile retreat (following the one in the States).

I'd like to open up the discussion on the Agile Experience Ning
(http://www.agileexperiencedesign.org/forum/topics/agile-ux-sig-london). Any
ideas and feedback more than welcome :)
The next meetup is penciled in for early Feb.

Cheers,
Johanna

Reply | Messages in this Topic (1)

#6678

From: Robert Gravina <robert@...>
Date: Mon Dec 7, 2009 6:58 pm
Subject: Re: UX books for programmers

rgravina

2009/12/7 Jeremy Kriegel <jer@...>
> I liked the way the first half of The Inmates are Running the Asylum
humorously sets up how to approach this problem.

Thanks. I think I need a laugh right about now :). Has anyone read
Coopers other book (About Face 3) - I've heard it's a bit of an
interaction design classic, and the UX people I've worked with in the
path seemed to be doing something like the Cooper method. Although the
book says it's relevant for "web 2.0 sites", it does seem to have a
GUI focus (based on the table of contents, Part III seems to be very
GUI focussed as it covers menus, toolbars, etc.).

Can anyone comment? Is it still worth a read?

Robert

#6679

From: Fl�vio Steffens de Castro <flavio.steffens@...>
Date: Thu Dec 3, 2009 2:11 pm
Subject: Creativity and agile

flaviogrupos

Hello people,

I just posted in my blog (www.agileway.com.br) a video about the IDEO creative process. The video is from ABC and was recorded in 1999. You can note that most of the process and culture is "agile based" - even that I didn't think that they knew about agile that time hehe

It's very good to take a look in the video and think about what lessions we can learn from their process.

Oh, tomorrow I will post another video from the IDEO CEO in TED 2008 speaking about creativity again. You can visit my blog to see or just found it in TED website.

Hope you like it :)

(don't bother about the subtitles or the portuguese texts. The videos are in english)

See ya!
_____________________
Flavio Steffens de Castro
http://www.agileway.com.br
A filosofia agile no dia-a-dia

MSN: flavio.steffens@...
Twitter: @flaviosteffens

#6680

From: Tim Wright <sambo.shacklock@...>
Date: Tue Dec 8, 2009 9:01 am
Subject: Re: UX books for programmers

crazy_timnz

That really depends on how you define "web 2.0" :)

In any case, the problem you'll need to look at is "what are your users trying to achieve". About Face can help with that. How you turn that information into a solution is a different problem - and the book gives hints for a conventional WIMP interface (windows, icons, menus, pointers). The ideas are probably equally relevant for websites (note tho: I've got About Face 2 - not About Face 3 - beside me).

Tim

On Tue, Dec 8, 2009 at 7:58 AM, Robert Gravina <robert@...> wrote:

2009/12/7 Jeremy Kriegel <jer@...>

> I liked the way the first half of The Inmates are Running the Asylum humorously sets up how to approach this problem.

Thanks. I think I need a laugh right about now :). Has anyone read
Coopers other book (About Face 3) - I've heard it's a bit of an
interaction design classic, and the UX people I've worked with in the
path seemed to be doing something like the Cooper method. Although the
book says it's relevant for "web 2.0 sites", it does seem to have a
GUI focus (based on the table of contents, Part III seems to be very
GUI focussed as it covers menus, toolbars, etc.).

Can anyone comment? Is it still worth a read?

Robert

#6681

From: Robert Gravina <robert@...>
Date: Tue Dec 8, 2009 10:24 am
Subject: Re: UX books for programmers

rgravina

Thanks all for the great responses!... of all those mentioned, two stand out for me as being particularly useful - About Face 3 for it's coverage of goal-centred design and Designing Interfaces for it's practical, pattern language approach to solving common interface problems.

Neither of these are particularly web-focused, but I can see that the concepts are general enough that they could apply to web applications, too. It would be nice to find a really good web-focussed one though.

Robert

#6682

From: Anders Ramsay <andersr@...>
Date: Tue Dec 8, 2009 12:29 pm
Subject: Re: Creativity and agile

andersramsay

IDEO certainly has an *iterative* practice, but Agile?� Their iterations, as far as I know, do not include creation of the actual product. The product they produce is something that is handed off to the people who actually build the product, often a highly detailed specification document.� In other words, iterative design by itself does not an Agile practice make.� For that to be the case, the design work needs to be integrated with the engineering or manufacturing of the product a la TPS.

2009/12/3 Fl�vio Steffens de Castro <flavio.steffens@...>

�

Hello people,

I just posted in my blog (www.agileway.com.br) a video about the IDEO creative process. The video is from ABC and was recorded in 1999. You can note that most of the process and culture is "agile based" - even that I didn't think that they knew about agile that time hehe

It's very good to take a look in the video and think about what lessions we can learn from their process.

Oh, tomorrow I will post another video from the IDEO CEO in TED 2008 speaking about creativity again. You can visit my blog to see or just found it in TED website.

Hope you like it :)

(don't bother about the subtitles or the portuguese texts. The videos are in english)

See ya!
_____________________
Flavio Steffens de Castro
http://www.agileway.com.br
A filosofia agile no dia-a-dia

MSN: flavio.steffens@...
Twitter: @flaviosteffens

#6683

From: "hughrbeyer" <beyer@...>
Date: Tue Dec 8, 2009 5:14 pm
Subject: Re: Agile vs. Creativity

hughrbeyer

--- In agile-usability@yahoogroups.com, mark schraad <mschraad@...> wrote:
>
> What Chris is describing is not a partnership at all. It is one person
> treating the other as their wrist. This might be something a business
> owner or product manager might be willing to do (because they
> typically know everything) but not something even a descent art
> director would do to a designer. It pure and simple micro management
> and throwing any qualifications the individual might have right out
> the window.
>
> And by the way... there is no such thing as graphics design... it is
> called graphic design.

Mmmm, no, what Chris was describing is called collaboration. He did leave out
the part where the graphics designer talks back--e.g. "That yellow won't look
good on all screens," "If we move it down it won't be lined up with that other
box, suppose we give it a background shading to make it stand out instead."

At best, both collaborators end up happy and the non-graphics person learns a
little bit about what to look for, both of value to an Agile team.

Oh, and "graphic design" is the discipline. When I say "graphics design", I'm
distinguishing the activity of deciding what pixels to show--the graphics--from
all the rest of UI design. It's often a useful distinction to make.

Hugh

#6684

From: "hughrbeyer" <beyer@...>
Date: Tue Dec 8, 2009 5:30 pm
Subject: Re: Agile vs. Creativity

hughrbeyer

--- In agile-usability@yahoogroups.com, Jared Spool <jspool@...> wrote:

> All this discussion brought this cartoon to mind:
>
> http://theoatmeal.com/comics/design_hell

Jeez, Jared, that's appalling. Funny, but appalling. Any designer who can't
handle a client saying "pop" and "edgy" shouldn't be in the business.

Our lead UI designer has a process for dealing with this kind of thing... he
*starts* by asking for a list of words that should characterize the site. And if
there are any he doesn't understand, he runs a little conversation about what
that word means and why it matters.

Which just means that you not only have to talk to your customers and
stakeholders, you have to know how to talk to them. And the techniques that work
for talking to end-users are not the same as the ones you need for talking to
other stakeholders.

Hugh

#6685

From: Ron Jeffries <ronjeffries@...>
Date: Tue Dec 8, 2009 6:02 pm
Subject: Re: Re: Agile vs. Creativity

ronaldejeffries

Hello, Hugh.

+1 with a bullet.

On Tuesday, December 8, 2009, at 12:30:16 PM,
you wrote:

> Jeez, Jared, that's appalling. Funny, but appalling. Any designer
> who can't handle a client saying "pop" and "edgy" shouldn't be in the
business.

> Our lead UI designer has a process for dealing with this kind of
> thing... he *starts* by asking for a list of words that should
> characterize the site. And if there are any he doesn't understand,
> he runs a little conversation about what that word means and why it matters.

> Which just means that you not only have to talk to your customers
> and stakeholders, you have to know how to talk to them. And the
> techniques that work for talking to end-users are not the same as
> the ones you need for talking to other stakeholders.



Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
It's easy to have a complicated idea.
It's very very hard to have a simple idea.
   -- Carver Mead

#6686

From: glen.alleman@...
Date: Tue Dec 8, 2009 6:11 pm
Subject: Re: Creativity and agile

gballeman2000

Andres,

You need to be careful here. Integrated with manufacturing has varying definitions. At Toyota the Camry production line is NOT a test bed for new releases of the Camry.

--- On Tue, 12/8/09, Anders Ramsay <andersr@...> wrote:

From: Anders Ramsay <andersr@...>
Subject: Re: [agile-usability] Creativity and agile
To: "agile-usability" <agile-usability@yahoogroups.com>
Date: Tuesday, December 8, 2009, 5:29 AM

IDEO certainly has an *iterative* practice, but Agile? Their iterations, as far as I know, do not include creation of the actual product. The product they produce is something that is handed off to the people who actually build the product, often a highly detailed specification document. In other words, iterative design by itself does not an Agile practice make. For that to be the case, the design work needs to be integrated with the engineering or manufacturing of the product a la TPS.

2009/12/3 Fl�vio Steffens de Castro <flavio.steffens@...>

Hello people,

I just posted in my blog (www.agileway.com.br) a video about the IDEO creative process. The video is from ABC and was recorded in 1999. You can note that most of the process and culture is "agile based" - even that I didn't think that they knew about agile that time hehe

It's very good to take a look in the video and think about what lessions we can learn from their process.

Oh, tomorrow I will post another video from the IDEO CEO in TED 2008 speaking about creativity again. You can visit my blog to see or just found it in TED website.

Hope you like it :)

(don't bother about the subtitles or the portuguese texts. The videos are in english)

See ya!
_____________________
Flavio Steffens de Castro
http://www.agileway.com.br
A filosofia agile no dia-a-dia

MSN: flavio.steffens@...
Twitter: @flaviosteffens

#6687

From: Jared Spool <jspool@...>
Date: Tue Dec 8, 2009 6:23 pm
Subject: Re: Re: Agile vs. Creativity

jmspool

On Dec 8, 2009, at 9:30 AM, hughrbeyer wrote:

> All this discussion brought this cartoon to mind:
>
> http://theoatmeal.com/comics/design_hell

Jeez, Jared, that's appalling. Funny, but appalling.

Yes. I never promised otherwise.

Jared

#6688

From: Fl�vio Steffens de Castro <flavio.steffens@...>
Date: Tue Dec 8, 2009 4:05 pm
Subject: Re: Creativity and agile

flaviogrupos

Hi Anders,

it's good to remember that the video is from 1999... two years before the Agile Manifesto. It's even before the "Google Philosophy".

Obviously that they aren't doing agile. But things like empirism, iterations, chaos and colaboration are strong as we can see. Also, prototypes, feedbacks from clients, envolvement from clients, fun, small teams and, why not, a big taskboard (visible to everyone).

I think that we see a lot of agile stuff in the video. Maybe not *THE* agile. But certainly a lot of :)

Regards
_____________________
Flavio Steffens de Castro
http://www.agileway.com.br
A filosofia agile no dia-a-dia

MSN: flavio.steffens@...
Twitter: @flaviosteffens

On Tue, Dec 8, 2009 at 10:29 AM, Anders Ramsay <andersr@...> wrote:

�

IDEO certainly has an *iterative* practice, but Agile?� Their iterations, as far as I know, do not include creation of the actual product. The product they produce is something that is handed off to the people who actually build the product, often a highly detailed specification document.� In other words, iterative design by itself does not an Agile practice make.� For that to be the case, the design work needs to be integrated with the engineering or manufacturing of the product a la TPS.

2009/12/3 Fl�vio Steffens de Castro <flavio.steffens@...>

�

Hello people,

I just posted in my blog (www.agileway.com.br) a video about the IDEO creative process. The video is from ABC and was recorded in 1999. You can note that most of the process and culture is "agile based" - even that I didn't think that they knew about agile that time hehe

It's very good to take a look in the video and think about what lessions we can learn from their process.

Oh, tomorrow I will post another video from the IDEO CEO in TED 2008 speaking about creativity again. You can visit my blog to see or just found it in TED website.

Hope you like it :)

(don't bother about the subtitles or the portuguese texts. The videos are in english)

See ya!
_____________________
Flavio Steffens de Castro
http://www.agileway.com.br
A filosofia agile no dia-a-dia

MSN: flavio.steffens@...
Twitter: @flaviosteffens

#6689

From: Anders Ramsay <andersr@...>
Date: Tue Dec 8, 2009 7:18 pm
Subject: Re: Creativity and agile

andersramsay

Hi Glen,

Was referring to the people who are responsible for design and the people who are responsible for manufacturing, not the physical production line.� But we digress (I think) - the key point is that I keep talking to designers who see what they do as Agile simply because they are iterating on their design concepts.� While that is all good and well, it is still work that is done separate and away from that of those who build the product. Unless their work is integrated, unless they are actually working together, the practice does not take full advantage of what makes Agile powerful. -Anders

On Tue, Dec 8, 2009 at 1:11 PM, <glen.alleman@...> wrote:

�

Andres,
You need to be careful here. Integrated with manufacturing has varying�definitions. At Toyota the Camry production line is NOT a test bed for new releases of the Camry.�

--- On Tue, 12/8/09, Anders Ramsay <andersr@...> wrote:

From: Anders Ramsay <andersr@...>
Subject: Re: [agile-usability] Creativity and agile
To: "agile-usability" <agile-usability@yahoogroups.com>
Date: Tuesday, December 8, 2009, 5:29 AM

IDEO certainly has an *iterative* practice, but Agile?� Their iterations, as far as I know, do not include creation of the actual product. The product they produce is something that is handed off to the people who actually build the product, often a highly detailed specification document.� In other words, iterative design by itself does not an Agile practice make.� For that to be the case, the design work needs to be integrated with the engineering or manufacturing of the product a la TPS.

2009/12/3 Fl�vio Steffens de Castro <flavio.steffens@...>

�

Hello people,

I just posted in my blog (www.agileway.com.br) a video about the IDEO creative process. The video is from ABC and was recorded in 1999. You can note that most of the process and culture is "agile based" - even that I didn't think that they knew about agile that time hehe

It's very good to take a look in the video and think about what lessions we can learn from their process.

Oh, tomorrow I will post another video from the IDEO CEO in TED 2008 speaking about creativity again. You can visit my blog to see or just found it in TED website.

Hope you like it :)

(don't bother about the subtitles or the portuguese texts. The videos are in english)

See ya!
_____________________
Flavio Steffens de Castro
http://www.agileway.com.br
A filosofia agile no dia-a-dia

MSN: flavio.steffens@...
Twitter: @flaviosteffens