What do you do.. 3

[TheVampire]

When a customer gives you a specification for an interface that looks like absolute junk? A color scheme that wild monkeys in a Sherwin-Williams paint store could do better?

Just a small sample...

I'm talking about buttons on two different data entry screens that are labeled the same, but act 180 degrees differently.

Buttons, when clicked, that don't appear to have done anything at all, but in reality have changed data.

And the reverse. Buttons that appear to have done something, but they really didn't!

Forms, that when a record is selected to edit and the user selected the wrong one and they cancel the edit, that the whole form is unloaded and the user has to navigate back through 4 levels of nested menu's just to get back to the form again so they can select the correct record!

How do you politely explain to them that the design needs *work*?

The people that did the design are not ( suprise ) the people that will actually be using the program.

What I'm worried about is that if we follow the spec, when the product actually gets to the users and the inevitable happens, we'll get shafted with the blame, regardless of what the spec says.

I've already documented most of the items in question ( in the most Politically Correct language I can manage ), and made sure that the various people on both sides have been copied the information, but nothing seems to be changing the customers mind on this.

Should I just grit my teeth and do what they ask for, or does anyone have any suggestions on a way that I can be more convincing? I've already considered writing *two* versions of the app. One way to the spec, and the other with my suggestions. If I have the extra time...

Robert

 

[jrbarnett]

Can you get a "specifier" and "user" together to discuss this, have the user (preferably one that's reasonably computer literate and sensible) view the designs and comment face to face with the specifier and see what is said.
No need to raise your concerns unless somebody else does, or you are asked what you think.

John

 

[sleipnir214]

I disagree. If you are in a position where you will have to implement gobbeldygook, then you should voice your concerns.

The customer may always be right, but only in the broadest sense of the phrase. A restaurant doesn't get to tell the chef how to cook, only that he doesn't want salt on his meal.

Likewise, your real job is to provide a product to your client what will further his business goals. If the UI is ill-designed, then the product will not fulfill its reason for existence.

Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!!

 

[ecobb]

Bring money into the picture, that always makes people listen to what you have to say. Sit down and go through their design vs. how you would design it. Point out to them (politely) that what they're asking has a lot of tedious, unnecessary coding in it, which will mean you have to spend more time working on it, which means it will cost more to build. Show them how you have found a way to streamline the application, taking out the redundancy and unnecessary portions, making it faster, more efficient, and possibly saving them money on the designing of it.

Be sure to take the approach of "You guys have a great idea, and after thinking about it I may have found a way that WE can make it even better" instead of "This is junk it will cause nothing but a headache for everyone involved".

Hope This Helps!

Ecobb

"Alright Brain, you don't like me, and I don't like you. But lets just do this, and I can get back to killing you with beer." - Homer Simpson

 

[CajunCenturion]

I agree that you need to bring these issue to light. If you believe that the design is flawed, then you have obligation to bring up and get it worked out as best you can.

If the customer acknowledges the issues and indicates they are not going to be a problem, then I would first decide whether or not (if you can) to participate in the project. If so, then put your concerns in writing and get their response in writing.

I would not write two versions of the app, unless they pay for two versions.

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[BJCooperIT]

My take on this is that if you plan on cashing your paycheck then you have an obligation to speak up (carefully)! This is part of what we professionals are paid to do - deliver a quality product. If the specifications are "rough draft" status, then you need to meet with the customer and discuss revisions that will bring the specifications up to company standards. If there are no standards then that is step #1.

This requires diplomacy to avoid having them feel as though you are trashing their efforts. I agree with Ecobb's "great idea" approach. Applaude their efforts and lead them by the hand so that they learn a better way.

^{Beware of false knowledge; it is more dangerous than ignorance. ~George Bernard Shaw}
Consultant/Custom Forms & PL/SQL - Oracle 8.1.7 - Windows 2000

 

[carp]

Concur. And if you're concerned about being blamed for it after the fact, do your "voicing" in writing and get the highest person you can to sign acknowledgement that you have explained the problems/risks to them and they STILL want to go through the icebergs at flank speed.
THEN put the document someplace very safe.

 

[bi]

Robert has already stated that he has brought up his concerns about the design (I've already documented most of the items in question ( in the most Politically Correct language I can manage ), and made sure that the various people on both sides have been copied the information, but nothing seems to be changing the customers mind on this.).

I would suggest you make sure you have a copy of the email or memo you sent with the problems and any replies you may have received.

Then I would follow either ecobb's or jrbarnett's suggestions (perhaps in that order).

 

[rosieb]

I'd agree with jrbarnett , try to get some real users involved. Ecobb is right about the flattery angle for whoever has produced the spec. It sounds as if they're inexperienced, in which case they would probably welcome tactfully offered advice.

You might want to introduce them to the idea of setting "design rules" for achieving consistancy in interfaces, it's also worth asking for process maps. You could try to get them to work with you on a "house" style.

Years ago I was given a copy of "The Psychology of Everyday Things" by Donald Norman, this contains some great rules for creating a totally unusable interface (most of which your customer seems to have grasped intuitively). I can't lay hands on my copy immediately (I think it's in the attic), but I think the book's still available. If you can find a copy, showing them the rules might help you get your point across - but do it gently.

 

[lespaul]

It's now called "The Design of Everyday Things"

and here's a link to amazon:

http://www.amazon.com/exec/obidos/tg/detail/-/0465067107/104-3494189-2483956?v=glance

Sounds interesting! May have to get it myself!

leslie

 

[pmonett]

If you implement a system you know is flawed, then you risk being the center of the ensuing flurry of "this doesn't work" calls.
Multiple buttons with same label and different functions, buttons that do not appear to have done anything, or that do without showing it, these things to me spell multiple hours in help desk calls and user frustration.
You will inevitably be called on to change these elements and you will be blamed for having implemented them incorrectly - even if you did exactly what the specifications said.
A button must always show a result - else the user will mash it a hundred times and then panic and complain when the result is a disaster. Misleading lables will invariably ensue in wrong buttons clicked at the wrong time and frantic helpdesk calls when the blunder is discovered (sometimes far too late).
The system you describe is a recipie for disaster. I would try to make your employer understand that as politely and diplomatically as possible. If no understanding is possible, then it is up to you to decide whether you wish to bear the brunt of the complaints that will inevitably follow, or state flatly that you will not implement such a system.
When all other paths have failed, it sometimes pays to be blunt.

Pascal.

 

[jrbarnett]

Why not ask the designers if they have read and taken into account the Microsoft Windows user interface guidelines (assuming that this application is to run on a Windows platform).

John

 

[TheVampire]

Thanks for the tips people. I really like jrbarnett's idea of pointing them towards the MS guidlines ( since this is a Windows app ). Perhaps this will show them that it's not a personal problem that *I* have with the design ( which is what I think they think.. ).

Oh yes, I always save copies of my mails that I send to them! ( And the receipt saying they received and read the mail ).

Thanks for the book link as well. I'll add it to my list.

Robert

 

[SQLSister]

YOu might try mocking up a prototype of the forms (even just a sketch will do)and asking the actual data entry people to comment on what they expect each item would do and how they would respond if they got no message to let them know the interface had added a record or how they would respond to some of the rror messages which might come up. You could use their comments to show that the actual people who use the program don't understand the design which would mean real problems in implementation. Tell teh designers that doing this was a standard design testing phase of the project!

 

[TheVampire]

I'd love to be able to query the actual end users, but I have been "insulated" from them, so to speak. This may be the customers way of guarding against the dreaded "feature creep", which I can understand in a way.

Robert

 

[jrbarnett]

Re the colour scheme,
You could also claim that you thought it a good idea to use the control panel defined system colours so that anybody who is colour blind would see the system on screen as they liked.

John

 

[lionelhill]

Unless you are desperate, you don't want to make a product that you know won't work. You, not the specifier, will be held responsible. Because when the users start complaining, the person designated to set this up will pass on the blame - it's human nature, and by the sound of it they don't really understand the task.

So I agree, try every nice way in the book, but if the worst comes to the worst, be a bit blunt. At least you won't get implicated in a fiasco.

Actually, from a user's perspective, I'm not grateful at the time when someone tells me I'm being useless, but I am grateful really, in my heart of hearts, a week later.