Re: starting human factors work

Carrie--

I've been in this situation a few times myself.  I don't know of any  
books off the top of my head that address this exactly.  Here's the  
outline of the book I would write...

My background is in engineering, and it sounds to me from some of your  
comments that you are overstating the engineers' objections although  
you have good instincts.  Since you're part of the software  
engineering team, you need to fit into that culture.

You're right that making a bunch of changes for something with a Feb.  
15 release date will make you unpopular.  However, and this will take  
some time to show, usability efforts--just having someone focused on  
the user experience--usually make projects *more* predictable.   
Engineers love that.  If up until now they have just been building  
whatever someone "thinks" is better, that means they have also been  
changing it as the political winds shift and as they learn, often very  
late in the game, that these opinions are not correct.  The engineers  
may have very well developed an idea that users are unpredictable (or  
"stupid") and that all UI design decisions are arbitrary.  I've worked  
with many engineers who used to avoid UI-related projects completely  
because all the changes and uninformed opinions drove them nuts.  When  
a project goes that way, it's the engineers who have to put in the  
long hours.

The good news is that you have all the tools to show that while people  
are not as predictable as computer systems, it is possible to design  
things that are likely to work and to subject the designs to various  
kinds of testing before the engineers spend too much time building  
them.  The engineers want this to happen and will help you
I always see my role as teaching the rest of the team the basic  
principles of design and usability testing.  How do we know what we  
know and how do we test it?  Testing hypotheses--it's the scientific  
method, an easy sell.  Find your open-minded colleagues and explain to  
them what you need.  You may not get all the time you want the first  
time around, but you will not need a lot to show value if they have  
never done this before.  If all you can do right now is predict some  
of the post-release user complaints or falling short of metrics, at  
least you will have demonstrated you're not giving random opinions.   
Or try to pick the one or two things that has the most impact but is  
easiest to fix.

Having a usability test or other standard for what makes a design good  
enough protects the engineers, too.  If you've tested it and it works,  
it's a lot harder for someone else to say it's confusing and needs to  
be changed.  Engineers also understand the risks of sending software  
into the world without testing, so once you show them the kind of  
testing and analysis you can do for usability, they will be on your  
side when someone with an opinion wants to mess things up and ship it  
to customers without the proper testing.  (They will also eventually  
keep you honest if you try to make last-minute changes that shortcut  
your own standard!)

If you can set up a study where the project team can watch real people  
interact with the product (it can be a formal usability lab, but  
that's not necessary), that's the best way to convince them that their  
users are not stupid.  You can even let them recruit the participants  
from among their friends.  (This isn't going to find the same problems  
as better targeting, but that's not necessarily the goal.)  What they  
will see is smart people who are not nearly as familiar with the  
jargon as you all are.  They will see ordinary people making perfectly  
understandable mistakes that could be prevented.  Once they see that  
you have the expertise to make fixes that help people to avoid these  
mistakes, and you are not just guessing, they will understand that  
following your recommendations is less risky than following someone  
else's or copying Facebook or whatever.

Engineers have a lot of "skin in the game," and are held accountable  
for results like nobody else.  (Sales is close.)  I've been  
programming again lately, because mobile apps benefit from having the  
UI designer working at that level.  As an engineer, if you make one  
typo and the app crashes in front of the client, it doesn't matter  
that you've done 1,000 other things right.  Since your mistakes and  
delays get the most attention, engineers are cautious about who they  
trust with decisions.   They lose patience with people who flit in and  
offer opinions but never put their assertions to a public test.  Last- 
minute changes might or might not make things better for end users,  
but they definitely make it more likely that a bug is going to pop up  
at a bad time.  In that sense, engineers feel they do know better than  
you what's in the best interest of the product.

To win the respect of engineers, it helps to show that you are willing  
to be held accountable for your work, too.  So if you set things up so  
that there is going to be a time where users are brought in and they  
use a prototype and the whole team is watching and it will fail  
spectacularly if you are wrong, they will take you seriously.  Or if  
you set a target of a certain metric, that works too.  (They will take  
you seriously just for being willing to do this, even before it  
happens.)  And they will be much less likely to second-guess you too  
strongly, knowing that they might be proven wrong in the end.  In a  
way, I am recommending "usability testing theater" but it really is a  
powerful experience for people who haven't seen it before and haven't  
had any other way to watch their users in action.  It shows that you  
are willing to put skin in the game.  Sometimes it's the only way to  
get everyone to see a problem clearly.

Other ways to give the engineers a sense of the kinds of problems  
users encounter is to set up a field trip to a customer site, or  
listen in on support calls and talk to the support people.  All too  
frequently, engineers are not allowed anywhere near customers.  As a  
designer, you're in a position to advocate for giving the engineers  
first-hand knowledge of the people they're trying to help.  Engineers  
like information, and get skeptical when people come in and demand  
their trust while seeming to withhold information.  I've found that  
engineers like to be included and to be given information and  
experiences, but are also very unlikely to seek out opportunities to  
interact with users on their own.  Not every engineer will want to do  
this, but if you reach out to the ones who are, that will help.   
Transparency is a good idea.

Yes, this is a lot more work than if everybody just listened to your  
recommendations, and yes, you will have to do this even for things  
that 99% of the members of this list would find uncontroversial.   
Another consultant I know has a saying, "If they knew what they were  
doing, they wouldn't hire us."  In other words, it's unreasonable to  
expect people to recognize the right answer when they see it because  
if they could do that, well, they wouldn't need us.  (And putting it  
that way keeps us humble.)

Good luck!

--Brian


On Jan 6, 2010, at 4:00 PM, Carrie Lee wrote:

> hi all,
>
> i recently started at a company where I am the first Human Factors  
> Engineer
> they've ever had. I've been in this position before at another  
> company and
> it didn't go to well since developers were used to making all the  
> decisions
> themselves and didn't want to listen to anyone, even the users. These
> developers would insist that users are stupid and they (the  
> developers) know
> what is best. (I don't work there anymore.)
>
> Can anyone point me to articles or books that talk about how to  
> start a
> successful Human Factors discipline within a company that never had  
> anything
> like this???
>
> It's obvious this company needs people like me, but some developers  
> here
> seem to be on a similar path - saying they know what is best and
> disregarding research and recommendations from users. I still find  
> myself
> implementing what someone "thinks" is best, despite research and
> recommendations going the opposite way.
>
> The company did hire me, although I don't know who championed that  
> decision.
> My direct manager is a project manager, and I am part of the software
> engineering team. Everyone likes the idea of having human factors  
> work done,
> but not when it messes with any deadlines. I was initially asked to  
> give
> recommendations for a product that is scheduled to be shipped out on  
> Feb 15.
> Needless to say, my recommendations are not being considered since  
> it's too
> late to make design/development changes....
>
> - carrie
> _______________________________________________
> This is the BayCHI Discussions mailing list, [email protected]
> To change your subscription options, or to unsubscribe, visit http://baychi.org/mailman/listinfo/discussions
_______________________________________________
This is the BayCHI Discussions mailing list, [email protected]
To change your subscription options, or to unsubscribe, visit http://baychi.org/mailman/listinfo/discussions