Nabble - Agile Usability

Re: Re: Agile in digital agencies

2009-11-24T11:04:19Z

Hello Kevin!

How was your experience? Did you delivered full sections (wireframes,
layouts, front-end and back-end) each iteration?

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

On Tue, Nov 24, 2009 at 6:58 AM, Kevin Rapley <kevin.rapley@...
> wrote:

>
>
> Hi Flavio,
> Yes, we are using SCRUM and Agile for creating websites and
> applications. I am yet to experience an Agile run project myself but
> will be brought on to a project very soon. This is why I have joined
> the Agile Usability Group to learn from others and share experiences
> too. I will be watching this thread closely and will divulge any
> insights as and when the time occurs.
>
> Regards
>
> --
> Kevin Rapley - User Experience Designer
> TechnoPhobia Limited
> The Workstation
> 15 Paternoster Row
> SHEFFIELD
> England
> S1 2BX
> t: +44 (0)114 2212123
> f: +44 (0)114 2212124
> e: Kevin.rapley@... <Kevin.rapley%40technophobia.com>
> w: http://www.technophobia.com
>
> Registered in England and Wales Company No. 3063669
> VAT registration No. 598 7858 42
> ISO 9001:2000 Accredited Company No. 21227
> ISO 14001:2004 Accredited Company No. E997
> ISO 27001:2005 (BS7799) Accredited Company No. IS 508906
> Investor in People Certified No. 101507
>
> The contents of this email are confidential to the addressee
> and are intended solely for the recipients use. If you are not
> the addressee, you have received this email in error.
> Any disclosure, copying, distribution or action taken in
> reliance on it is prohibited and may be unlawful.
>
> Any opinions expressed in this email are those of the author
> personally and not TechnoPhobia Limited who do not accept
> responsibility for the contents of the message.
>
> All email communications, in and out of TechnoPhobia,
> are recorded for monitoring purposes.
>
>
>

Re: Agile in digital agencies

2009-11-24T00:58:38Z

Hi Flavio,
Yes, we are using SCRUM and Agile for creating websites and
applications. I am yet to experience an Agile run project myself but
will be brought on to a project very soon. This is why I have joined
the Agile Usability Group to learn from others and share experiences
too. I will be watching this thread closely and will divulge any
insights as and when the time occurs.

Regards

--
Kevin Rapley - User Experience Designer
TechnoPhobia Limited
The Workstation
15 Paternoster Row
SHEFFIELD
England
S1 2BX
t: +44 (0)114 2212123
f: +44 (0)114 2212124
e: Kevin.rapley@...
w: http://www.technophobia.com

Registered in England and Wales Company No. 3063669
VAT registration No. 598 7858 42
ISO 9001:2000 Accredited Company No. 21227
ISO 14001:2004 Accredited Company No. E997
ISO 27001:2005 (BS7799) Accredited Company No. IS 508906
Investor in People Certified No. 101507

The contents of this email are confidential to the addressee
and are intended solely for the recipients use. If you are not
the addressee, you have received this email in error.
Any disclosure, copying, distribution or action taken in
reliance on it is prohibited and may be unlawful.

Any opinions expressed in this email are those of the author
personally and not TechnoPhobia Limited who do not accept
responsibility for the contents of the message.

All email communications, in and out of TechnoPhobia,
are recorded for monitoring purposes.

Agile in digital agencies

2009-11-23T14:15:55Z

Hello people,

is there anyone here that already use scrum/xp/lean/agile in digital
agencies? Like creating websites, online marketing, etc.

I will like to share experiences. :)

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

Design Values: Validated Data over Expert Opinion

2009-11-23T11:42:47Z

I've written a post for my company's external design blog, that might be of interest to this list. It's a follow-up to John Schrag's post on "Values in Software Design Practice" which was discussed on this forum earlier.

The original post described the values my team believes contribute to a healthy software design practice. This post looks deeper into why we value "Quality of Data" over "Ease of Data Collection".

The full post is here: http://dux.typepad.com
Feel free to comment.

Lynn Miller
Autodesk

Re: Agile and Academia

2009-11-23T05:45:48Z

William, Vince, and Larry - thanks all for your great feedback. I love this
list!

-Anders

On Sun, Nov 22, 2009 at 10:18 PM, Larry Constantine <lconstantine@...
> wrote:

>
>
> Anders,
>
> I hope I'm not getting too repetitive on this forum, but the Carnegie
> Mellon University
> Master in Human-Computer Interaction and the dual-degree MHCI run jointly
> between the
> University of Madeira and Carnegie Mellon (http://www.labuse.org/mhci/)
> are both
> completely organized around cross-disciplinary teamwork. By the time our
> students graduate
> they have extensive experience in teams that involve at least one person
> from
> graphics/design, one from the social sciences, and one or more from
> software
> engineering/computer science. That experience includes a 9-month project in
> business and
> industry producing real results. The newly formed Madeira Interactive
> Technologies
> Institute is also centered on interdisciplinary perspectives and
> collaboration.
>
> So, the future may be brighter for some graduates.
>
> --Larry Constantine, IDSA, ACM Fellow
> Professor | University of Madeira | Funchal, Portugal
> Director | Laboratory for Usage-centered Software Engineering |
> www.LabUSE.org
> Chief Scientist, Constantine & Lockwood Ltd
>
>
>

RE: Agile and Academia

2009-11-22T19:17:55Z

Anders,

I hope I'm not getting too repetitive on this forum, but the Carnegie Mellon University
Master in Human-Computer Interaction and the dual-degree MHCI run jointly between the
University of Madeira and Carnegie Mellon (http://www.labuse.org/mhci/) are both
completely organized around cross-disciplinary teamwork. By the time our students graduate
they have extensive experience in teams that involve at least one person from
graphics/design, one from the social sciences, and one or more from software
engineering/computer science. That experience includes a 9-month project in business and
industry producing real results. The newly formed Madeira Interactive Technologies
Institute is also centered on interdisciplinary perspectives and collaboration.

So, the future may be brighter for some graduates.

--Larry Constantine, IDSA, ACM Fellow
Professor | University of Madeira | Funchal, Portugal
Director | Laboratory for Usage-centered Software Engineering | www.LabUSE.org
Chief Scientist, Constantine & Lockwood Ltd

Re: Agile and Academia

2009-11-22T16:37:41Z

Hi Anders -

Check out the Human Computer Interaction program at Iowa State University:
http://www.hci.iastate.edu/

It is a fantastic interdisciplinary program that develops in its students the breadth of perspective you suggest.

Best,
Vince

--- On Sun, 11/22/09, Anders Ramsay <andersr@...> wrote:

From: Anders Ramsay <andersr@...>
Subject: [agile-usability] Agile and Academia
To: agile-usability@...
Date: Sunday, November 22, 2009, 3:50 PM

Hi,

I recently posted a blog entry on why I think one key source for much
of the Us/Them mentality between UX designers and agile software
developers (at least what I have experienced) can be traced back to
how we are separated during our formative years in educational
institutions, with those studying computer science not having much
contact with those studying graphic design, or more recently
interaction design. Many of them have never actually worked with
those from the other discipline until after graduating and find
themselves thrown into project teams with people who may be looking at
the craft of software development from a completely different
perspective. The full post is at http://is.gd/516fE

Is this an accurate assessment? Am I making too much out of this
separation? Are there educational institutions that have take steps to
better integrate the various disciplines the eventually will need to
collaborate in the workplace?

I also received an interesting comment to my posting, and would love
to hear what people on this list have to say about the following:

[In response to me proposing is that educational programs incorporate
pairing across disciplines.]
Commenter: "Your whole article assumes a truism that I’m not sure has
been proven, especially at the academic level, which is that pairing
is more efficient (same or cross-disciplinary)."

Commenter: "In my experience a solid waterfall approach has been
infinitely more successful cross-disciplinarily than any type of good
or bad Agile I have worked with (and I’ve been forced to work with
many). Statistically or through any other empirical measure (and I
don’t have anything but anecdotal evidence myself) no one has PROVEN
that Agile is better than non-agile."

-Anders

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

Yahoo! Groups Links

Re: Agile and Academia

2009-11-22T14:43:20Z

Hi, Anders! Interesting!

Anders Ramsay wrote:
> I also received an interesting comment to my posting, and would love
> to hear what people on this list have to say about the following:
>
> [In response to me proposing is that educational programs incorporate
> pairing across disciplines.]
> Commenter: "Your whole article assumes a truism that I’m not sure has
> been proven, especially at the academic level, which is that pairing
> is more efficient (same or cross-disciplinary)."
>

I would be a little surprised that nobody has academically proven the
value of people with different skill sets closely collaborating to
achieve a shared goal, which is all that cross-disciplinary pairing is.
I'd start looking in Surowiecki's bibliography, but for me it's in the
"duh" category.

It's true that nobody has fully proven the value of pair programming,
although they have managed to get evidence that undermines the common
negative reaction that work would take twice as much time, and they have
demonstrated short-term quality improvements, too.

But I think the real benefits come from long-term sustainability through
deep shared understanding, and you're never going to prove anything
either way on the dozen-freshmen-for-a-semester studies that I've seen.
If somebody would like to fund proper studies on pairing, please let me
know. I'm sure I could do it for less than bringing a single drug to
market. :-)

> Commenter: "In my experience a solid waterfall approach has been
> infinitely more successful cross-disciplinarily than any type of good
> or bad Agile I have worked with (and I’ve been forced to work with
> many). Statistically or through any other empirical measure (and I
> don’t have anything but anecdotal evidence myself) no one has PROVEN
> that Agile is better than non-agile."
>

Nobody will ever prove it as some sort of universal. First: there is no
Agile method. Saying you're "doing Agile" is like saying you're from
North America. It may be true, but it's not very informative. Second:
teams, projects, companies, and workloads vary too much. Third: like
Lean Manufacturing, mastering an Agile approach requires pervasive
change in culture and philosophy as well as project behaviors. Agile vs
non-Agile is too simple a question to study. And so on.

But equally, nobody has ever "PROVEN", in the academic sense, that any
development process is "better". We're not doing science here, and -- as
often happens in this debate -- holding one just option to a
double-blind standard of proof is faintly ridiculous.

However, if you are the sort of person who values the scientific method,
then I'd suggest Agile approach fits better with that. All the good
Agile teams I know are continually experimenting with their process,
their product, their tools, and their techniques. Short-cycle iterative
processes let you do that in ways that are impossible in waterfall-like
processes.

Turning to that commenter's broader point, that their experience leads
them another way: ok, fine. Their experience doesn't match my
experience, and I have theoretical reasons why I think their implied
conclusion is bunk, but I'm not the boss of them, so they should do what
they think best.

If they can find somewhere to work that way, that is. Classic waterfall,
with it's necessarily higher capital costs and risk profiles, is an
endangered species here in the Silicon Valley region. Barring perhaps a
few old-growth companies, I expect it will be extinct here for software
in another 10-15 years.

William

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/agile-usability/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/agile-usability/join
(Yahoo! ID required)

<*> To change settings via email:
agile-usability-digest@...
agile-usability-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
agile-usability-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Agile and Academia

2009-11-22T12:50:03Z

Hi,

I recently posted a blog entry on why I think one key source for much
of the Us/Them mentality between UX designers and agile software
developers (at least what I have experienced) can be traced back to
how we are separated during our formative years in educational
institutions, with those studying computer science not having much
contact with those studying graphic design, or more recently
interaction design. Many of them have never actually worked with
those from the other discipline until after graduating and find
themselves thrown into project teams with people who may be looking at
the craft of software development from a completely different
perspective. The full post is at http://is.gd/516fE

Is this an accurate assessment? Am I making too much out of this
separation? Are there educational institutions that have take steps to
better integrate the various disciplines the eventually will need to
collaborate in the workplace?

I also received an interesting comment to my posting, and would love
to hear what people on this list have to say about the following:

[In response to me proposing is that educational programs incorporate
pairing across disciplines.]
Commenter: "Your whole article assumes a truism that I’m not sure has
been proven, especially at the academic level, which is that pairing
is more efficient (same or cross-disciplinary)."

Commenter: "In my experience a solid waterfall approach has been
infinitely more successful cross-disciplinarily than any type of good
or bad Agile I have worked with (and I’ve been forced to work with
many). Statistically or through any other empirical measure (and I
don’t have anything but anecdotal evidence myself) no one has PROVEN
that Agile is better than non-agile."

-Anders

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/agile-usability/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/agile-usability/join
(Yahoo! ID required)

<*> To change settings via email:
agile-usability-digest@...
agile-usability-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
agile-usability-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Re: Agile vs. Creativity

2009-11-18T21:25:42Z

Scott Preece wrote:
>
> My understanding was that the normal model was that the PO prioritizes
> stories, engages in conversations as needed, and provides feedback on
> iteration deliveries, but doesn't get involved in the "inside" of the
> work.

The model I teach involves as much engagement as possible. That includes
enough feedback during construction that any sort of end-of-iteration
feedback is a formality. If a pair of developers regularly goes more
than a few hours without showing something to a product manager, I
normally consider that a bad sign.

As to visual design, some of my clients pair designers and developers
together for extended periods as the visual aspects of a given feature
are hammered out. If the product managers had detailed opinions on
visual design, I'm sure they'd participate at that stage, but generally,
they don't. They leave visual design to the local experts in that. They
buy in at an earlier stage, where they see interface sketches and style
samples. Even there, though, I don't see much back-seat designing.

William

RE: New to Agile Usability

2009-11-18T15:07:27Z

The start could be with roles listings:

"Usability expert"

UX designer

UI developer

Interactive designer

In Agile teams general specialists are becoming the norm and they are the
champions; in our talk here they are the UX/UI/Interactive
designer/developer; someone who has the skill to work understand the tell
the story with the product owner/customer using low-fidelity medium and
gradually work their way thru in a "UX design studio".

For an agile team, specialization in the UX/UI/Usability domain did not
really help. What I see working is a UX person with knowledge and experience
on usability heuristics and standards, usability low-fi tools, information
structure, and user-centric experience; this person is capable of telling
the story based o persona/user role needs, verifying the quick low-cost
design models (example www.balsamiq.com) , designing the general theme and
look & feel, iteratively adding higher fidelity designs by feature (or
story, or MMF) , implementing UI elements in different technologies (JS,
JQuery, Flash, Sliverlight etc..), working closely with developers,
processing feedback and usability test results, and analyzing the
post-release usability stats.

A specialist usability person sounds like a software architect who no longer
code; nevertheless, this specialization may be useful in places that
provides usability assessment as a service on its own. But in an agile
software development, a UX Knight is a key role for success.

I completely support cross functional teams yet I see "meta teams" of
developers, another of UX persons, and another of product owners as a great
venue for knowledge sharing and continuous improvement on the organizational
level.

Hope this answers part of the questions.

Thanks,

Mouneer

From: agile-usability@...
[mailto:agile-usability@...] On Behalf Of Elmohanned Ahmed
Sent: Tuesday, November 10, 2009 10:49 PM
To: agile-usability@...
Subject: [agile-usability] New to Agile Usability

Hi All,

We are an organization that started the move to agile about a year ago. Our
usability team is quiet perplexed. We basically work in intranet web
applications. Can anybody update on the typical role of a usability guy in a
project? What does he do? When? Any details are welcome.

Thanks,

ElMohanned

Inspection to prevent defects is absolutely required for any process.
Inspection to find defects is waste.

Shigeo Shingo, Study of Toyota Production system

Disclaimer: NOTICE The information contained in this message is confidential
and is intended for the addressee(s) only. If you have received this message
in error or there are any problems please notify the originator immediately.
The unauthorized use, disclosure, copying or alteration of this message is
strictly forbidden. Raya will not be liable for direct, special, indirect or
consequential damages arising from alteration of the contents of this
message by a third party or as a result of any malicious code or virus being
passed on. Views expressed in this communication are not necessarily those
of Raya.If you have received this message in error, please notify the sender
immediately by email, facsimile or telephone and return and/or destroy the
original message.

image001.jpg (494 bytes) Download Attachment
image002.jpg (456 bytes) Download Attachment

Re: Agile UX SIG London: pub meetup

2009-11-18T09:03:24Z

On 13 Nov 2009, at 22:42, joko_1.rm wrote:

> Hello folks in London, Brighton, and on the rest of the island!
>
> I have discussed the idea of an agile UX SIG with several people (Una Walsh, Adrian Howard, Stuart Cruickshank, just to name a few). We all agreed that we would like to make it happen! Aim is to bring people together who are interested in agile & user experience - ux people, designers, developers, scrum masters, product owners, project managers, etc.
>
> The first event will be an informal pub meetup, to see who is interested and to discuss ideas for the future (such as a conference-style agile ux event, an agile retreat, or workshops).
>
> We haven't decided on a location yet, but will probably go for a venue near london bridge (convenient for trains). Any suggestions highly welcome! Of course, if you feel like offering to sponsor this event (e.g. by hosting it), get in touch.
>
> Please register here: http://agileuxsig.eventbrite.com/
>
> And please do spread the word - the more diversity, the better.

A rather belated "bloody good idea".

I'm going. Hope to see others from this list there too :-)

Cheers,

Adrian
--
http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh

Re: Agile UX and Digital Marketing

2009-11-18T08:49:31Z

Hello,

I think that we can adapt most of the practices of Agile (XP, Scrum, TDD, etc.)

The creative area (as IA, Design, Usability) are much cognitive than a software. In my opinion, that happens because when we build a software we constantly focus on FUNCTIONALITY. When we think about Agencies/MKT/Websites the focus is on DESIGN/CREATIVITY.

Also, we have a team that have different skills (designers, architects, programmers, flashers...) and doing a "pair programming" with a designer and a programmer sounds goofy :)

But I think that we can adapt the Scrum process, for example. The Kanban/Taskboard is usable in 99,9% of the cases, I believe. The iteration process could work fine, also.

Imagine that your first sprint is to deliver a design of the HOME website. So, you will have IA and designers working a lot, and programmers working less. But, the programmers are very important here, because they will give insights and also will start thinking about the funcions of the website.

Who dont have the problem where all the IA and design are approved, but when the programming start, they found a lot of problems there?

The "cross-function" teams are great, but that dont means that they need to pair programming all the time. But track all the project from the beginning to the end.

Well, what do you think? Sounds a little crazy yet, or helped? :)

Thanks
Flavio
www.agileway.com.br

I think that we could adapt, for example, the SCRUM process.

--- In agile-usability@..., chris chandler <chris.chandler@...> wrote:

>
> Good question Christine, I've been wondering about this myself for a long
> time. A lot of valuable discussion on this list has been about how to
> join/marry User Centered Design or UX, with Agile methods, but very little
> time has been spent discussing the actual visual appeal of a consumer facing
> web site or application.
>
> On the UX side (and by this I mean Information Architecture, Interaction
> Design and Usability) there seems to be a consistent discussion about the
> need for what Larry Constantine recently described of a "coherent UI
> architecture, worked out in advance."
>
> Are there any major, or at least successful creative agencies that have
> adopted "Agile Creative" as an approach? I'd love to hear about them...
>
> -cc
>
>
>
>
>
>
> On Tue, Nov 10, 2009 at 3:04 PM, Christine <christinemvelez@...>wrote:
>
> >
> >
> > A lot of posts I come across seems to limit the discussion of agile UX to
> > the development of software. Or the good experiences I read about are with
> > software development projects. I worked at a digital marketing agency and
> > have found that, so far, the agile process hasn't allowed us to build our
> > best work. That is, work that is a good user experience, well developed, and
> > thoughtfully creative. However, we rarely used the agile process, so I
> > imagine inexperience with the process has impacted its effectiveness. The
> > projects that we have used them on appear to be good candidates (i.e., tech
> > focused, small teams) but creative and UX always are a factor in our
> > projects.
> >
> > Does anyone have tips or even good experiences to share regarding agile UX
> > in the digital marketing arena?
> >
> > CV
> >
> >
>

Re: Agile vs. Creativity

2009-11-17T20:56:08Z

Hi, Scott,

Scott Preece wrote:
> So, do you (and others on this list) think it would be common practice
> for the PO to be sitting with developers while they're writing code?

I couldn't tell you how common it is, but I've seen it. And it was a
good thing. Not only did they reach a resolution on differences in a
relatively short period of time, but each got more respect for the job
the other was doing.

> It just means that each increment is done (deliverable) before
> it's delivered for PO review.

I've always found it better when the PO is more involved than that.
Sure, there are some pains at the start, but as those subside the team
(which includes the PO) works much more fluidly.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

Re: Agile vs. Creativity

2009-11-17T18:34:53Z

Sorry for the late reply. I don't have access to my personal emails at work and my evening is very short.

See the my other post to John Schrag about stakeholders.

Stakeholders: Usually customers and/or internal senior managers.

Some examples:
- looks too old style - not web 2.0 look
- color scheme
- too flat - no interesting interactions
- too crowded
...

- Cindy

________________________________
From: George Dinwiddie <lists@...>
To: agile-usability@...
Sent: Tue, November 17, 2009 8:05:34 AM
Subject: Re: [agile-usability] Agile vs. Creativity

Cindy,

You say "sometimes the result was still not satisfying." It would help
me if you would elaborate on this a little. Not satisfying to whom?
Not satisfying in what way? What did you see and hear that leads you to
say it was not satisfying?

- George

Cindy Lu wrote:

>
>
> Tim,
>
> I was thinking the visual design is part of the architecture work.
>
> Anyway, the symptom we have is a lot of discussions on visual designs,
> sometimes the result was still not satisfying. I tried to figure our a
> way to make it better.
>
> - Cindy
>
> ------------ --------- --------- --------- --------- --------- -
> *From:* Tim Wright <sambo.shacklock@ gmail.com>
> *To:* agile-usability@ yahoogroups. com
> *Sent:* Sun, November 15, 2009 4:56:02 PM
> *Subject:* Re: [agile-usability] Agile vs. Creativity
>
>
>
>
> Larry Constantine wrote something a week or so ago on a different
> conversation in this mailing list (about Neilson's agile user experiance
> alertbox):
>
> > I had looked at the earlier report, and the follow-up nicely
> reinforces and refines the
> > findings. It is gratifying to find Jakob concluding what Lucy and I
> have been preaching
> > for the last 7-8 years, particularly about the importance of a
> coherent UI architecture
> > worked out in advance.
>
> Perhaps what Cindy is noticing here is a symptom of not doing the
> upfront architectural work?
>
> Tim
> On Mon, Nov 16, 2009 at 10:46 AM, George Dinwiddie <lists@idiacomputin g
> .com <mailto:lists@idiacomputing .com>> wrote:
>
>
>
> Hi, Cindy,
>
> I remember what you wrote the first time. That doesn't answer my
> questions, though. Should I repeat them?
>
>
>
> Is it the designer who's making the decision as to what's a better
> design? Or is it the stakeholder? Or do each of these people think
> /they/ are the one?
>
> It sounds to me like the designer wants to create a final work before
> getting the opinion of the stakeholder. Doesn't that disenfranchise the
> stakeholder?
>
> By the way, when I said, "What would happen if a designer and a
> stakeholder sat down together, so they could discuss what's liked, and
> not liked, about a design /as it's being sketched/?" I really meant
> that. Not "putting key points on the paper and review them with
> stakeholders. " I mean sitting down together and working on it together.
>
> - George
>
>
> Cindy Lu wrote:
> >
> >
> > Hi! John and Gorge,
> >
> > I would like to go back to the original issues we started with:
> >
> > We found two issues for some design projects:
> > 1. The number of iterations becomes endless (almost)
> > 2. At the end, the final design is still not very satisfying
> >
> > I would like to understand if you have similar problems or in
> your team,
> > quick iterations work very well in the graphic design area.
> >
> > My observation is that some creative people need some time alone
> to do
> > the creation. For some people, this time period maybe longer.
> >
> > - Cindy
> >
> > ------------ --------- --------- --------- --------- --------- -
> > *From:* John Schrag <john@schrag. ca <mailto:john% 40schrag. ca>>
> > *To:* agile-usability@ yahoogroups. com
> <mailto:agile- usability% 40yahoogroups. com>
> > *Sent:* Sat, November 14, 2009 6:58:11 PM
> > *Subject:* Re: [agile-usability] Agile vs. Creativity
> >
> >
> >
> > It wasn't clear from your note --- Are goals set at the beginning
> of the
> > design process? Because I think any design (interaction or
> graphic) can
> > be tweaked and refined until the end of time, unless you set
> yourself
> > some ending conditions. I'm not qualified to speak for graphic
> design,
> > but for interaction design we try to set specific measurable
> goals (the
> > user can find the feature in X amount of time without consulting the
> > help; she can use it successfully to achieve her goals, etc) and we
> > stop refining once the design has hit those goals. There is a
> > temptation to keep improving the design, but time you spend doing
> that
> > is time you are taking away from other things that need your
> attention.
> >
> > I think having a design brief implies having goals, so it is a
> good thing.
> >
> > In many disciplines, the design process starts with ideation --
> > generating lots of ideas very quickly but not developing them --
> then
> > moves on to winnow the ideas down to a few good ones, and develop
> the
> > few good ones further. I think this is valid for interface design as
> > well. The only question then is your time budget for each of these
> > activities. I will generally spend an hour or two coming up with a
> > dozen or so quick interface skeches for a new feature, before
> picking
> > the most likely one and developing it into something more complete.
> > Another trick is having a good review process, with the review
> > focussing on the right level of critique. If you are presenting
> the UI
> > general layout, and someone is complaining about the fonts and
> colours,
> > then they need some coaching on being in a design review.
>

--
------------ --------- --------- --------- --------- --------- -
* George Dinwiddie * http://blog. gdinwiddie. com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
------------ --------- --------- --------- --------- --------- -

RE: Agile vs. Creativity

2009-11-17T18:31:10Z

It might be interesting to find out what the iteration strategy was and how it was changed as well as what the new designer did that was different. Then, compare the two approaches to the third instance you mentioned.

Mike Dwyer
Principal Agile Consultant

BigVisible Solutions
url: <http://www.bigvisible.com/> http://www.bigvisible.com

cell: (978) 376-4422

email: <mailto:mdwyer@...> mdwyer@...

From: agile-usability@... [mailto:agile-usability@...] On Behalf Of Cindy Lu
Sent: Tuesday, November 17, 2009 8:56 PM
To: agile-usability@...
Subject: Re: [agile-usability] Agile vs. Creativity

John,

In one project, the client was not happy with the final design after many frequent iterations. For the same client and another project, we changed a designer and iteration strategy. The design was finalized after 3 iterations. The client was very happy with the end result. In another project, a key stakeholder was not happy.

- Cindy

_____

From: John Schrag <john@...>
To: agile-usability@...
Sent: Mon, November 16, 2009 8:06:39 AM
Subject: Re: [agile-usability] Agile vs. Creativity

The thing that struck me in the original note was Cindy's description
of the designs as being "not satisfying". Does this mean not
satisfying the goals (assuming there were any) or does it mean that
one person on the team (the owner?) is not satisfied? It made me
wonder if this is actually a case of micromanagement.

I also find it odd that some notes on this thread seem to imply that
asking for two or three days to work through a design task is somehow
un-agile. That's not a long time, unless your sprint length is
really, really short.

-john

Re: Agile vs. Creativity

2009-11-17T18:07:56Z

Hello, Cindy. On Tuesday, November 17, 2009, at 8:47:08 PM, you
wrote:

>>How is more time away from the team going to get the idea any
>> better, its expression to the team any better, or the team's
>> willingness to do more changes and better?

> 1) to absorb the requirement/feedback session to make sure the
> problems and requirements are well understood
> 2) to generate some ideas and try them
> 3) consult a peer for their opinions
> 4) to think through how to present the design

Those MIGHT produce a better idea. I don't see that it will improve
the idea's fit with the team's ideas, that it will make it easier to
sell to the team, or that the team will become more willing to
listen.

But again, of course, you should do as you think is best.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Design is the thinking one does before, during, and after
implementation. It works best for me with a little up front, most of
it during implementation, and very little after it's too late.

Re: Agile vs. Creativity

2009-11-17T18:04:29Z

Hello, Cindy. On Tuesday, November 17, 2009, at 8:16:11 PM, you
wrote:

> The stakholder(s) usually have very limited time. So when we
> present to them, we want to make sure the idea is well thought
> out. It does not mean the design is final. The designer felt if
> he is left alone for 2-3 days, he can create several options from
> different angles instead of focusing on one less than half based
> idea. Sometimes, a good idea is easily killed if it is not well thought through.

> I think visual design work is different from other types of
> creation work in system design. In addition, people are different how best they can produce.

Of course you should do as you feel is best. I've noticed, however,
that every specialty thinks that theirs is the one that needs to be
handled differently in Agile. My experience suggests that this is
not the case.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Without practice, no emergence. -- Dougen Zenji

Re: Agile vs. Creativity

2009-11-17T17:56:25Z

John,

In one project, the client was not happy with the final design after many frequent iterations. For the same client and another project, we changed a designer and iteration strategy. The design was finalized after 3 iterations. The client was very happy with the end result. In another project, a key stakeholder was not happy.

- Cindy

________________________________
From: John Schrag <john@...>
To: agile-usability@...
Sent: Mon, November 16, 2009 8:06:39 AM
Subject: Re: [agile-usability] Agile vs. Creativity

The thing that struck me in the original note was Cindy's description
of the designs as being "not satisfying". Does this mean not
satisfying the goals (assuming there were any) or does it mean that
one person on the team (the owner?) is not satisfied? It made me
wonder if this is actually a case of micromanagement.

I also find it odd that some notes on this thread seem to imply that
asking for two or three days to work through a design task is somehow
un-agile. That's not a long time, unless your sprint length is
really, really short.

-john

Re: Agile vs. Creativity

2009-11-17T17:47:08Z

Hi! Ron,

Thanks for sharing your thought.

>How is more time away from the team going to get the idea any
better, its expression to the team any better, or the team's
willingness to do more changes and better?

1) to absorb the requirement/feedback session to make sure the problems and requirements are well understood
2) to generate some ideas and try them
3) consult a peer for their opinions
4) to think through how to present the design

- Cindy

________________________________
From: Ron Jeffries <ronjeffries@...>
To: agile-usability@...
Sent: Mon, November 16, 2009 6:01:18 AM
Subject: Re: [agile-usability] Agile vs. Creativity

Hello, chris. On Sunday, November 15, 2009, at 6:39:01 PM, you
wrote:

> If that isn't done, then I can imagine it leading to the situation from the
> original post -- you get approval on an idea with a bunch of changes, and
> those changes beget more changes, and after a couple of rounds, it's hard to
> see that progress is being made (eg, get the colors right and the font may
> need adjustment, get the font right and scaling of images could look wrong,
> etc etc)

How is more time away from the team going to get the idea any
better, its expression to the team any better, or the team's
willingness to do more changes and better?

Ron Jeffries
www.XProgramming. com
www.xprogramming. com/blog
One test is worth a thousand expert opinions.
-- Bill Nye (The Science Guy)

Re: Agile vs. Creativity

2009-11-17T17:32:36Z

William wrote:

>Cindy, could it be that the endless-iteration projects are ones where they're working serially, rather than starting with (or introducing) wide variations?

We always started with 2-3 design options. Sometimes, none of them are satisfying so the designer started all over again. For a most recent project, after several iterations that lasted several weeks, none of them were chosen.

I put all the designs in one deck, printed them all out and sat with the stakeholders. I asked them only focus on elements they liked and they thought that met the design brief we agreed. I also asked additional requirements in their mind. I documented them in one page. After that session, the designer created one more design. The key stakeholder said "This is it".

- Cindy

Re: Agile vs. Creativity

2009-11-17T17:16:11Z

The stakholder(s) usually have very limited time. So when we present to them, we want to make sure the idea is well thought out. It does not mean the design is final. The designer felt if he is left alone for 2-3 days, he can create several options from different angles instead of focusing on one less than half based idea. Sometimes, a good idea is easily killed if it is not well thought through.

I think visual design work is different from other types of creation work in system design. In addition, people are different how best they can produce.

I would like to try the idea for the next project to see how it goes.

- Cindy

________________________________
From: George Dinwiddie <lists@...>
To: agile-usability@...
Sent: Sun, November 15, 2009 8:11:04 PM
Subject: Re: [agile-usability] Agile vs. Creativity

I'm not quite sure what Larry means by "a coherent UI architecture
worked out in advance." Perhaps he'll elaborate.

Cindy mentioned, "the quality of the visual design, e.g. contrast,
balance, cohesiveness of the theme, if sample text presented, no
spelling errors, etc." It seems to me that the designer and the
stakeholder can sit together and play with these parameters, and others,
discussing them in both design terms and business terms, and coming to
some sort of agreement. I wonder why the designer feels the need to do
this work without feedback and then present it all at once for approval.
That seems like a good recipe for the "almost endless" number of
iterations.

- George

Tim Wright wrote:

>
>
>
> Hmm. Given the sheer number of IT architects we have at work, I could
> well mean neither :)
>
> I meant: "a coherent UI architecture worked out in advance" (from Larry :).
> Tim
> On Mon, Nov 16, 2009 at 11:40 AM, Ron Jeffries <ronjeffries@ acm.org
> <mailto:ronjeffries@ acm.org>> wrote:
>
>
>
> Hello, Tim. On Sunday, November 15, 2009, at 4:56:02 PM, you
> wrote:
>
>
>
> > Perhaps what Cindy is noticing here is a symptom of not doing the
> upfront
> > architectural work?
>
> If you really mean architectural work, it turns out that
> surprisingly little is needed up front. Architecture evolution works
> just fine.
>
> If you mean UX design work, it is my expectation that this, too,
> could be made to evolve, but I grant that I am not expert in the
> area so could conceivably be wrong.
>
> Ron Jeffries
> www.XProgramming. com <http://www.xprogramming.com/>
> www.xprogramming. com/blog <http://www.xprogramming.com/blog>
> In times of stress, I like to turn to the wisdom of my Portuguese
> waitress,
> who said: "Olá, meu nome é Marisol e eu serei sua garçonete."
> -- after Mark Vaughn, Autoweek.
>

Re: Agile vs. Creativity

2009-11-17T08:37:28Z

So, do you (and others on this list) think it would be common practice for the PO to be sitting with developers while they're writing code?

My understanding was that the normal model was that the PO prioritizes stories, engages in conversations as needed, and provides feedback on iteration deliveries, but doesn't get involved in the "inside" of the work. I don't see why that would be different for design work than for code - the designer should have the time needed to get the work to a reviewable state before presenting it for feedback.

I think the problem is that designs, being visual, always have a current state that someone can respond to and therefore seems to be "reviewable", where functionality stories don't have a visible state until an increment of work has been finished. You need to treat the designer the same way you would a coder - the work should be done in increments, but each increment should be finished before it's reviewed. This doesn't mean there isn't collaboration going on - the designer should get feedback from other designers while the increment is being created. It just means that each increment is done (deliverable) before it's delivered for PO review.

regards,
scott

>
>From: George Dinwiddie <lists@...>
>To: agile-usability@...
>Sent: Tue, November 17, 2009 7:22:42 AM
>Subject: Re: [agile-usability] Agile vs. Creativity
>
> >
>>
>
>chris chandler wrote:
>>> You say they should collaborate over sketches, I went to great length to
>>> discuss how a visual designer works (in photoshop). At this point I'm
>>> sure I don't understand what you are suggesting -- how would the
>>> conversation go in your world??
>
>>Chris,
>
>>I don't want to dive down the rabbit-hole of the hypothetical. Cindy is
>>describing a real situation. I'm trying to base my statements on her
>>observations. I'm not trying to describe a way for everyone to work all
>>the time. Mostly people can work out effective ways of working
>>together. We notice the times when it's not so effective.
>
>>Cindy has noticed that this situation is not so effective. Her team has
>>discussed this (perhaps without the stakeholder or PO or whoever is
>>filling the "other side" of the situation), and decided that they'd be
>>better off left alone more, so they can do the work they know how to do.
>> This is a very tempting path, I know from experience.
>
>>I also know from experience, that even if they're really great at what
>>they do, going off and working alone to present a more-complete version
>>to the PO (or whomever) is not likely to generate a closer understanding
>>between the PO and the designer such that the concerns of both are well
>>satisfied.
>
>>I also know from experience, that even people who think they're a good
>>judge of something they don't know how to do themselves, gain a greater
>>appreciation of the skill and nuance when they work together with
>>someone who can communicate while exploring the alternatives with them.
>> And this is fractal, in that it's quite similar at various levels of
>>detail.
>
>>I also know from experience, that two people trying to work together in
>>this fashion often have to learn how to work together in this fashion in
>>order to do so. And even if they've worked in this fashion before, they
>>both have to learn how to work in this fashion with these two particular
>>people. "How the conversation goes" depends entirely on these two
>>people and their context.
>
>>I'm not saying it's easy. And there are many possible dysfunctions,
>>ranging from the know-it-all PO and the prima donna designer to the
>>simple difficulty of verbalizing intangibles. We don't have to solve
>>all of these possible dysfunctions, though. We just need to help this
>>one particular case.
>
>>- George
>
>>--
>> ------------ --------- --------- --------- --------- --------- -
>> * George Dinwiddie * http://blog. gdinwiddie. com
>> Software Development http://www.idiacomputing.com
>> Consultant and Coach http://www.agilemaryland.org
>> ------------ --------- --------- --------- --------- --------- -
>
>
>

RE: Agile vs. Creativity

2009-11-17T07:48:12Z

William

Your citing the Dunning-Kruger effect highlights a core change that Agile
and Scrum brings about. The Dunning-Kruger effect is an example of the
emotional muscle memory conventional work practices have built in most of
us. These practices stress individual superiority over others; the
profession you are in; the organization you are part of; the people you feel
will be impressed enough to reward you. The Dunning-Kruger effect feeds on
the silly notion that each one of us is capable of doing anything by
ourselves. What a crock. Name one thing you have done with no one else
involved. It is an impossibility, unless you actually carved out each part
of the computer you are working on, formed each gate of the ALU (computer
chip) and then created each pixel of light and dark you need to see this on
the screen.

The Dunning-Kruger effect exists because we try to live up to this
fabrication of living.

Agile tosses a wrench into that notion and sits down and asks the other poor
bloke across the way what they think, what they are doing and can we be of
assistance in what they are doing a long phrase for collaboration. We
admit that we cannot do it all and from that we form hardy bands of people
who get things done because we know that individually we are great a very
few things, OK at some and for the most part are barely average to awful.
That may not be you but it is, for many of us, what we use to find and form
complimentary cross functional teams. We also recognize that the product
owner is the most exposed of any member of the team. Yes, I did say they are
part of the team.

So why shouldnt they show the Dunning-Kruger effect more than others? What
have you done to provide empirical evidence that the Dunning-Kruger effect
is not the way it is but a façade? Look the Product Owner is the most
exposed, vulnerable, and least ready to answer the three terrifying
questions any of us face. How is it going?; Are we on budget?; Will we
have everything we want in the product as of today?

The challenge we face in this nebulous cloud of usability or any other cloud
of emerging solutions is the same. If we dont band together, we are all
going to suffer alone. Agile is the both the grease that loosens the knot
of muscle memory and the glue that can make collaboration stick.

Mike Dwyer
Principal Agile Consultant

BigVisible Solutions
url: <http://www.bigvisible.com/> http://www.bigvisible.com

cell: (978) 376-4422

email: <mailto:mdwyer@...> mdwyer@...

From: agile-usability@...
[mailto:agile-usability@...] On Behalf Of William Pietri
Sent: Monday, November 16, 2009 10:06 PM
To: agile-usability@...
Subject: Re: [agile-usability] Agile vs. Creativity

George Dinwiddie wrote:
> Why would you imagine the graphic designer being just a pair of hands on
> the computer while the PO creates the graphic design? Do you really
> think so little of Product Owners? Do you really think so little of
> graphic designers?
>

To be fair, a lot of novice product owners do mistake themselves for
bosses, so back-seat driving is regrettably common. And visual design is
one of those areas where quite a lot of people think their opinion is
just as good as a professional's.[1] So Chris may be imagining that
relationship because that's mainly what he sees.

Personally, when there are big differences of opinion, I like to see
visual designs evaluated a) by other visual design experts, and b) via
actual data. And similarly for almost any other field of expertise. But
generally, I think Agile teams work best when people trust each other to
handle their fields.

William

[1] Due, I think, to the Dunning-Kruger effect:
http://en.wikipedia.org/wiki/Dunning-Kruger_effect

Re: Agile vs. Creativity

2009-11-17T06:56:25Z

This may not be an easy thing to describe. I suspect more people would say that, viewed as an object, the iPhone is more "satisfying" than the Google/Motorola DROID. How would you describe what makes it so?

scott

>
>From: George Dinwiddie <lists@...>
>To: agile-usability@...
>Sent: Tue, November 17, 2009 7:05:34 AM
>Subject: Re: [agile-usability] Agile vs. Creativity
>
> >
>>
>
>Cindy,
>
>>You say "sometimes the result was still not satisfying." It would help
>>me if you would elaborate on this a little. Not satisfying to whom?
>>Not satisfying in what way? What did you see and hear that leads you to
>>say it was not satisfying?
>
>>- George
>
>>Cindy Lu wrote:
>>>
>>>
>>> Tim,
>>>
>>> I was thinking the visual design is part of the architecture work.
>>>
>>> Anyway, the symptom we have is a lot of discussions on visual designs,
>>> sometimes the result was still not satisfying. I tried to figure our a
>>> way to make it better.
>>>
>>> - Cindy
>>>
>>> ------------ --------- --------- --------- --------- --------- -
>>> *From:* Tim Wright <sambo.shacklock@ gmail.com>
>>> *To:* agile-usability@ yahoogroups. com
>>> *Sent:* Sun, November 15, 2009 4:56:02 PM
>>> *Subject:* Re: [agile-usability] Agile vs. Creativity
>>>
>>>
>>>
>>>
>>> Larry Constantine wrote something a week or so ago on a different
>>> conversation in this mailing list (about Neilson's agile user experiance
>>> alertbox):
>>>
>>> > I had looked at the earlier report, and the follow-up nicely
>>> reinforces and refines the
>>> > findings. It is gratifying to find Jakob concluding what Lucy and I
>>> have been preaching
>>> > for the last 7-8 years, particularly about the importance of a
>>> coherent UI architecture
>>> > worked out in advance.
>>>
>>> Perhaps what Cindy is noticing here is a symptom of not doing the
>>> upfront architectural work?
>>>
>>> Tim
>>> On Mon, Nov 16, 2009 at 10:46 AM, George Dinwiddie <lists@idiacomputin g
>>> .com <mailto:lists@idiacomputing .com>> wrote:
>>>
>>>
>>>
>>> Hi, Cindy,
>>>
>>> I remember what you wrote the first time. That doesn't answer my
>>> questions, though. Should I repeat them?
>>>
>>>
>>>
>>> Is it the designer who's making the decision as to what's a better
>>> design? Or is it the stakeholder? Or do each of these people think
>>> /they/ are the one?
>>>
>>> It sounds to me like the designer wants to create a final work before
>>> getting the opinion of the stakeholder. Doesn't that disenfranchise the
>>> stakeholder?
>>>
>>> By the way, when I said, "What would happen if a designer and a
>>> stakeholder sat down together, so they could discuss what's liked, and
>>> not liked, about a design /as it's being sketched/?" I really meant
>>> that. Not "putting key points on the paper and review them with
>>> stakeholders. " I mean sitting down together and working on it together.
>>>
>>> - George
>>>
>>>
>>> Cindy Lu wrote:
>>> >
>>> >
>>> > Hi! John and Gorge,
>>> >
>>> > I would like to go back to the original issues we started with:
>>> >
>>> > We found two issues for some design projects:
>>> > 1. The number of iterations becomes endless (almost)
>>> > 2. At the end, the final design is still not very satisfying
>>> >
>>> > I would like to understand if you have similar problems or in
>>> your team,
>>> > quick iterations work very well in the graphic design area.
>>> >
>>> > My observation is that some creative people need some time alone
>>> to do
>>> > the creation. For some people, this time period maybe longer.
>>> >
>>> > - Cindy
>>> >
>>> > ------------ --------- --------- --------- --------- --------- -
>>> > *From:* John Schrag <john@schrag. ca <mailto:john% 40schrag. ca>>
>>> > *To:* agile-usability@ yahoogroups. com
>>> <mailto:agile- usability% 40yahoogroups. com>
>>> > *Sent:* Sat, November 14, 2009 6:58:11 PM
>>> > *Subject:* Re: [agile-usability] Agile vs. Creativity
>>> >
>>> >
>>> >
>>> > It wasn't clear from your note --- Are goals set at the beginning
>>> of the
>>> > design process? Because I think any design (interaction or
>>> graphic) can
>>> > be tweaked and refined until the end of time, unless you set
>>> yourself
>>> > some ending conditions. I'm not qualified to speak for graphic
>>> design,
>>> > but for interaction design we try to set specific measurable
>>> goals (the
>>> > user can find the feature in X amount of time without consulting the
>>> > help; she can use it successfully to achieve her goals, etc) and we
>>> > stop refining once the design has hit those goals. There is a
>>> > temptation to keep improving the design, but time you spend doing
>>> that
>>> > is time you are taking away from other things that need your
>>> attention.
>>> >
>>> > I think having a design brief implies having goals, so it is a
>>> good thing.
>>> >
>>> > In many disciplines, the design process starts with ideation --
>>> > generating lots of ideas very quickly but not developing them --
>>> then
>>> > moves on to winnow the ideas down to a few good ones, and develop
>>> the
>>> > few good ones further. I think this is valid for interface design as
>>> > well. The only question then is your time budget for each of these
>>> > activities. I will generally spend an hour or two coming up with a
>>> > dozen or so quick interface skeches for a new feature, before
>>> picking
>>> > the most likely one and developing it into something more complete.
>>> > Another trick is having a good review process, with the review
>>> > focussing on the right level of critique. If you are presenting
>>> the UI
>>> > general layout, and someone is complaining about the fonts and
>>> colours,
>>> > then they need some coaching on being in a design review.
>>>
>
>>--
>> ------------ --------- --------- --------- --------- --------- -
>> * George Dinwiddie * http://blog. gdinwiddie. com
>> Software Development http://www.idiacomputing.com
>> Consultant and Coach http://www.agilemaryland.org
>> ------------ --------- --------- --------- --------- --------- -
>
>
>

Re: Agile vs. Creativity

2009-11-17T06:08:57Z

Something struck me while reading the last few posts....

On usability issues, there's this fear that because the Product Owner
is in a position of power, he will disregard the contributions of the
designers. This might and is probably true in the experience of many.
As much as I don't believe the Product Owner should be able to force
the programmer to do shoddy work, he should also not be allowed to
force designers to do shoddy work. Remember the XP developer bill of
rights? You have the right to do quality work... I think this is
fundamental to building any good team!!!

Watch out, quality and scope is not the same. There's tons of ways of
implementing a login in terms of scope (users/password hardcoded, in a
file, bypassing by retrieving the OS login, using some network
authentication....). From the simple to the most complex, they can all
be designed and coded at top quality... The product owner gets to
choose the scope according to the value and cost. The quality of of
design and implementation should not be negotiable. I think in the
case of visual designs, there could be multiple valid variations which
could have the same or different business value with varying
implementation costs. As professionals, designers should offer
different options but should always be of top quality. Any suggested
modifications to the design, coming from any team member including the
PO, should always be validated and approved by the designer for quality.

So in summary:

1) I do think we agree that having a Product Owner trump the designer
on design issues is clearly a team dysfunction. If a PO thinks a
design does not work, he should ask the designer for other possible
options by stating his objections and giving useful comments. He
should also be be ready to pay for it, nothing is free. The product
owner owns scope, the designer owns the quality of the proposed
designs. Clearly, in real life, Product Owners will probably meddle. I
believe that as s a professional designer, you are responsible to
state your objection to any forced modification you disagree with. In
some cases, as is stated in the code of conduct of may professions,
you might actually refuse to do the work (in civil engineering for
example, lives might be at stake). In other cases where consequences
might not be so terrible, you might go on and hope to continue
influencing the team. If it happens all the time, then it might be
another problem, see point#3.
2) Everybody can contribute to the UI design. A designer who does not
listen to team members is clearly a team dysfunction.
3) Either the team thrusts that the designer is knowledgeable and
should be listened to, or the team should get another designer. Again,
no thrust in the designer is also a team dysfunction. As the
designer, you might want to think about how you are presenting your
knowledge to the team. It's a question of respect, and it usually
needs to be earned in some way. Being cocky or just banking on the
title is typically not a winning strategy IMHO. A sign that this
problem exists in your team is if you actually need to enforce the
Designer title officially!!!

Anyway, that's my two cents on the subject... YMMV.

Pascal Roy, ing./P.Eng., PMP
Vice-Président/Vice President
Elapse Technologies inc.

[url] www.elapsetech.com
[email]] pascal.roy@...
[cell] 514-862-6836

Le 2009-11-16 à 22:05, William Pietri a écrit :

> George Dinwiddie wrote:
> > Why would you imagine the graphic designer being just a pair of
> hands on
> > the computer while the PO creates the graphic design? Do you really
> > think so little of Product Owners? Do you really think so little of
> > graphic designers?
> >
>
> To be fair, a lot of novice product owners do mistake themselves for
> bosses, so back-seat driving is regrettably common. And visual
> design is
> one of those areas where quite a lot of people think their opinion is
> just as good as a professional's.[1] So Chris may be imagining that
> relationship because that's mainly what he sees.
>
> Personally, when there are big differences of opinion, I like to see
> visual designs evaluated a) by other visual design experts, and b) via
> actual data. And similarly for almost any other field of expertise.
> But
> generally, I think Agile teams work best when people trust each
> other to
> handle their fields.
>
> William
>
> [1] Due, I think, to the Dunning-Kruger effect:
> http://en.wikipedia.org/wiki/Dunning-Kruger_effect
>

Re: Agile vs. Creativity

2009-11-17T05:22:42Z

chris chandler wrote:
> You say they should collaborate over sketches, I went to great length to
> discuss how a visual designer works (in photoshop). At this point I'm
> sure I don't understand what you are suggesting -- how would the
> conversation go in your world??

Chris,

I don't want to dive down the rabbit-hole of the hypothetical. Cindy is
describing a real situation. I'm trying to base my statements on her
observations. I'm not trying to describe a way for everyone to work all
the time. Mostly people can work out effective ways of working
together. We notice the times when it's not so effective.

Cindy has noticed that this situation is not so effective. Her team has
discussed this (perhaps without the stakeholder or PO or whoever is
filling the "other side" of the situation), and decided that they'd be
better off left alone more, so they can do the work they know how to do.
This is a very tempting path, I know from experience.

I also know from experience, that even if they're really great at what
they do, going off and working alone to present a more-complete version
to the PO (or whomever) is not likely to generate a closer understanding
between the PO and the designer such that the concerns of both are well
satisfied.

I also know from experience, that even people who think they're a good
judge of something they don't know how to do themselves, gain a greater
appreciation of the skill and nuance when they work together with
someone who can communicate while exploring the alternatives with them.
And this is fractal, in that it's quite similar at various levels of
detail.

I also know from experience, that two people trying to work together in
this fashion often have to learn how to work together in this fashion in
order to do so. And even if they've worked in this fashion before, they
both have to learn how to work in this fashion with these two particular
people. "How the conversation goes" depends entirely on these two
people and their context.

I'm not saying it's easy. And there are many possible dysfunctions,
ranging from the know-it-all PO and the prima donna designer to the
simple difficulty of verbalizing intangibles. We don't have to solve
all of these possible dysfunctions, though. We just need to help this
one particular case.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

Re: Agile vs. Creativity

2009-11-17T05:05:34Z

Cindy,

You say "sometimes the result was still not satisfying." It would help
me if you would elaborate on this a little. Not satisfying to whom?
Not satisfying in what way? What did you see and hear that leads you to
say it was not satisfying?

- George

Cindy Lu wrote:

>
>
> Tim,
>
> I was thinking the visual design is part of the architecture work.
>
> Anyway, the symptom we have is a lot of discussions on visual designs,
> sometimes the result was still not satisfying. I tried to figure our a
> way to make it better.
>
> - Cindy
>
> ------------------------------------------------------------------------
> *From:* Tim Wright <sambo.shacklock@...>
> *To:* agile-usability@...
> *Sent:* Sun, November 15, 2009 4:56:02 PM
> *Subject:* Re: [agile-usability] Agile vs. Creativity
>
>
>
>
> Larry Constantine wrote something a week or so ago on a different
> conversation in this mailing list (about Neilson's agile user experiance
> alertbox):
>
> > I had looked at the earlier report, and the follow-up nicely
> reinforces and refines the
> > findings. It is gratifying to find Jakob concluding what Lucy and I
> have been preaching
> > for the last 7-8 years, particularly about the importance of a
> coherent UI architecture
> > worked out in advance.
>
> Perhaps what Cindy is noticing here is a symptom of not doing the
> upfront architectural work?
>
> Tim
> On Mon, Nov 16, 2009 at 10:46 AM, George Dinwiddie <lists@idiacomputing
> .com <mailto:lists@...>> wrote:
>
>
>
> Hi, Cindy,
>
> I remember what you wrote the first time. That doesn't answer my
> questions, though. Should I repeat them?
>
>
>
> Is it the designer who's making the decision as to what's a better
> design? Or is it the stakeholder? Or do each of these people think
> /they/ are the one?
>
> It sounds to me like the designer wants to create a final work before
> getting the opinion of the stakeholder. Doesn't that disenfranchise the
> stakeholder?
>
> By the way, when I said, "What would happen if a designer and a
> stakeholder sat down together, so they could discuss what's liked, and
> not liked, about a design /as it's being sketched/?" I really meant
> that. Not "putting key points on the paper and review them with
> stakeholders." I mean sitting down together and working on it together.
>
> - George
>
>
> Cindy Lu wrote:
> >
> >
> > Hi! John and Gorge,
> >
> > I would like to go back to the original issues we started with:
> >
> > We found two issues for some design projects:
> > 1. The number of iterations becomes endless (almost)
> > 2. At the end, the final design is still not very satisfying
> >
> > I would like to understand if you have similar problems or in
> your team,
> > quick iterations work very well in the graphic design area.
> >
> > My observation is that some creative people need some time alone
> to do
> > the creation. For some people, this time period maybe longer.
> >
> > - Cindy
> >
> > ------------ --------- --------- --------- --------- --------- -
> > *From:* John Schrag <john@schrag. ca <mailto:john%40schrag.ca>>
> > *To:* agile-usability@ yahoogroups. com
> <mailto:agile-usability%40yahoogroups.com>
> > *Sent:* Sat, November 14, 2009 6:58:11 PM
> > *Subject:* Re: [agile-usability] Agile vs. Creativity
> >
> >
> >
> > It wasn't clear from your note --- Are goals set at the beginning
> of the
> > design process? Because I think any design (interaction or
> graphic) can
> > be tweaked and refined until the end of time, unless you set
> yourself
> > some ending conditions. I'm not qualified to speak for graphic
> design,
> > but for interaction design we try to set specific measurable
> goals (the
> > user can find the feature in X amount of time without consulting the
> > help; she can use it successfully to achieve her goals, etc) and we
> > stop refining once the design has hit those goals. There is a
> > temptation to keep improving the design, but time you spend doing
> that
> > is time you are taking away from other things that need your
> attention.
> >
> > I think having a design brief implies having goals, so it is a
> good thing.
> >
> > In many disciplines, the design process starts with ideation --
> > generating lots of ideas very quickly but not developing them --
> then
> > moves on to winnow the ideas down to a few good ones, and develop
> the
> > few good ones further. I think this is valid for interface design as
> > well. The only question then is your time budget for each of these
> > activities. I will generally spend an hour or two coming up with a
> > dozen or so quick interface skeches for a new feature, before
> picking
> > the most likely one and developing it into something more complete.
> > Another trick is having a good review process, with the review
> > focussing on the right level of critique. If you are presenting
> the UI
> > general layout, and someone is complaining about the fonts and
> colours,
> > then they need some coaching on being in a design review.
>

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

Re: Agile vs. Creativity

2009-11-16T21:44:09Z

On Mon, Nov 16, 2009 at 6:27 PM, George Dinwiddie
<lists@...>wrote:

>
>
> chris chandler wrote:
> > Interesting!
> >
> > Your comment gives me a vison of the PO sitting down next to the visual
> > designer and saying "move that a little to the left, no, no it's too
> > big, can you punch up that yellow, oh, now it's too bright etc etc, hey
> > just for kicks lets try comic sans as the body copy font, whaddya say?"
> > I don't think this can be what you mean, because no one in their right
> > mind would wish something like this on any team, but that is what your
> > comment suggests to me.
>
> Interesting! You just suggested that I'm not in my right mind.
>
>

Well, that's certainly possible, but I'm pretty sure the scenario I laid out
is not what you are suggesting, so the jury's still out.

> Why would you imagine the graphic designer being just a pair of hands on
> the computer while the PO creates the graphic design? Do you really
> think so little of Product Owners? Do you really think so little of
> graphic designers?
>

You say they should collaborate over sketches, I went to great length to
discuss how a visual designer works (in photoshop). At this point I'm sure I
don't understand what you are suggesting -- how would the conversation go in
your world??

-cc

Re: Agile vs. Creativity

2009-11-16T20:28:52Z

On Nov 16, 2009, at 8:46 PM, George Dinwiddie wrote:

> Larry Constantine wrote:
>> Another issue raised in this thread that I would like to weigh in on is
>> the matter of working style and collaboration. The bottom line is that
>> different people have different preferred ways of working and perform
>> better in different settings. Many people, who are good team players and
>> are highly committed to collaboration, nevertheless work best by
>> alternating relatively brief collaborative problem solving with more
>> extended independent work.
>
> Does it do anyone any good to make the time and amount of work larger
> between rejections by the stakeholder?

Yes. The amount of time and the amount of work do not necessarily correlate. This is especially true with visual design. More time spent on design produces more quality and not more product.

I'll use my hours as an example. If I am working on one complex widget, and I have completed the sketching, IA, and general interaction design, I can create a competent visual design for the one widget in one to three hours. However, to create a solid, really good visual design, it takes nine hours.

Three times as much time creates the same amount of work, but with vastly different levels of quality.

Does engineering experience the same kind of multiplying effect? (In my experience, I can recall model design seeing that kind of boost in quality.)

--
Austin Govella
User Experience

Work: http://www.grafofini.com
Blog: http://www.thinkingandmaking.com
Book: http://www.blueprintsfortheweb.com

austin@...
215-240-1265

Volunteer moderators needed

2009-11-16T19:21:15Z

Hi! It looks like the list could use another volunteer moderator or two,
especially given that the busy holiday season is coming up.

What is required of you? Three things:

* approve new members
* approve first posts from new users
* sort out occasional minor issues

This generally doesn't take more than a few minutes a day between all of
us, so it's not a big burden. As long as you check your email regularly,
have a keen eye for detail, and have a deep interest in both the topic
and civilized behavior, you'll be fine.

If you're interested, drop me a line off list.

Thanks,

William

Re: Agile vs. Creativity

2009-11-16T19:05:35Z

George Dinwiddie wrote:
> Why would you imagine the graphic designer being just a pair of hands on
> the computer while the PO creates the graphic design? Do you really
> think so little of Product Owners? Do you really think so little of
> graphic designers?
>

To be fair, a lot of novice product owners do mistake themselves for
bosses, so back-seat driving is regrettably common. And visual design is
one of those areas where quite a lot of people think their opinion is
just as good as a professional's.[1] So Chris may be imagining that
relationship because that's mainly what he sees.

Personally, when there are big differences of opinion, I like to see
visual designs evaluated a) by other visual design experts, and b) via
actual data. And similarly for almost any other field of expertise. But
generally, I think Agile teams work best when people trust each other to
handle their fields.

William

[1] Due, I think, to the Dunning-Kruger effect:
http://en.wikipedia.org/wiki/Dunning-Kruger_effect

Re: Agile vs. Creativity

2009-11-16T18:46:27Z

Larry Constantine wrote:

> Austin and Ron put their fingers on a central issue about interactions
> among team members with various specialties and between specialists and
> the stakeholders and decision makers. There is often a rather dramatic
> asymmetry in the presumptions of the various parties about their
> knowledge and abilities in each others domains. Nearly everyone in the
> world thinks that they understand and can do interaction design and in
> many cases are convinced that their opinions are valid, correct, and
> indeed override those of the designer. It can be even worse when it
> comes to graphic design, because the vast majority of people think that
> their notion of what is attractive and appealing is right. Such
> assumptions are much less common regarding programming. Few managers or
> marketing professionals would presume to comment on the structure or
> details of C++ code, but most will not only comment but argue that they
> are right about usability and aesthetics.

Yes, this can be a problem. And it's not just limited to interface
design. I've seen it applied to programmers, too.

Trying to present the unsatisfied stakeholder with a /fait accompli/ to
get one's expertise recognized doesn't seem to work, in my experience.
Learning how to communicate with said stakeholder and understand their
true concerns (demonstrating one's fluency in the design space in the
process), seems more likely to solve such an impasse.

> Both stakeholders and team members need to trust each others skills,
> competence, and expertise. If you don’t trust that your designers know
> more about design than you, there is something wrong.

Yes, that's true. It's also true that the "unskilled" who are paying
attention often notice important things and ask useful questions. I've
found this true in programming.

> The relationship with stakeholders and decision makers is complicated by
> the fact that, ultimately, they call the shots. As a consulting
> designer, I can only advise, not dictate, so if a decision maker tells
> me it has to be such-and-such a way that is clearly wrong or
> wrong-headed, I can only present my case and arguments and evidence as
> best as I can, making clear if the decision is being made over my
> objections and best judgment. As a rule, whoever pays picks the tune.

Yes, and they may have different objectives than the graphic designer.

> Another issue raised in this thread that I would like to weigh in on is
> the matter of working style and collaboration. The bottom line is that
> different people have different preferred ways of working and perform
> better in different settings. Many people, who are good team players and
> are highly committed to collaboration, nevertheless work best by
> alternating relatively brief collaborative problem solving with more
> extended independent work.

Does it do anyone any good to make the time and amount of work larger
between rejections by the stakeholder?

> I have found this to be particularly true of
> graphic artists. A successful graphic design is about gestalts—such as,
> balance, space, flow, and the like—but also about exceedingly fine
> details, such as the exact shade and shape of a green highlight or the
> way a gradient suggests dimensionality or how a color has to be subtly
> altered when against a particular background to maintain the impression
> of unity. In combination, such seeming minutiae can have an enormous
> impact on the overall impact on users and consumers. These are not the
> sort of things that are best worked out through interactive sketching
> with stakeholders.

Could not the designer describe these effects, and the vision, while
sketching?

> It is actually not much different with programmers on agile projects.
> After the user story has been worked out, the programmers go do their
> thing, whether in pairs or individually, and return with the next
> version of the build. They do not typically sit in the room with the
> marketing and sales people and cut code collaboratively with the
> stakeholders.

I've seen this, where the "next version of the build" was available in
hours, not days. And I've seen it where the programmer sat with the
Product Owner, or with the designer, and worked out issues and alternatives.

> In every area, there are limits to what you can and
> should reasonably do with or in the presence of stakeholders.

I'm hearing, in these conversations, a lack of trust about the judgment
and understanding of the stakeholders. I've certainly seen cases of
heavy-handed meddling, and can understand the fear. I've also seen that
they are generally well-meaning people, also, and that building bridges
of understanding works in both directions.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/agile-usability/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/agile-usability/join
(Yahoo! ID required)

<*> To change settings via email:
agile-usability-digest@...
agile-usability-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
agile-usability-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Re: Agile vs. Creativity

2009-11-16T18:36:21Z

Hello, Scott. On Monday, November 16, 2009, at 9:09:49 PM, you
wrote:

> Any designer "might" be more valuable than any other designer.
> This is more vague than you usually are. Are you suggesting that
> there is value specifically in "not needing to work in longer
> isolation periods", regardless of the quality of what is
> eventually produced or the number of iterations required to get to acceptance?

Of course not. That would be stupid.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
I'm not bad, I'm just drawn that way. -- Jessica Rabbit

Re: Agile vs. Creativity

2009-11-16T18:27:11Z

chris chandler wrote:
> Interesting!
>
> Your comment gives me a vison of the PO sitting down next to the visual
> designer and saying "move that a little to the left, no, no it's too
> big, can you punch up that yellow, oh, now it's too bright etc etc, hey
> just for kicks lets try comic sans as the body copy font, whaddya say?"
> I don't think this can be what you mean, because no one in their right
> mind would wish something like this on any team, but that is what your
> comment suggests to me.

Interesting! You just suggested that I'm not in my right mind.

Why would you imagine the graphic designer being just a pair of hands on
the computer while the PO creates the graphic design? Do you really
think so little of Product Owners? Do you really think so little of
graphic designers?

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------