Same same but different
Have you ever discussed a problem and said: well, when you implement X, I want it to be/look like Y. That does not work. It becomes same same but different.
For example: we have address fields on multiple entities. If they looked slightly different, that would be same same (all are address fields) but different (since they perhaps weren't placed the same way).
Is same same but different important? Well, like with spelling it depends who you're asking. Myself, I wouldn't make an order from a company who can't spell (if they cannot even spell the most common things, what says that everything else works as it should...) Others doesn't even see it.
Is it a problem: well, since the business value of fixing these "little things" are hard to calculate, especially for people not being bothered by it, it seldom gets fixed. And the result is an aggravated situation: for every instance of same same but different, it becomes more and more unclear what is right. And than you get chaos.
So, my advice: of course is it to fix it at once. Every time. Saying "I'll fix that later means IT WILL NEVER be done. Never. And since looks is first expression, it will always be noticed by someone. IT doesn't take so much time if it's always done but cleaning up afterwards takes forever.
Labels: usability
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home