Nabble - Agile Usability

Agile/UX Wave

2009-11-06T14:24:31Z

For those of you on wave who might want a reason to use it. I've created a
public wave for agile/ux. Search for 'with:public agile ux'

-jer

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

RE: Nielsen on Agile User Experience

2009-11-06T07:42:09Z

I'm quite interested into that one. If anyone figure out a link to the
presentation I will greatly appreciate.

Cheers,

Eric.

From: agile-usability@...
[mailto:agile-usability@...] On Behalf Of Paul Sherman
Sent: 4 novembre 2009 15:28
To: agile-usability@...
Subject: Re: [agile-usability] Nielsen on Agile User Experience

I just wanted to point the group to another excellent resource for
managing & executing design within an Agile environment.

The presentation is by my former coworkers Amy Kargen and Casandra
Swint. The presentation from UPA 2009 is titled "Life in the Fast Lane:
Merging Interaction Design onto the Agile Superhighway".

I can't find the presentation on the interwebz but I'll ping them to
share it with the group.

Regards,

Paul Sherman

On Nov 4, 2009, at 12:57 PM, Larry Constantine wrote:

William,

Thanks for the reminder. 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.

--Larry Constantine, IDSA, ACM Fellow
Professor | Department of Mathematics and Engineering
University of Madeira | Funchal, Portugal
Director | Laboratory for Usage-centered Software Engineering |
www.LabUSE.org
Chief Scientist, Constantine & Lockwood Ltd
58 Kathleen Circle | Rowley, MA 01969
tel: +1 978.948.5012 | fax: +1 978 948 5036

________________________________

From: agile-usability@...
[mailto:agile-usability@...] On Behalf Of William Pietri
Sent: Wednesday, November 04, 2009 12:40 PM
To: agile-usability@...
Subject: [agile-usability] Nielsen on Agile User Experience

I thought folks here would be interested in this:

http://www.useit.com/alertbox/agile-user-experience.html

William

[JOB] - user experience designer - in lovely London, England

2009-11-06T04:42:40Z

Hello! Elizabeth here I'm the product manager at JustGiving, a
fantastic place to work in London. We're looking for a new user
experience designer to join our team if you're interested drop
me a line at Elizabeth@... <mailto:Elizabeth@...>
. Job spec below.

No agents or applicants who aren't eligible to work in the UK
please.

User Experience Designer

JustGiving, the UK's leading online fundraising platform, is seeking
a creative, collaborative and passionate Senior User Experience designer
to join our growing product development team in central London.

All candidates must provide a portfolio of work and be able to
demonstrate a strong work ethic, an eye for detail, excellent
communication skills, and the ability to adapt, prioritize, and
multitask. You must be well organized and delivery oriented.

What it's like to work here
Well, we think JustGiving is a very interesting place to work. We have a
pretty flat structure, with people working in multi-disciplinary project
teams to get things done. Everyone who works here has a voice and a
stake in the business. We have unusual investors, who believe in growing
companies in a balanced, sustainable way (they have yet to take a penny
out of the business).

Purpose
You will help build great products for the JustGiving website

About the role
You will work directly with other designers, developers and program
managers to identify, conceptualise and realise products and features
which are simple, engaging and a delight to use.

You will:

* Put the user at the centre of everything you do
* Create product prototypes at different levels of fidelity:
paper and digital wireframes
* Develop and maintain user personas
* Build detailed functional specifications for product
prototypes
* Engage with business and development stakeholders on ongoing
projects
* Research, test and validate designs and prototypes with
stakeholders and users

About you

· You will have worked alongside other UX designers in the
past and will be have experience of operating in a highly collaborative
environment.
· You have 2-3 years of experience, including user research,
usability testing, information architecture and interaction design

· You've got experience quickly producing elegant and
easily understood diagrams, wireframes, and other artifacts both on
paper and using a tool such as Axure.

· You've had extensive experience of usability testing

· You've had exposure to and understanding of variety of
design and development processes and methodologies

· You've got experience creating and managing UI pattern
libraries and interaction guidelines

· You have excellent written and verbal communications skills

· You need strong organizational skills and attention to
detail

Salary
Competitive market rates, based on experience.

Re: Re: New to the challenge of Agile Usability. Looking for good ideas.

2009-11-05T18:11:47Z

In that case, I'd suggest:

Don't do the wateration thing. I see people struggle pretty hard with
that in a 4-week iteration, and I've never seen it work in a 2-week or
1-week iteration.

Instead, I think you should switch from thinking of it as a "push"
system to a "pull" system.

Waterfall is very push-oriented. There's a giant idea that gets
analyzed, broken down into a giant plan, and crammed into the production
system, generally with a lot of pain.

But the best Agile teams I see instead start with the production team,
which builds a consistent amount of work every iteration. Then they say,
"How can we be ready to keep them working at maximum efficiency?" The
team pulls what it needs from the rest of the organization, a bit at a time.

As you say, that involves having a broad but shallow product backlog, so
when we ask, "What's the most important thing they could release this
iteration?" we have some confidence that we know.

Then for the thing the team takes on this iteration, product managers
need to be ready to answer any question that comes up without delay, as
do the people with "design" in their titles. That generally means some
pre-iteration prep work. The right amount varies by product and by team,
but the shorter your iterations, the more quickly everybody will learn
what the right local approaches are.

Personally, I think Sprint Zero is unnecessary, a luxury. If your
organization has taken months to think about a project before pulling
the trigger, then I'd bet people know enough to select an iteration's
worth of work without too much risk. Certainly I've never seen a project
where I couldn't shake out a week's work. But if you need a little
waterfall hair-of-the-dog to get going, I doubt it will do much harm.

Regarding your multiple-project issue, I recommend one work queue per
team. So if it's truly one team, then all work requests for them go in
the same stream and count toward the same velocity number.

Hoping that helps,

William

gh900 wrote:

> William
>
> Iterations are currently two weeks long.
>
> "thinking time" is generally in months.
>
> Designers do sit with developers.
>
> Hope that clarifies it a little.
>
> Gareth
>
>
> --- In agile-usability@..., William Pietri <william@...> wrote:
>
>> Hi, Gh900. Your question is a good one, but broad enough that it's hard
>> to answer easily. To narrow things down, a few questions:
>>
>> How long are your iterations?
>>
>> How long, typically, is the period where your organization is thinking
>> about funding a project, but hasn't actually committed to it yet?
>>
>> Do designers sit with developers?
>>
>>
>> Thanks,
>>
>> William
>>
>>
>> gh900 wrote:
>>
>>> I'm new to this organisation, and starting to bring in some Scrum practices. There's been a tradition of wireframing and sign-off before development starting here which I want to get away from (at least all up front!) so we can start delivering value faster.
>>>
>>> I know there's going to have to be some compromise to get this working, but I'm not sure whether a "wateration", as suggested in some quarters, is the best one. I can see IA/design taking place in the first half of the sprint and development in the second half. Even if we then re-work things next sprint, it's getting away from stories being done done at the end of a sprint. I can't really see this working.
>>>
>>> All I can come up with is some combination of the following: Get the Product Backlog in shape with all high priority stories broken down into small chunks and ready for development. Being ready should mean any IA/UCD work is complete at a story/backlog item level - maybe this can be done on a separate cycle, or one sprint in advance ? Do a Sprint Zero for new projects to set overall goals and vision, and allow time for high-level IA (and some systems architecture) to be done. More collaboration between IA, the SME and development - start working as more of a Scrum team.
>>>
>>> Anything else seems to go against the Scrum grain. I'm not the kind of person that would blindly adhere to a method, but I don't want to get too far away from the ideal either.
>>>
>>> Any good suggestions welcome. Oh, and just to complicate matters further, as well as working on multiple products, the (small) team also has to support and maintain existing applications...
>>>
>>>
>>>
>>> ------------------------------------
>>>
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

Re: Beta Testing For Usability?

2009-11-05T17:17:16Z

Thanks, Kaleb. I've recently found some great articles on A/B testing and it's use in product and usability development.

This was an excellent one: http://blog.mixpanel.com/ab-testing-to-increase-user-engagement

I definitely think we'll try this approach.

--- In agile-usability@..., Kaleb Pederson <kaleb.pederson@...> wrote:

>
> On Mon, Nov 2, 2009 at 12:58 PM, doug.gorman@...
> <doug.gorman@...> wrote:
> > Hello, everyone!
> >
> > We're about to roll out a few applications to a beta test group and I was wondering what techniques you've all used to get useful feedback about usability during beta test phases.
>
> Nice question.
>
> > Have you used other approaches or techniques during betas to get great "real world" feedback on usability? What techniques had the highest yield?
>
> Depending on the type of application, a true real-world indicator of
> the effectiveness of various UI changes would be to A/B test them
> (http://en.wikipedia.org/wiki/A/B_testing). Assuming you're working
> with a web application, you should be able to send a certain
> percentage of users (possibly pre-screened and filtered) through the
> beta page(s) to determine the overall affect on the target metrics. If
> a single change positively effects the target metrics, like conversion
> or lead generation, then it's probably a good change and likely makes
> the application more usable.
>
> --
> Kaleb Pederson
>
> Blog - http://kalebpederson.com
> Twitter - http://twitter.com/kalebpederson
>

Re: Nielsen on Agile User Experience

2009-11-04T12:27:52Z

I just wanted to point the group to another excellent resource for
managing & executing design within an Agile environment.

The presentation is by my former coworkers Amy Kargen and Casandra
Swint. The presentation from UPA 2009 is titled "Life in the Fast
Lane: Merging Interaction Design onto the Agile Superhighway".

I can't find the presentation on the interwebz but I'll ping them to
share it with the group.

Regards,
Paul Sherman

On Nov 4, 2009, at 12:57 PM, Larry Constantine wrote:

William,

Thanks for the reminder. 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.

--Larry Constantine, IDSA, ACM Fellow
Professor | Department of Mathematics and Engineering
University of Madeira | Funchal, Portugal
Director | Laboratory for Usage-centered Software Engineering | www.LabUSE.org
Chief Scientist, Constantine & Lockwood Ltd
58 Kathleen Circle | Rowley, MA 01969
tel: +1 978.948.5012 | fax: +1 978 948 5036

From: agile-usability@... [mailto:agile-
usability@...] On Behalf Of William Pietri
Sent: Wednesday, November 04, 2009 12:40 PM
To: agile-usability@...
Subject: [agile-usability] Nielsen on Agile User Experience

I thought folks here would be interested in this:

http://www.useit.com/alertbox/agile-user-experience.html

William

Re: Re: Designing toggle icon

2009-11-04T11:41:54Z

Perhaps the problem is that you're trying to use one widget to convey two
pieces of information - state and action. Something like this might be
better:

You are watching this page. *Stop watching*.

Tim

On Sat, Oct 31, 2009 at 8:48 AM, scott preece <sepreece@...> wrote:

>
>
> Or, use an icon to show state and just use a popup dialog to indicate what
> happened as a result of clicking it (e.g., "Now watching page"). For a
> non-destructive operation like this, that should be OK. I would prefer a
> timed dialog or one that would go away as soon as you move your mouse away
> from the button, rather than requiring an extra click.
>
> Alternatively, you could use a mouseover popup to indicate what the action
> associated with the button is.
>
> scott
>
> --- In agile-usability@... <agile-usability%40yahoogroups.com>,
> "Larry Constantine" <lconstantine@...> wrote:
>
> >
> > Alain said:
> >
> >
> >
> > One idea I had was the following...
> >
> > Use the icon to convey state, since people seem to agree more on what
> > state an icon refers to than on what action will result from pushing it.
> > For example, eye with green check for "on" and an eye with a red X for
> > "off".
> >
> > To convey action, use a popup menu. When the user clicks on the icon, he
> > would see a popup menu with the following two items:
> >
> > - On
> > - Off
> >
> > And there would be a checkmark in front of the one that corresponds to
> > the current state.
> >
> > A bit complex, but might work.
> >
> >
> >
> >
> >
> > Yes, complex. Okay, if you must have it as a tool and have limited real
> estate, I would go
> > with the toggle button, suggestion (a), or another weirder but still
> effective hybrid that
> > I have used on occasion: the check button.
> >
> >
> >
> > In attached image are concept mockups of the 2 designs, the straight
> toggle button and the
> > check button shown in off (left) and on (right) states. The latter is the
> least ambiguous,
> > but both rely on instructive interaction, that is, the user knows how
> they work after
> > using (clicking) once.
> >
> >
> >
> > Good luck!
>
> >
> >
> >
> > --Larry Constantine
> >
> >
> >
> >
> >
> > _____
> >
> > From: agile-usability@...<agile-usability%40yahoogroups.com>[mailto:
> agile-usability@... <agile-usability%40yahoogroups.com>] On
> Behalf
> > Of Desilets, Alain
> > Sent: Friday, October 30, 2009 1:05 PM
>
> > To: agile-usability@... <agile-usability%40yahoogroups.com>
> > Subject: RE: [agile-usability] Designing toggle icon
>
> >
> >
> >
> >
> >
> > > Indeed, this is a generic problem for which there is no single best
> > solution. It depends. But my own research shows
> > > that people who interpret the label on a toggle button to mean the
> > command to be executed (rather than the current
> > > state) are in the majority. However, labels on function buttons that
> > change are problematic in any case. (Although, I
> > > have used them on rare and carefully reasoned occasion.)
> >
> > Thx for answering Larry. Nice to get advice from a guru ;-).
> >
> > The wiki engine in question (TikiWiki) currently uses that approach
> > (icon on the button suggests the action that will happen when you click
> > on it). But we are seeing that a good 50% of users are confused by it
> > and interpret it in terms of state.
> >
> > When I tested the 8 icons in my previous email with 12 subjects or so, I
> > asked half of them what the icon suggested in terms of state, and asked
> > the other half what it suggested in terms of the action that would
> > happen.
> >
> > I found that when people described their understanding of the state,
> > they were unanimous. But those who were asked to describe what action
> > would happen tended to split 50-50 between turn off and turn on.
> >
> > This may be tied to the specific icons I tested, but it might be a hint
> > that it's easier to clearly convey a state than an action.
> >
> > This seems to argue for using the icon to convey state, not action...
> > dunno.
> >
> > > Here are the options that my work suggests work best, on average (your
> > mileage may vary):
> > >
> > > (a) have a button with an unchanging label (the on-state) that appears
> > depressed (or on) when selected
> >
> > So, an eye button that appears depressed or not. Sounds like a good
> > idea.
> >
> > Can you provide an example of what such a button looks like?
> >
> > > (b) have two buttons (watches on, watches off) linked visually and in
> > behavior
> >
> > Hum... don't like that. The reason we are going with icons is that we
> > have a real estate crunch.
> >
> > > (c) use a check box (e.g., [ ] Watches on)
> > > On a Wiki, I would favor the latter as more in keeping with the
> > Web-based interface; and it's simpler.
> >
> > Unfortunately, that button is part of a toolbar that's all made up of
> > icons, so I want to keep it that way for consistency.
> >
> > One idea I had was the following...
> >
> > Use the icon to convey state, since people seem to agree more on what
> > state an icon refers to than on what action will result from pushing it.
> > For example, eye with green check for "on" and an eye with a red X for
> > "off".
> >
> > To convey action, use a popup menu. When the user clicks on the icon, he
> > would see a popup menu with the following two items:
> >
> > - On
> > - Off
> >
> > And there would be a checkmark in front of the one that corresponds to
> > the current state.
> >
> > A bit complex, but might work. I like the depressed button idea too.
> >
>
>
>

RE: Nielsen on Agile User Experience

2009-11-04T10:56:54Z

William,

Thanks for the reminder. 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.

--Larry Constantine, IDSA, ACM Fellow
Professor | Department of Mathematics and Engineering
University of Madeira | Funchal, Portugal
Director | Laboratory for Usage-centered Software Engineering | www.LabUSE.org
Chief Scientist, Constantine & Lockwood Ltd
58 Kathleen Circle | Rowley, MA 01969
tel: +1 978.948.5012 | fax: +1 978 948 5036

_____

From: agile-usability@... [mailto:agile-usability@...] On Behalf
Of William Pietri
Sent: Wednesday, November 04, 2009 12:40 PM
To: agile-usability@...
Subject: [agile-usability] Nielsen on Agile User Experience

I thought folks here would be interested in this:

http://www.useit. <http://www.useit.com/alertbox/agile-user-experience.html>
com/alertbox/agile-user-experience.html

William

Nielsen on Agile User Experience

2009-11-04T09:40:27Z

I thought folks here would be interested in this:

http://www.useit.com/alertbox/agile-user-experience.html

William

Re: New to the challenge of Agile Usability. Looking for good ideas.

2009-11-04T06:24:06Z

William

Iterations are currently two weeks long.

"thinking time" is generally in months.

Designers do sit with developers.

Hope that clarifies it a little.

Gareth

--- In agile-usability@..., William Pietri <william@...> wrote:

>
> Hi, Gh900. Your question is a good one, but broad enough that it's hard
> to answer easily. To narrow things down, a few questions:
>
> How long are your iterations?
>
> How long, typically, is the period where your organization is thinking
> about funding a project, but hasn't actually committed to it yet?
>
> Do designers sit with developers?
>
>
> Thanks,
>
> William
>
>
> gh900 wrote:
> > I'm new to this organisation, and starting to bring in some Scrum practices. There's been a tradition of wireframing and sign-off before development starting here which I want to get away from (at least all up front!) so we can start delivering value faster.
> >
> > I know there's going to have to be some compromise to get this working, but I'm not sure whether a "wateration", as suggested in some quarters, is the best one. I can see IA/design taking place in the first half of the sprint and development in the second half. Even if we then re-work things next sprint, it's getting away from stories being done done at the end of a sprint. I can't really see this working.
> >
> > All I can come up with is some combination of the following: Get the Product Backlog in shape with all high priority stories broken down into small chunks and ready for development. Being ready should mean any IA/UCD work is complete at a story/backlog item level - maybe this can be done on a separate cycle, or one sprint in advance ? Do a Sprint Zero for new projects to set overall goals and vision, and allow time for high-level IA (and some systems architecture) to be done. More collaboration between IA, the SME and development - start working as more of a Scrum team.
> >
> > Anything else seems to go against the Scrum grain. I'm not the kind of person that would blindly adhere to a method, but I don't want to get too far away from the ideal either.
> >
> > Any good suggestions welcome. Oh, and just to complicate matters further, as well as working on multiple products, the (small) team also has to support and maintain existing applications...
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>

Re:Beta Testing For Usability?

2009-11-03T07:07:21Z

Don't forget the very basic Feedback form or email address so that
people can spontaneously send feedback as it occurs to them. Make sure
you have a quick response to them to keep them motivated - have someone
check for feedback frequently and respond.

>>Have you used other approaches or techniques during betas to get
great "real world" feedback on usability? What techniques had the
highest yield?

Lyn Bain
Chili Interactive

Re: Beta Testing For Usability?

2009-11-03T01:52:25Z

Hi,

I've seen that a free form forum can also help to find solutions.

For example, someone is having trouble with new feature and asks for help. That often leads to a discussion with multiple solutions to problem and brings several opinions and related issues to table at once.
Other than that, your list seems to be quite comprehensive.

Petteri

--- In agile-usability@..., "doug.gorman@..." <doug.gorman@...> wrote:

>
> Hello, everyone!
>
> We're about to roll out a few applications to a beta test group and I was wondering what techniques you've all used to get useful feedback about usability during beta test phases.
>
> My current plan is:
>
> 1. Interview testers before they get the beta release. The purposes of this interview are to level set about what the testers expect the application will do for them, what they are currently using to fill the gap (internet sites, etc), and what they hope the beta application does not do.
>
> 2. Weekly polling to see how well or not the beta is living up to expectations for each tester.
>
> 3. Weekly ethnographical studies with select testers (preferrably those who seem frustrated with the application).
>
> 4. Bi-weekly publishing of test results with recommendations for how to proceed on issues found.
>
> Have you used other approaches or techniques during betas to get great "real world" feedback on usability? What techniques had the highest yield?
>

Re: Beta Testing For Usability?

2009-11-02T14:26:05Z

On Mon, Nov 2, 2009 at 12:58 PM, doug.gorman@...
<doug.gorman@...> wrote:
> Hello, everyone!
>
> We're about to roll out a few applications to a beta test group and I was wondering what techniques you've all used to get useful feedback about usability during beta test phases.

Nice question.

> Have you used other approaches or techniques during betas to get great "real world" feedback on usability? What techniques had the highest yield?

Depending on the type of application, a true real-world indicator of
the effectiveness of various UI changes would be to A/B test them
(http://en.wikipedia.org/wiki/A/B_testing). Assuming you're working
with a web application, you should be able to send a certain
percentage of users (possibly pre-screened and filtered) through the
beta page(s) to determine the overall affect on the target metrics. If
a single change positively effects the target metrics, like conversion
or lead generation, then it's probably a good change and likely makes
the application more usable.

--
Kaleb Pederson

Blog - http://kalebpederson.com
Twitter - http://twitter.com/kalebpederson

Beta Testing For Usability?

2009-11-02T12:58:50Z

Hello, everyone!

We're about to roll out a few applications to a beta test group and I was wondering what techniques you've all used to get useful feedback about usability during beta test phases.

My current plan is:

1. Interview testers before they get the beta release. The purposes of this interview are to level set about what the testers expect the application will do for them, what they are currently using to fill the gap (internet sites, etc), and what they hope the beta application does not do.

2. Weekly polling to see how well or not the beta is living up to expectations for each tester.

3. Weekly ethnographical studies with select testers (preferrably those who seem frustrated with the application).

4. Bi-weekly publishing of test results with recommendations for how to proceed on issues found.

Have you used other approaches or techniques during betas to get great "real world" feedback on usability? What techniques had the highest yield?

Parcticipants needed for Web-based study

2009-11-01T16:23:16Z

Hi everyone,

The following information is in regards to a study being conducted at
the University of Calgary, Department of Computer Science for the
purpose of a master's thesis. The study will be conducted by Ali
Hosseini-Khayat a Masters student at the University of Calgary. For
further details and inquiries please refer to the contact details at the
end of this email.

Summary

A study is being conducted in order to evaluate the usefulness and
effectiveness of automatically collected usability data and it's
visualizations for the designer of a prototype. Usability data has been
automatically collected by a custom Wizard of Oz usability testing tool.
The collected data needs to be presented in a meaningful way to aid in
the detection of usability flaws. You will be evaluating multiple
representations and visualizations of that data.

We ask that you attempt to identify usability flaws using the different
visualizations. This is followed by a short survey. Each of the 9 study
questions should take about 2-3 minutes and the survey should take 5
minutes.

Please note that participation will in no way affect your position of
employment and that your employer will not be informed or know of your
participation or lack thereof.

Participation

If you would like to participate in this survey please direct your
browser to the following URL:

http://ciase.cpsc.ucalgary.ca/Study
<http://ciase.cpsc.ucalgary.ca/Study>

Thank you for your time.

Further details are provided below.

Motivation

This study is being conducted in order to evaluate the usefulness and
effectiveness of automatically collected usability data and it's
visualizations for the designer of a prototype. Use of low-fidelity
prototypes and testing techniques such as Wizard of Oz testing can help
enable Agile teams to perform usability testing on a limited budget and
timeline. By conducting distributed tests over the Internet some of the
overhead involved with executing usability tests is reduced. However,
the effectiveness of distributed testing in comparison to collocated
testing may also be reduced due to limited feedback from the test
participant. This thesis presents ActiveStory Enhanced, a tool that
provides designers with the ability to easily and naturally create
low-fidelity prototypes and subsequently conduct Wizard of Oz usability
tests in an automated and distributed fashion. Usability data is
collected during tests sessions (with the participant's knowledge) and
sent back to the designer to help evaluate the usability of their
interface. This study is being conducted in order to evaluate the
usefulness and effectiveness of the usability data and it's
visualizations for the designer.

Task Overview

You will be presented with 9questions that provide some form of
usability data or visualization designed to aid you in detecting a
usability flaw in a prototype. Questions consist of images, charts and
short video clips (1 min max.) The final question is a short survey
where you can rate each of the features you used.

If you have any further questions or want clarification regarding this
research and/or your participation, please contact:

Ali Hosseini-Khayat, Department of Computer Science, University of
Calgary, hosseisa {at} ucalgary.ca

or Dr. Frank Maurer, Department of Computer Science, University of
Calgary, (403)-220-5454 (403)-220-5454 , fmaurer {at} ucalgary.ca

Re: New to the challenge of Agile Usability. Looking for good ideas.

2009-10-31T10:17:10Z

Hi, Gh900. Your question is a good one, but broad enough that it's hard
to answer easily. To narrow things down, a few questions:

How long are your iterations?

How long, typically, is the period where your organization is thinking
about funding a project, but hasn't actually committed to it yet?

Do designers sit with developers?

Thanks,

William

gh900 wrote:

> I'm new to this organisation, and starting to bring in some Scrum practices. There's been a tradition of wireframing and sign-off before development starting here which I want to get away from (at least all up front!) so we can start delivering value faster.
>
> I know there's going to have to be some compromise to get this working, but I'm not sure whether a "wateration", as suggested in some quarters, is the best one. I can see IA/design taking place in the first half of the sprint and development in the second half. Even if we then re-work things next sprint, it's getting away from stories being done done at the end of a sprint. I can't really see this working.
>
> All I can come up with is some combination of the following: Get the Product Backlog in shape with all high priority stories broken down into small chunks and ready for development. Being ready should mean any IA/UCD work is complete at a story/backlog item level - maybe this can be done on a separate cycle, or one sprint in advance ? Do a Sprint Zero for new projects to set overall goals and vision, and allow time for high-level IA (and some systems architecture) to be done. More collaboration between IA, the SME and development - start working as more of a Scrum team.
>
> Anything else seems to go against the Scrum grain. I'm not the kind of person that would blindly adhere to a method, but I don't want to get too far away from the ideal either.
>
> Any good suggestions welcome. Oh, and just to complicate matters further, as well as working on multiple products, the (small) team also has to support and maintain existing applications...
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

Re: Designing toggle icon

2009-10-30T12:48:16Z

Or, use an icon to show state and just use a popup dialog to indicate what happened as a result of clicking it (e.g., "Now watching page"). For a non-destructive operation like this, that should be OK. I would prefer a timed dialog or one that would go away as soon as you move your mouse away from the button, rather than requiring an extra click.

Alternatively, you could use a mouseover popup to indicate what the action associated with the button is.

scott

--- In agile-usability@..., "Larry Constantine" <lconstantine@...> wrote:

>
> Alain said:
>
>
>
> One idea I had was the following...
>
> Use the icon to convey state, since people seem to agree more on what
> state an icon refers to than on what action will result from pushing it.
> For example, eye with green check for "on" and an eye with a red X for
> "off".
>
> To convey action, use a popup menu. When the user clicks on the icon, he
> would see a popup menu with the following two items:
>
> - On
> - Off
>
> And there would be a checkmark in front of the one that corresponds to
> the current state.
>
> A bit complex, but might work.
>
>
>
>
>
> Yes, complex. Okay, if you must have it as a tool and have limited real estate, I would go
> with the toggle button, suggestion (a), or another weirder but still effective hybrid that
> I have used on occasion: the check button.
>
>
>
> In attached image are concept mockups of the 2 designs, the straight toggle button and the
> check button shown in off (left) and on (right) states. The latter is the least ambiguous,
> but both rely on instructive interaction, that is, the user knows how they work after
> using (clicking) once.
>
>
>
> Good luck!
>
>
>
> --Larry Constantine
>
>
>
>
>
> _____
>
> From: agile-usability@... [mailto:agile-usability@...] On Behalf
> Of Desilets, Alain
> Sent: Friday, October 30, 2009 1:05 PM
> To: agile-usability@...
> Subject: RE: [agile-usability] Designing toggle icon
>
>
>
>
>
> > Indeed, this is a generic problem for which there is no single best
> solution. It depends. But my own research shows
> > that people who interpret the label on a toggle button to mean the
> command to be executed (rather than the current
> > state) are in the majority. However, labels on function buttons that
> change are problematic in any case. (Although, I
> > have used them on rare and carefully reasoned occasion.)
>
> Thx for answering Larry. Nice to get advice from a guru ;-).
>
> The wiki engine in question (TikiWiki) currently uses that approach
> (icon on the button suggests the action that will happen when you click
> on it). But we are seeing that a good 50% of users are confused by it
> and interpret it in terms of state.
>
> When I tested the 8 icons in my previous email with 12 subjects or so, I
> asked half of them what the icon suggested in terms of state, and asked
> the other half what it suggested in terms of the action that would
> happen.
>
> I found that when people described their understanding of the state,
> they were unanimous. But those who were asked to describe what action
> would happen tended to split 50-50 between turn off and turn on.
>
> This may be tied to the specific icons I tested, but it might be a hint
> that it's easier to clearly convey a state than an action.
>
> This seems to argue for using the icon to convey state, not action...
> dunno.
>
> > Here are the options that my work suggests work best, on average (your
> mileage may vary):
> >
> > (a) have a button with an unchanging label (the on-state) that appears
> depressed (or on) when selected
>
> So, an eye button that appears depressed or not. Sounds like a good
> idea.
>
> Can you provide an example of what such a button looks like?
>
> > (b) have two buttons (watches on, watches off) linked visually and in
> behavior
>
> Hum... don't like that. The reason we are going with icons is that we
> have a real estate crunch.
>
> > (c) use a check box (e.g., [ ] Watches on)
> > On a Wiki, I would favor the latter as more in keeping with the
> Web-based interface; and it's simpler.
>
> Unfortunately, that button is part of a toolbar that's all made up of
> icons, so I want to keep it that way for consistency.
>
> One idea I had was the following...
>
> Use the icon to convey state, since people seem to agree more on what
> state an icon refers to than on what action will result from pushing it.
> For example, eye with green check for "on" and an eye with a red X for
> "off".
>
> To convey action, use a popup menu. When the user clicks on the icon, he
> would see a popup menu with the following two items:
>
> - On
> - Off
>
> And there would be a checkmark in front of the one that corresponds to
> the current state.
>
> A bit complex, but might work. I like the depressed button idea too.
>

RE: Designing toggle icon [1 Attachment]

2009-10-30T12:31:56Z

Alain said:

One idea I had was the following...

Use the icon to convey state, since people seem to agree more on what
state an icon refers to than on what action will result from pushing it.
For example, eye with green check for "on" and an eye with a red X for
"off".

To convey action, use a popup menu. When the user clicks on the icon, he
would see a popup menu with the following two items:

- On
- Off

And there would be a checkmark in front of the one that corresponds to
the current state.

A bit complex, but might work.

Yes, complex. Okay, if you must have it as a tool and have limited real estate, I would go
with the toggle button, suggestion (a), or another weirder but still effective hybrid that
I have used on occasion: the check button.

In attached image are concept mockups of the 2 designs, the straight toggle button and the
check button shown in off (left) and on (right) states. The latter is the least ambiguous,
but both rely on instructive interaction, that is, the user knows how they work after
using (clicking) once.

Good luck!

--Larry Constantine

_____

From: agile-usability@... [mailto:agile-usability@...] On Behalf
Of Desilets, Alain
Sent: Friday, October 30, 2009 1:05 PM
To: agile-usability@...
Subject: RE: [agile-usability] Designing toggle icon

> Indeed, this is a generic problem for which there is no single best
solution. It depends. But my own research shows
> that people who interpret the label on a toggle button to mean the
command to be executed (rather than the current
> state) are in the majority. However, labels on function buttons that
change are problematic in any case. (Although, I
> have used them on rare and carefully reasoned occasion.)

Thx for answering Larry. Nice to get advice from a guru ;-).

The wiki engine in question (TikiWiki) currently uses that approach
(icon on the button suggests the action that will happen when you click
on it). But we are seeing that a good 50% of users are confused by it
and interpret it in terms of state.

When I tested the 8 icons in my previous email with 12 subjects or so, I
asked half of them what the icon suggested in terms of state, and asked
the other half what it suggested in terms of the action that would
happen.

I found that when people described their understanding of the state,
they were unanimous. But those who were asked to describe what action
would happen tended to split 50-50 between turn off and turn on.

This may be tied to the specific icons I tested, but it might be a hint
that it's easier to clearly convey a state than an action.

This seems to argue for using the icon to convey state, not action...
dunno.

> Here are the options that my work suggests work best, on average (your
mileage may vary):
>
> (a) have a button with an unchanging label (the on-state) that appears
depressed (or on) when selected

So, an eye button that appears depressed or not. Sounds like a good
idea.

Can you provide an example of what such a button looks like?

> (b) have two buttons (watches on, watches off) linked visually and in
behavior

Hum... don't like that. The reason we are going with icons is that we
have a real estate crunch.

> (c) use a check box (e.g., [ ] Watches on)
> On a Wiki, I would favor the latter as more in keeping with the
Web-based interface; and it's simpler.

Unfortunately, that button is part of a toolbar that's all made up of
icons, so I want to keep it that way for consistency.

One idea I had was the following...

Use the icon to convey state, since people seem to agree more on what
state an icon refers to than on what action will result from pushing it.
For example, eye with green check for "on" and an eye with a red X for
"off".

To convey action, use a popup menu. When the user clicks on the icon, he
would see a popup menu with the following two items:

- On
- Off

And there would be a checkmark in front of the one that corresponds to
the current state.

A bit complex, but might work. I like the depressed button idea too.

RE: Designing toggle icon

2009-10-30T11:04:56Z

> Indeed, this is a generic problem for which there is no single best
solution. It depends. But my own research shows
> that people who interpret the label on a toggle button to mean the
command to be executed (rather than the current
> state) are in the majority. However, labels on function buttons that
change are problematic in any case. (Although, I
> have used them on rare and carefully reasoned occasion.)

Thx for answering Larry. Nice to get advice from a guru ;-).

The wiki engine in question (TikiWiki) currently uses that approach
(icon on the button suggests the action that will happen when you click
on it). But we are seeing that a good 50% of users are confused by it
and interpret it in terms of state.

When I tested the 8 icons in my previous email with 12 subjects or so, I
asked half of them what the icon suggested in terms of state, and asked
the other half what it suggested in terms of the action that would
happen.

I found that when people described their understanding of the state,
they were unanimous. But those who were asked to describe what action
would happen tended to split 50-50 between turn off and turn on.

This may be tied to the specific icons I tested, but it might be a hint
that it's easier to clearly convey a state than an action.

This seems to argue for using the icon to convey state, not action...
dunno.

> Here are the options that my work suggests work best, on average (your
mileage may vary):
>
> (a) have a button with an unchanging label (the on-state) that appears
depressed (or on) when selected

So, an eye button that appears depressed or not. Sounds like a good
idea.

Can you provide an example of what such a button looks like?

> (b) have two buttons (watches on, watches off) linked visually and in
behavior

Hum... don't like that. The reason we are going with icons is that we
have a real estate crunch.

> (c) use a check box (e.g., [ ] Watches on)
> On a Wiki, I would favor the latter as more in keeping with the
Web-based interface; and it's simpler.

Unfortunately, that button is part of a toolbar that's all made up of
icons, so I want to keep it that way for consistency.

One idea I had was the following...

Use the icon to convey state, since people seem to agree more on what
state an icon refers to than on what action will result from pushing it.
For example, eye with green check for "on" and an eye with a red X for
"off".

To convey action, use a popup menu. When the user clicks on the icon, he
would see a popup menu with the following two items:

- On
- Off

And there would be a checkmark in front of the one that corresponds to
the current state.

A bit complex, but might work. I like the depressed button idea too.

RE: Designing toggle icon

2009-10-30T10:52:51Z

Alain,

Indeed, this is a generic problem for which there is no single best solution. It depends.
But my own research shows that people who interpret the label on a toggle button to mean
the command to be executed (rather than the current state) are in the majority. However,
labels on function buttons that change are problematic in any case. (Although, I have used
them on rare and carefully reasoned occasion.)

Here are the options that my work suggests work best, on average (your mileage may vary):

(a) have a button with an unchanging label (the on-state) that appears depressed (or
on) when selected

(b) have two buttons (watches on, watches off) linked visually and in behavior

(c) use a check box (e.g., [ ] Watches on)

On a Wiki, I would favor the latter as more in keeping with the Web-based interface; and
it's simpler.

--Larry Constantine

_____

From: agile-usability@... [mailto:agile-usability@...] On Behalf
Of Desilets, Alain
Sent: Friday, October 30, 2009 12:20 PM
To: agile-usability@...
Subject: [agile-usability] Designing toggle icon [1 Attachment]

[Attachment(s) from Desilets, Alain included below]

I know this is a general UI design issue, but I am asking here because I know many of you
folks personally to be a friendly and helpful bunch. But please feel free to tell me to
post this somewhere else (and if so, what list you recommend).

I need to design a clickable icon for use on a wiki system, which will toggle watches on
and off. When watches are on, the user receives email notification of every change made to
a page. If watches are off, he doesn't.

The problem I am having is that no matter what icon I come up with, some people interpret
it as representing the STATE of the watches, and some people interpret it as the ACTION
that will be done on the state of the watches when they click on it. Unfortunately, these
two interpretations tend to contradict each other. For example, an eye with a green
checkmark can be interpreted as:

- Traces are ON (and therefore, click here to turn them OFF)

OR

- Click here to turn traces ON (and therefore, they are currently OFF)

Which are exact opposite of each other. I have tested the list of icons in the attached MS
Word file with a dozen people or so, and I find this contradiction applies with all of
them.

This seems to be a common problem, for example, see:

http://www.ixda. <http://www.ixda.org/discuss.php?post=11512>
org/discuss.php?post=11512

yet, I haven't been able to find a definitive, well accepted design pattern for that.

Does any of you know of one?

Thx.

RE: Re: Designing toggle icon

2009-10-30T10:51:19Z

The idea of a closed eye has been suggested by a number of my test
subjects. I haven't had a chance to test it yet, but my guess is that it
will suffer from the same issue.

Does a closed eye mean
- Watches are currently OFF (and therefore, click here to turn them ON)
OR
- Click here to turn OFF the watches (and therefore, they are currently
ON)

But it's worth a try.

-----Original Message-----
From: agile-usability@...
[mailto:agile-usability@...] On Behalf Of marjoriepries
Sent: Friday, October 30, 2009 1:44 PM
To: agile-usability@...
Subject: [agile-usability] Re: Designing toggle icon

The problem seems to be in depending on the color to convey the meaning
while the eye is static. Maybe if you tried a closed eye vs. an open eye
and forgot about the colored checkmarks completely, then.

the idea of a ligthhouse with a signal beam vs. one without also came to
my mind.

Marjorie

--- In agile-usability@..., "Desilets, Alain"
<alain.desilets@...> wrote:
>

>
>
> The problem I am having is that no matter what icon I come up with,
some
> people interpret it as representing the STATE of the watches, and
some
> people interpret it as the ACTION that will be done on the state of
the
> watches when they click on it. Unfortunately, these two
interpretations

> tend to contradict each other. For example, an eye with a green
> checkmark can be interpreted as:
>
>
>
> - Traces are ON (and therefore, click here to turn them OFF)
>
> OR
>
> - Click here to turn traces ON (and therefore, they are
> currently OFF)
>
>
>
> Which are exact opposite of each other. I have tested the list of

icons
> in the attached MS Word file with a dozen people or so, and I find
this
> contradiction applies with all of them.
>
>
> Thx.
>

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

Yahoo! Groups Links

RE: Designing toggle icon

2009-10-30T10:49:18Z

This button is one of many on a toolbar, and I don't have sufficient
real-estate to put long labels like this.

________________________________

From: agile-usability@...
[mailto:agile-usability@...] On Behalf Of Anders Ramsay
Sent: Friday, October 30, 2009 1:37 PM
To: agile-usability@...
Subject: Re: [agile-usability] Designing toggle icon

Maybe the issue is using icons. Why not just have 'Start watching this
page' and 'Stop watching this page' toggle button?

On Oct 30, 2009, at 1:19 PM, "Desilets, Alain"
<alain.desilets@...> wrote:

I know this is a general UI design issue, but I am asking here
because I know many of you folks personally to be a friendly and helpful
bunch. But please feel free to tell me to post this somewhere else (and
if so, what list you recommend).

I need to design a clickable icon for use on a wiki system,
which will toggle watches on and off. When watches are on, the user
receives email notification of every change made to a page. If watches
are off, he doesn't.

The problem I am having is that no matter what icon I come up
with, some people interpret it as representing the STATE of the
watches, and some people interpret it as the ACTION that will be done on
the state of the watches when they click on it. Unfortunately, these two
interpretations tend to contradict each other. For example, an eye with
a green checkmark can be interpreted as:

- Traces are ON (and therefore, click here to turn them
OFF)

OR

- Click here to turn traces ON (and therefore, they are
currently OFF)

Which are exact opposite of each other. I have tested the list
of icons in the attached MS Word file with a dozen people or so, and I
find this contradiction applies with all of them.

This seems to be a common problem, for example, see:

<http://www.ixda.org/discuss.php?post=11512>
http://www.ixda.org/discuss.php?post=11512

yet, I haven't been able to find a definitive, well accepted
design pattern for that.

Does any of you know of one?

Thx.

Re: Designing toggle icon

2009-10-30T10:43:32Z

The problem seems to be in depending on the color to convey the meaning while the eye is static. Maybe if you tried a closed eye vs. an open eye and forgot about the colored checkmarks completely, then.

the idea of a ligthhouse with a signal beam vs. one without also came to my mind.

Marjorie

--- In agile-usability@..., "Desilets, Alain" <alain.desilets@...> wrote:
>

>
>
> The problem I am having is that no matter what icon I come up with, some
> people interpret it as representing the STATE of the watches, and some
> people interpret it as the ACTION that will be done on the state of the
> watches when they click on it. Unfortunately, these two interpretations
> tend to contradict each other. For example, an eye with a green
> checkmark can be interpreted as:
>
>
>
> - Traces are ON (and therefore, click here to turn them OFF)
>
> OR
>
> - Click here to turn traces ON (and therefore, they are
> currently OFF)
>
>
>
> Which are exact opposite of each other. I have tested the list of icons
> in the attached MS Word file with a dozen people or so, and I find this
> contradiction applies with all of them.
>
>
> Thx.
>

Re: Designing toggle icon

2009-10-30T10:37:03Z

Maybe the issue is using icons. Why not just have 'Start watching this
page' and 'Stop watching this page' toggle button?

On Oct 30, 2009, at 1:19 PM, "Desilets, Alain" <alain.desilets@...
> wrote:

> [Attachment(s) from Desilets, Alain included below]
>
> I know this is a general UI design issue, but I am asking here
> because I know many of you folks personally to be a friendly and
> helpful bunch. But please feel free to tell me to post this
> somewhere else (and if so, what list you recommend).
>
>
>
> I need to design a clickable icon for use on a wiki system, which
> will toggle watches on and off. When watches are on, the user
> receives email notification of every change made to a page. If
> watches are off, he doesn’t.
>
>
>
> The problem I am having is that no matter what icon I come up with,
> some people interpret it as representing the STATE of the watches,
> and some people interpret it as the ACTION that will be done on the
> state of the watches when they click on it. Unfortunately, these two
> interpretations tend to contradict each other. For example, an eye
> with a green checkmark can be interpreted as:
>
>
>
> - Traces are ON (and therefore, click here to turn them OFF)
>
> OR
>
> - Click here to turn traces ON (and therefore, they are
> currently OFF)
>
>
>
> Which are exact opposite of each other. I have tested the list of
> icons in the attached MS Word file with a dozen people or so, and I
> find this contradiction applies with all of them.
>
>
>
> This seems to be a common problem, for example, see:
>
>
>
> http://www.ixda.org/discuss.php?post=11512
>
>
>
> yet, I haven’t been able to find a definitive, well accepted design
> pattern for that.
>
>
>
> Does any of you know of one?
>
>
>
> Thx.
>
>

Designing toggle icon [1 Attachment]

2009-10-30T10:19:58Z

I know this is a general UI design issue, but I am asking here because I
know many of you folks personally to be a friendly and helpful bunch.
But please feel free to tell me to post this somewhere else (and if so,
what list you recommend).

I need to design a clickable icon for use on a wiki system, which will
toggle watches on and off. When watches are on, the user receives email
notification of every change made to a page. If watches are off, he
doesn't.

The problem I am having is that no matter what icon I come up with, some
people interpret it as representing the STATE of the watches, and some
people interpret it as the ACTION that will be done on the state of the
watches when they click on it. Unfortunately, these two interpretations
tend to contradict each other. For example, an eye with a green
checkmark can be interpreted as:

- Traces are ON (and therefore, click here to turn them OFF)

OR

- Click here to turn traces ON (and therefore, they are
currently OFF)

Which are exact opposite of each other. I have tested the list of icons
in the attached MS Word file with a dozen people or so, and I find this
contradiction applies with all of them.

This seems to be a common problem, for example, see:

http://www.ixda.org/discuss.php?post=11512

yet, I haven't been able to find a definitive, well accepted design
pattern for that.

Does any of you know of one?

Thx.

Re: Who tore the cubicles down?

2009-10-28T11:41:24Z

Great, thanks! The more cubicles torn down the merrier :) If you don't
mind, I might be contacting each of you individually to see if I can include
one or more of your cubicle-disassembly stories in my book.

On Tue, Oct 27, 2009 at 2:44 PM, Margaret Motamed <motamed@...> wrote:

>
>
> I don’t know who told the story. But I do know that we have done that
> here locally. With 2 functional teams. Management was fine with it. Only
> facilities was a bit mad at first – because the cube walls were expensive to
> them so they did not want pieces lost etc. So our barrier was facilities
> only.
>
>
>
> Margaret
>
>
>
> *From:* agile-usability@... [mailto:
> agile-usability@...] *On Behalf Of *Anders Ramsay
> *Sent:* Tuesday, October 27, 2009 11:32 AM
> *To:* agile-usability@...
> *Subject:* [agile-usability] Who tore the cubicles down?
>
>
>
>
>
> At the Agile 09 conference, there was a speaker who told a story of how he
> one day, without asking management for permission, simply disassembled a
> bunch of cubicles to create a shared workspace for his team, so they could
> be co-located Racking my brain but cannot remember his name. (And this is
> probably a story he has told before.) Anyone recall who told this story?
>
> -Anders
>
>
>

New to the challenge of Agile Usability. Looking for good ideas.

2009-10-28T08:24:05Z

I'm new to this organisation, and starting to bring in some Scrum practices. There's been a tradition of wireframing and sign-off before development starting here which I want to get away from (at least all up front!) so we can start delivering value faster.

I know there's going to have to be some compromise to get this working, but I'm not sure whether a "wateration", as suggested in some quarters, is the best one. I can see IA/design taking place in the first half of the sprint and development in the second half. Even if we then re-work things next sprint, it's getting away from stories being done done at the end of a sprint. I can't really see this working.

All I can come up with is some combination of the following: Get the Product Backlog in shape with all high priority stories broken down into small chunks and ready for development. Being ready should mean any IA/UCD work is complete at a story/backlog item level - maybe this can be done on a separate cycle, or one sprint in advance ? Do a Sprint Zero for new projects to set overall goals and vision, and allow time for high-level IA (and some systems architecture) to be done. More collaboration between IA, the SME and development - start working as more of a Scrum team.

Anything else seems to go against the Scrum grain. I'm not the kind of person that would blindly adhere to a method, but I don't want to get too far away from the ideal either.

Any good suggestions welcome. Oh, and just to complicate matters further, as well as working on multiple products, the (small) team also has to support and maintain existing applications...

Re: Who tore the cubicles down?

2009-10-27T16:23:51Z

I may have. I have done it, I have told it, and I have heard of others
that did it, and I was at Agile09.

My story predates Agile; I first did it in 1985!

Gerard

-- 
Gerard Meszaros
Lean/Agile Coach/Mentor/Trainer
http://www.gerardmeszaros.com 
1-403-827-2967

Author of the Jolt Productivity Award winning book "xUnit Test Patterns - Refactoring Test Code" and winner of the "Programming with the Stars" competition at Agile 2009. Learn more at http://xunitpatterns.com/index.html

Dan Rawsthorne wrote:

I may have. I have done it, I have told it, and I have heard of others
that did it, and I was at Agile09.

Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
..., 425-269-8628

Anders Ramsay wrote:
>
>
> At the Agile 09 conference, there was a speaker who told a story of
> how he one day, without asking management for permission, simply
> disassembled a bunch of cubicles to create a shared workspace for his
> team, so they could be co-located Racking my brain but cannot
> remember his name. (And this is probably a story he has told
> before.) Anyone recall who told this story?
>
> -Anders
>
>

__._,_.___

Messages in this topic (3) Reply (via web post) | Start a new topic

Change settings via the Web (Yahoo! ID required)
Change settings via email: agile-usability-digest@... | agile-usability-traditional@...
Visit Your Group | Yahoo! Groups Terms of Use | agile-usability-unsubscribe@...

__,_._,___

Re: Who tore the cubicles down?

2009-10-27T15:25:50Z

I may have. I have done it, I have told it, and I have heard of others
that did it, and I was at Agile09.

Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
dan@..., 425-269-8628

Anders Ramsay wrote:

>
>
> At the Agile 09 conference, there was a speaker who told a story of
> how he one day, without asking management for permission, simply
> disassembled a bunch of cubicles to create a shared workspace for his
> team, so they could be co-located Racking my brain but cannot
> remember his name. (And this is probably a story he has told
> before.) Anyone recall who told this story?
>
> -Anders
>
>

RE: Who tore the cubicles down?

2009-10-27T11:44:42Z

I don't know who told the story. But I do know that we have done that here locally. With 2 functional teams. Management was fine with it. Only facilities was a bit mad at first - because the cube walls were expensive to them so they did not want pieces lost etc. So our barrier was facilities only.

Margaret

From: agile-usability@... [mailto:agile-usability@...] On Behalf Of Anders Ramsay
Sent: Tuesday, October 27, 2009 11:32 AM
To: agile-usability@...
Subject: [agile-usability] Who tore the cubicles down?

At the Agile 09 conference, there was a speaker who told a story of how he one day, without asking management for permission, simply disassembled a bunch of cubicles to create a shared workspace for his team, so they could be co-located Racking my brain but cannot remember his name. (And this is probably a story he has told before.) Anyone recall who told this story?

-Anders

Who tore the cubicles down?

2009-10-27T11:31:50Z

At the Agile 09 conference, there was a speaker who told a story of how he
one day, without asking management for permission, simply disassembled a
bunch of cubicles to create a shared workspace for his team, so they could
be co-located Racking my brain but cannot remember his name. (And this is
probably a story he has told before.) Anyone recall who told this story?

-Anders

Re: Re: Tips for people new to Agile?

2009-10-24T07:07:22Z

Glad you found them useful! Please feel free to re-post.

On Fri, Oct 23, 2009 at 2:33 PM, thomas_o_coleman <
thomas_o_coleman@...> wrote:

>
>
>
>
> Hi Anders,
>
> Thanks for your tips!
>
> I'm wondering if you would mind if I repost your comments in another forum
> (the AgileUX group on connect.humanfactors.com)?
>
> Thanks,
> Tom
>
> P.S. I'd also like to invite you all to participate in that forum as well
>
>
> --- In agile-usability@... <agile-usability%40yahoogroups.com>,
> Anders Ramsay <andersr@...> wrote:
> >
> > Some tips that come to mind:
> >
> > * The change in your practice when transitioning to Agile is primarily in
> > the How rather than the What. In other words, you are using a different
> way
> > of communicating the same design principles and ideas you might
> communicate
> > in a traditional process.
> >
> > * Think less of UX as a role and more as a literacy, something that a UX
> > specialist might facilitate. You can also think of yourself as a UX
> coach,
> > playing a role similar to that of an Agile Coach working with a
> traditional
> > team. You may provide guidance and leadership but ultimately it is the
> team
> > as a whole that should be designing the product. This can be a very
> > challenging shift for someone coming from a kind of genius designer
> mindset,
> > in organizations where a creative team is sort of expected to deliver the
> > design from on high to the developers. This is a fundamental
> contradiction
> > to Agile thinking. (And unfortunately one that likely will persist as
> long
> > as academic institutions keep computer engineers in separate buildings
> from
> > those in design programs.)
> >
> > * Because Agile is a completely different paradigm compared to Waterfall,
> > you can't really just flip the methodology switch and one day 'go Agile.'
> > Paraphrasing the book 'Becoming Agile,' just like you wouldn't one day
> get
> > up an run a marathon without first training and building up your stamina
> and
> > running lots of shorter runs first, you need to work on your Agile
> Fitness.
> > One key area is developing a deeper understanding of software
> development,
> > what it actually means to program, actually understanding computer logic,
> > normalization, and other computer fundamentals. A key reason for this is
> > that your practice, if you really are working as an Agile team, will be
> much
> > more integrated with developers. A lot of times, the front-end developer
> may
> > also wear the UX lead hat. Or the UX lead might contribute to front-end
> > development, such as maintaining the CSS. Similarlly, while you may not
> know
> > how to do something like refactoring, you need to understand what it is
> and
> > why it is done. Then, you will be able to more powerfully integrate your
> > practice with theirs. More specifically, while they are doing code
> > refactoring, you can be thinking about your work as UI or UX refactoring.
> >
> > * As Jeff Patton once so wisely pointed out to me, "the user experience
> > exists no matter what." In other words, the moment you've built something
> > with inputs and outputs, it has an experience. Therefore, at a high
> level,
> > the work of a UX specialist is to facilitate achieving maximum Experience
> > Quality.
> >
> > Just a few slightly meandering thoughts.
> >
> > -Anders
> >
> >
> > On Tue, Oct 20, 2009 at 12:11 PM, William Pietri <william@...>wrote:
>
> >
> > >
> > >
> > > Hi! Pretty much every day we moderators see people signing up for the
> list.
> > > As part of the process, they mention why they're here. A common theme
> is
> > > somebody with usability experience who is new to Agile methods. For
> example,
> > > here are some recent ones:
> > >
> > > I'm a Certified Usability Analyst contracting at a company using Agile.
> > > This is a whole new way of doing business for me so I'm trying to get
> as
> > > much help as I can from someone who keeps it real.
> > >
> > > I am a usability practitioner in [Canada]. I currently work on a
> > > large site and i'm interested in learning about how usability with an
> > > Agile flavour can make efficiencies.
> > >
> > > I am UX working at an Agile organization, and would love to discuss and
> > > learn how to merge both UX and Agile methodologies.
> > >
> > >
> > >
> > > Since many of you have been on this list a long time, I thought I'd
> ask:
> > > What tips do you have for user-focused people new to Agile
> environments?
> > >
> > > William
> > >
> > >
> >
>
>
>

Re: Role of the Business/System Analyst

2009-10-23T12:01:20Z

"What it comes down to is that the business representatives don't want to
sit and have business requirements pulled out of them over hours' worth of
meetings over the 3 week iteration period before the next iteration. They
want to be able to say we need this kind of thing, give minimal requirements
and let the team figure out what that means and come back and ask questions
if we need to."
If the meetings that were happening previously weren't really adding value,
then they probably needed to go. If that means there's not as much work for
the existing employees, then what they doing before I guess was just waste.
Obviously, that sucks for the people who have nothing to do now, and shame
on the business for not coping with that well.

If the now defunct meetings _were_ adding value, then the same employees
should have the same amount of work to do, it just may be a little more
chaotic since they'll need to go track down the biz reps to get answers to
their questions.

my 2 cents

On Fri, Oct 23, 2009 at 1:25 PM, Jeanne Hallock
<jeanneh@...>wrote:

>
>
> First let me start off with that my role at my company is UI
> designer/user experience specialist for a 'silo'ed group with an additional
> UX group that governs across a large enterprise company. We are, from
> Nielsen's writing, 10-14 years a way from being a truly user-centered
> development group. I have worked previously in a dot-com environment, which
> was an agile shop.
>
> In a couple project groups, one of our business representatives is trying
> to push our group to be even "more" agile than we have been. We are in an
> enterprise agile situation, so we have never done what I would call real
> agile.
>
> What it comes down to is that the business representatives don't want to
> sit and have business requirements pulled out of them over hours' worth of
> meetings over the 3 week iteration period before the next iteration. They
> want to be able to say we need this kind of thing, give minimal requirements
> and let the team figure out what that means and come back and ask questions
> if we need to.
>
> Our business analysts are completely freaked out and are trying to talk
> them out of it. In my attempt/research on the web what the role of the
> analyst is in agile to help them calm down some, what I have found is pretty
> much my role, the user experience specialist, is being assigned to the
> business analyst. I understand that in agile everyone is supposed to do
> every job to some extent and in a more team-environment I have seen that it
> works well. So, I don't have a problem with that exactly.
>
> But in the enterprise situation office politics take a heavy toll in many
> areas. In our case the analysts play a major role politically in the vision
> and lifecycle process. They are the 'scopers' or the gatekeepers. They
> often mold and push business towards or away functionality based on
> judements of value or team cost such that they determine what functionality
> will really be developed and to what extent.
>
> What I have been reading online basically puts one of us out of business
> because their agile documentation puts them in user representative role. So
> what should the role of the analyst in agile when you have a usability/ux
> person in the mix? How are other companies, especially at the enterprise
> level handling it?
>
> Thanks in advance,
> Jeanne Hallock
>
>
>
>

--
Chris
http://clabs.org

Re: Tips for people new to Agile?

2009-10-23T11:33:55Z

Hi Anders,

Thanks for your tips!

I'm wondering if you would mind if I repost your comments in another forum (the AgileUX group on connect.humanfactors.com)?

Thanks,
Tom

P.S. I'd also like to invite you all to participate in that forum as well

--- In agile-usability@..., Anders Ramsay <andersr@...> wrote:

>
> Some tips that come to mind:
>
> * The change in your practice when transitioning to Agile is primarily in
> the How rather than the What. In other words, you are using a different way
> of communicating the same design principles and ideas you might communicate
> in a traditional process.
>
> * Think less of UX as a role and more as a literacy, something that a UX
> specialist might facilitate. You can also think of yourself as a UX coach,
> playing a role similar to that of an Agile Coach working with a traditional
> team. You may provide guidance and leadership but ultimately it is the team
> as a whole that should be designing the product. This can be a very
> challenging shift for someone coming from a kind of genius designer mindset,
> in organizations where a creative team is sort of expected to deliver the
> design from on high to the developers. This is a fundamental contradiction
> to Agile thinking. (And unfortunately one that likely will persist as long
> as academic institutions keep computer engineers in separate buildings from
> those in design programs.)
>
> * Because Agile is a completely different paradigm compared to Waterfall,
> you can't really just flip the methodology switch and one day 'go Agile.'
> Paraphrasing the book 'Becoming Agile,' just like you wouldn't one day get
> up an run a marathon without first training and building up your stamina and
> running lots of shorter runs first, you need to work on your Agile Fitness.
> One key area is developing a deeper understanding of software development,
> what it actually means to program, actually understanding computer logic,
> normalization, and other computer fundamentals. A key reason for this is
> that your practice, if you really are working as an Agile team, will be much
> more integrated with developers. A lot of times, the front-end developer may
> also wear the UX lead hat. Or the UX lead might contribute to front-end
> development, such as maintaining the CSS. Similarlly, while you may not know
> how to do something like refactoring, you need to understand what it is and
> why it is done. Then, you will be able to more powerfully integrate your
> practice with theirs. More specifically, while they are doing code
> refactoring, you can be thinking about your work as UI or UX refactoring.
>
> * As Jeff Patton once so wisely pointed out to me, "the user experience
> exists no matter what." In other words, the moment you've built something
> with inputs and outputs, it has an experience. Therefore, at a high level,
> the work of a UX specialist is to facilitate achieving maximum Experience
> Quality.
>
> Just a few slightly meandering thoughts.
>
> -Anders
>
>
> On Tue, Oct 20, 2009 at 12:11 PM, William Pietri <william@...>wrote:
>
> >
> >
> > Hi! Pretty much every day we moderators see people signing up for the list.
> > As part of the process, they mention why they're here. A common theme is
> > somebody with usability experience who is new to Agile methods. For example,
> > here are some recent ones:
> >
> > I'm a Certified Usability Analyst contracting at a company using Agile.
> > This is a whole new way of doing business for me so I'm trying to get as
> > much help as I can from someone who keeps it real.
> >
> > I am a usability practitioner in [Canada]. I currently work on a
> > large site and i'm interested in learning about how usability with an
> > Agile flavour can make efficiencies.
> >
> > I am UX working at an Agile organization, and would love to discuss and
> > learn how to merge both UX and Agile methodologies.
> >
> >
> >
> > Since many of you have been on this list a long time, I thought I'd ask:
> > What tips do you have for user-focused people new to Agile environments?
> >
> > William
> >
> >
>

Role of the Business/System Analyst

2009-10-23T11:25:44Z

First let me start off with that my role at my company is UI designer/user
experience specialist for a 'silo'ed group with an additional UX group that
governs across a large enterprise company. We are, from Nielsen's writing,
10-14 years a way from being a truly user-centered development group. I have
worked previously in a dot-com environment, which was an agile shop.

In a couple project groups, one of our business representatives is trying to
push our group to be even "more" agile than we have been. We are in an
enterprise agile situation, so we have never done what I would call real
agile.

What it comes down to is that the business representatives don't want to sit
and have business requirements pulled out of them over hours' worth of
meetings over the 3 week iteration period before the next iteration. They
want to be able to say we need this kind of thing, give minimal requirements
and let the team figure out what that means and come back and ask questions
if we need to.

Our business analysts are completely freaked out and are trying to talk them
out of it. In my attempt/research on the web what the role of the analyst is
in agile to help them calm down some, what I have found is pretty much my
role, the user experience specialist, is being assigned to the business
analyst. I understand that in agile everyone is supposed to do every job to
some extent and in a more team-environment I have seen that it works well.
So, I don't have a problem with that exactly.

But in the enterprise situation office politics take a heavy toll in many
areas. In our case the analysts play a major role politically in the vision
and lifecycle process. They are the 'scopers' or the gatekeepers. They often
mold and push business towards or away functionality based on judements of
value or team cost such that they determine what functionality will really
be developed and to what extent.

What I have been reading online basically puts one of us out of business
because their agile documentation puts them in user representative role. So
what should the role of the analyst in agile when you have a usability/ux
person in the mix? How are other companies, especially at the enterprise
level handling it?

Thanks in advance,
Jeanne Hallock