Technical Limitation Arguements

29 Apr 2009 - 10:49pm
4 years ago
11 replies
271 reads
Elle C.
2009

Hi,

I'm in a transition stage, moving from developer to business systems
analyst. In this new role, I'm trying to incorporate some usability
guidelines and improve user interaction. I get quite a bit of push
back from the developer team members.

They claim certain things cannot be done. However, being a
developer, I know some things can be done. There was even a point,
since I still have access to the environment that I wrote some code
to prove it. I cannot go on doing that for the rest of my career.
But, I would hate to give up the fight, and allow good interaction
design to take a backseat to quick, dirty, & cheap development.

How do some of you, who have been in my situation, handle these types
of resistances, so that your application can be a good and usable
one?

Thanks,
Elle

Comments

1 May 2009 - 3:33am
Yohan Creemers
2008

Hi Elle,

I like your approach, saying: if you (mr developer) can't do it, I will do
it myself. In my experience you only have to say/prove it once or twice and
professional developers will take the challenge the next time.

Nothing is impossible. Some design solutions are expensive, unsecure or for
some other reason not perfect. Invite developers to criticize your design.
Let them explain what the technical consequences are and -important- ask
them to think of alternatives that are more desirable from a technical view
point. In most cases a compromise within the functional and technical
constraints is possible. The end result will be a piece of teamwork all team
member are proud of.

If this strategy doesn't work, I can only advise to hire better developers
;) Don't give up the fight, it's your responsibility to create a solution
with the best interaction possible.

- Yohan.

1 May 2009 - 6:36am
Bruce Esrig
2006

The real stunner in my experience is to say ...

The criteria that you are using in order to determine what to do are
different from the criteria I'm using. Your criteria are based on technical
insights together with your beliefs about what would work for the user.

There's a whole discipline devoted to figuring out what users do, what they
want, and what we should do for them. There are a whole lot of surprises
that come out of looking at things from the users' point of view. For
example, in our situation, ...

Let's talk about things from both points of view: what experience the users
would find most beneficial and compelling, and what we can do for them. I'll
keep user behaviors uppermost in my mind, and you can keep technical
considerations uppermost in your mind. But we each have to turn to the other
to make this work, because we are developing complementary expertise.

Here are some things I've laid out that provide a framework that we can work
in ...

Best wishes,

Bruce

On Fri, May 1, 2009 at 4:33 AM, Yohan Creemers <yohan at ylab.nl> wrote:

> Hi Elle,
>
> I like your approach, saying: if you (mr developer) can't do it, I will do
> it myself. In my experience you only have to say/prove it once or twice and
> professional developers will take the challenge the next time.
>
> Nothing is impossible. Some design solutions are expensive, unsecure or for
> some other reason not perfect. Invite developers to criticize your design.
> Let them explain what the technical consequences are and -important- ask
> them to think of alternatives that are more desirable from a technical view
> point. In most cases a compromise within the functional and technical
> constraints is possible. The end result will be a piece of teamwork all
> team
> member are proud of.
>
> If this strategy doesn't work, I can only advise to hire better developers
> ;) Don't give up the fight, it's your responsibility to create a solution
> with the best interaction possible.
>
> - Yohan.
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>
>

1 May 2009 - 9:33am
Adrian Howard
2005

On 30 Apr 2009, at 12:49, Elle wrote:
[snip]
> How do some of you, who have been in my situation, handle these types
> of resistances, so that your application can be a good and usable
> one?
[snip]

The best way I find to get out of these situations is to ask "Why?" -
possibly several times (http://en.wikipedia.org/wiki/5_Whys :-)

Some of the reasons I discover have included things along the lines of
* Time constraints: "Well of course we could do Foo if we had 3 months
- but it needs to be released next week".
* Multi-tasking problems: "Well of course we could do Foo, but I'm
working on projects X & Y too. Boss says project X wins".
* Feature prioritisation issues: "Well of course we could do Foo, but
at the moment that bit of the system is functional - if ugly - and
OtherImportantFeature still needs finishing for sales to meet their
promises"
* Skill issues: "You can do Foo? How?" (just coz _you_ can do it
doesn't mean they can :-)
* Budget constraints: "Of course we could do Foo, but we only have
three days of money left"
* Reward structures: "Of course we could do Foo, but that's not a new
feature - that's just a UI fix - and we lose our bonus if we don't
ship another new feature this month"
* Organisational issues: "You can tell me to do Foo all you like, the
only person who can get me to switch from my current task is my boss"
* Previous experiences: "Every time a designer tells me to change
something, it comes back to bite us with bad customer reports & failed
projects" (There are a lot of bad designers out there unfortunately.
Some really good developers have only worked with bad designers. This
can colour their view of the group...)
... and so on ...

More often than not I find that the underlying reason for the "no"
makes perfect sense to the person saying it. More often than not the
root cause turns out to be a business/organisational issue rather than
anything related to the ux/dev folk.

Sometimes "no" turns out to have been the right answer given the whole
context.

Do your devs have reasons for their "no"?

Cheers,

Adrian

1 May 2009 - 10:44am
Sharon Greenfield5
2008

Sounds like less of a technical issue, and more of a respect issue.
You could be a clown transitioning to ringmaster; you could experience
the same thing.
Read an I/O Psychology book for understanding motivations and finding
possible solutions.

On Apr 30, 2009, at 12:49 PM, Elle wrote:

> Hi,
>
> I'm in a transition stage, moving from developer to business systems
> analyst. In this new role, I'm trying to incorporate some usability
> guidelines and improve user interaction. I get quite a bit of push
> back from the developer team members.
>
> They claim certain things cannot be done. However, being a
> developer, I know some things can be done. There was even a point,
> since I still have access to the environment that I wrote some code
> to prove it. I cannot go on doing that for the rest of my career.
> But, I would hate to give up the fight, and allow good interaction
> design to take a backseat to quick, dirty, & cheap development.

1 May 2009 - 5:32pm
DampeS8N
2008

There are no such things as technical limitations. That is a cop-out
phrase that people use to avoid change.

That said. There is such a thing as financial limitations. It is
technically possible to build something JUST LIKE a google search
appliance but that returns a REAL total number of results. It would
require a lot more power than a GSA comes with, and a lot more
thought, and millions of dollars in R&D.

When a GSA is 1/100th that cost.

So it is better to just not have a 'go to the last page' button.

Will

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

1 May 2009 - 5:55pm
Jared M. Spool
2003

On May 1, 2009, at 3:32 PM, William Brall wrote:

> There are no such things as technical limitations. That is a cop-out
> phrase that people use to avoid change.

Huh.

Someone better tell the poor electron, which has spent all of its
existence trying to move faster than the speed of light and never
quite getting there.

I would think, at some point, you run into limitations of the space-
time continuum.

> That said. There is such a thing as financial limitations.

Now, that's interesting. I guess it's been somewhat proven by the
federal debt, though not quite.

I don't think either of these approaches of declaring what are
limitations are really helpful to someone.

I'd suggest you look for something that actually holds proverbial water.

Jared

1 May 2009 - 6:03pm
Jared M. Spool
2003

On Apr 30, 2009, at 12:49 PM, Elle wrote:

> How do some of you, who have been in my situation, handle these types
> of resistances, so that your application can be a good and usable
> one?

Elle,

What you're describing is an adversarial relationship with developers.
You say it can be done. They say it can't.

This is a classic opinion war. And, in my experience, opinion wars can
not be won. So, if you take this approach, you will always lose.

In our research, we've found the best teams step past opinion wars by
having a solid experience vision and a good feedback mechanism.

The team collaboratively creates a vision of what an aspirational
experience could be, sometime in the future. Imagine what it's like to
use the design without today's frustrations -- what would that be
like? (Note: this isn't 'What would the DESIGN be like?', but instead
'What would the EXPERIENCE be like?')

The team then measures the current experience (using techniques like
usability testing and field studies). Then it talks about what baby
steps could move them in the direction of the vision.

This is very different from the You-Must-Do-This/We-Can't-Do-This
approach of the opinion war. It's a collaborative and iterative
process, where the entire team explores the options.

You can see more about what I'm talking about in this article:

The 3 Q's For Great Experience Design
http://www.uie.com/articles/the3qs/

Hope that helps,

Jared

p.s. This is also what we're talking about in the upcoming UIE
Roadshow: http://is.gd/gxwe -- I'll have a discount code for IxDA
folks shortly.

Jared M. Spool
User Interface Engineering
510 Turnpike St., Suite 102, North Andover, MA 01845
e: jspool at uie.com p: +1 978 327 5561
http://uie.com Blog: http://uie.com/brainsparks Twitter: @jmspool
UIE Roadshow: Seattle, Denver, DC in June: http://is.gd/gxwe

1 May 2009 - 7:10pm
Angel Marquez
2008

>>moving from developer to business systems
Internal move or company to company? I only ask because if it was internal
you would know who you are dealing with.

>>They claim certain things cannot be done.If they cannot be done and they
have been employed and have say you can be absolutely certain they know what
can be done to secure their position.

>>There was even a point, since I still have access to the environment that
I wrote some code to prove it.
You are totally undermining their authority. I've totally done this before.
Or I've done it with out showing then asked if it could be done and when
they say no I say how did I make this happen (with that total I am f*cking
retard look on my face). Or my favorite is to ask if it is okay if you do it
because you know how. Hell no do that want that to happen.

I guess you should ask for their advice or alternative solutions even
thought you know they are full of sh*t. Their is always more than one way to
do something, might as well hear em out.

2 May 2009 - 12:49pm
Kevin Cornwall
2009

My favorite aphorism that applies:
Cheap, fast, good. Pick two.

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

3 May 2009 - 3:37pm
Mark Young
2008

In response to "Can't be done" you might offer a work session where
together you design how it can be done and also work out an estimate
of how much work/time it would take to build it.

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

3 May 2009 - 2:20pm
ckarbass
2008

Hi Elle,

I think what may help you is focusing on getting your developers to
achieve empathy for your users.

One of the best ways to do this is to involve them with your
usability testing. Watching four or five people painfully struggle
through a user test is extremely motivational to anyone watching:
developers/managers/designers/etc

Otherwise, a developer without empathy may not be able to rationalize
a difficult technical hurdle if they think the product is fine.

-Cyrus

www.twitter.com/ckarbass

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

Syndicate content Get the feed