RE: [agile-usability] can agile customers support minimal commitment to UX design? was: Minimal commitment UX design
- I didn't say or suggest that we should withhold information. I'm in favor of
sharing all the information we have and I'm suggesting that real users will
not be confused by seeing rough interfaces, and will not be confused by
hearing there's more to the program than the glass on the front of it.
That's clear. My point is that there are reasons to avoid doing so as well.
Your post (which mocked the idea by invoking "pessimistic notions about...
'mere users'") implied that the only reason one would avoid sharing a rough
UI was some lack of trust or respect. I was pointing out that there are
other reasons one might choose to hold back rough UI.
- On Oct 1, 2005, at 9:28 AM, Joshua Seiden wrote:
>See, that's the issue. I recently had a client who was converting an
>> 2) How could the system have been built such that the decision to
>> switch could have been made later - still with reasonable cost?
> Don't know. I'm not in the construction business ;-)
old, old system from one type of database to another. It was hell. But
it would wrong to conclude that's an unavoidable fact about systems
that use databases. It's just a consequence of the way they originally
decided to do it. We could go back in time and say to them, "What
you're about to do is a *bad* idea. Do this instead. It's only a
trivially different amount of work, it won't affect anything users see,
but you'll be happy you did if you ever switch databases."
So your data point isn't suggestive unless we could expose the design
to an expert and have that person say either what my database person
would have said or "I cannot see any way to build a system that would
support UX 1 and also easily be switched to UX 2."
If we're to understand what we have to get right up front and what can
be deferred, we need to look in some detail at both successes and
>> 3) How can the system be built such that *not* switching doesn'tSuppose there's a way of building a system such that it both supports
>> result in a lot of work with no payoff?
> I'm not sure I understand this question. Can you clarify what you're
UX 1 today and would make it easy to switch to UX 2 tomorrow. That way
makes the system 50% more expensive to build today. If the switch is
never made, that's a lot of money spent with no return. We need a way
where additional up-front cost is low.
Brian Marick, independent consultant
Mostly on agile methods with a testing slant
Book in progress: www.exampler.com/book