Customizing Components

6 Feb 2008 - 9:07am
6 years ago
4 replies
346 reads
Kel Smith
2007

I was recently brought aboard a project lifecycle in midstream. The end deliverable is a large-scale sales application built in Java using open source UI components. The topical usability of these widgets is quite poor, almost to the extent that they operate against commonly accepted conventions.

I should add that the application is intended for users who have minimal computer experience; from the UX point of view, I obviously have some concerns. I would love to reinvestigate a different framework in a future sprint, but that would necessitate buy-in among folks who have already put in a great deal of effort.

So here's my question: has anyone out there had such an experience, and if so how did you best handle it? It's very important that I maintain a win-win outcome among technical and business stakeholders; I want to be respectful of legacy while recommending a serious rethink of the approach.

Don't you wish you were me? :)

Many thanks everyone ...

Comments

6 Feb 2008 - 9:57am
Adrian Howard
2005

On 6 Feb 2008, at 14:07, Kel Smith wrote:
[snip]
> So here's my question: has anyone out there had such an experience,
> and if so how did you best handle it? It's very important that I
> maintain a win-win outcome among technical and business
> stakeholders; I want to be respectful of legacy while recommending
> a serious rethink of the approach.
[snip]

I've not been in exactly that situation, but I have been in similar.
It's a bugger isn't it!

My tip would be not to focus on the framework and the problem, but
the process that highlighted the problem. Rather than trying to sell
"this framework sucks - lets go get a better one" I would start
pushing things like "We need to do some user testing to make sure
that folk can use the software".

Once you have buy-in from the developers and management on the
necessity for a usable system, you can use things like user-testing
to demonstrate the problem. At this point it should be everybody's
problem, rather than just yours :-)

Cheers,

Adrian

6 Feb 2008 - 10:34am
Gloria Petron
2007

I've been in exactly your situation. At this stage, what the team needs is
not your expertise on how things could have been done, but your help making
a success out of the tool they've currently chosen. If you can use what you
know to help create a successful outcome, you will gain credibility points
which will get you a lot farther in the long run.

Also, never underestimate how much people can be impressed with small wins,
such as you can get by performing a few well-placed "interface surgeries"
(to use R Hoeckman Jr's term) to the worst UI widget offenders.

I recently worked on an intranet project with many challenges: lousy
Lotus/Domino back-end technology and a really insecure marketing team who
was anxiously spraying feelgood text all over anything that couldn't get out
of the way. Within these constraints I went to work and applied best
practices as much as I could.

To me, the finished product looked like JoJo the Dog-Faced Boy. But the
project sponsors were ecstatic. You can't account for taste, but you*
can *decide
whether or not you're going to be a difficult person to work with. Ask
yourself: is your objective to make sure that everyone knows what you know,
or is your goal to quietly use what you know to be the guiding hand in a
storm?

6 Feb 2008 - 11:52am
jrrogan
2005

I've worked on a couple of projects like this.

Basically you have a classic cost/benefit analysis infront of you:

Cost of Changing frameworks VS benefit of improved User Experience.

Some things to think about:

1. If you're competitively selling this app you can argue that paying the
price now ensures success later.
2. If you don't have direct competition, then determine end user influence
on adoption of software, and use this as leverage.
3. If you're not in a competitve environment and the end users have little
influence on adoption, then you can focus on data
entry/manipulation/accuracy of input with the poor screen UI VS an enhanced
UI.

If none of the above arguments work, (or anything else), and you end up with
the sh*tty framework, I totally agree with Gloria's previous post that
incremental positive changes can go very far in making an app better, (and
remember "a little better" is a lot better then "a little worse" ;)

Rich

--
Joseph Rich Rogan
President UX/UI Inc.
http://www.jrrogan.com

6 Feb 2008 - 4:15pm
Kel Smith
2007

Terrific responses as usual. Exactly why IxDA is the bestest message
board out there.

Thanks, everyone.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=25593

Syndicate content Get the feed