The UX Problem

Today I'd like to talk about a serious problem with internal applications.

The sad truth is that it's much worse than this.  That app is an extremely lightweight version of how these things really turn out.  I am by no means a UI/UX guy, but I can tell you that while 90% of the time, the developers blame the politics and the users for this horrifying result, the reality is that this is the developer's fault.  The devs have to fix it later anyway, so it really does fall on the developer to get rid of this convoluted crap and make it work right.  I've been building one such application recently, and I'm planning to rewrite it now that it's a horrifying mess of spaghetti code.  So in preparing for my rewrite I've started laying down some ground rules.  And I think I might not be the only one to benefit from them.  So I'm sharing them with the internet for all to see.

Rule 1: Don't display information the user isn't using.

This may sound so simple, but even in the example above the app is showing codes instead of text.  Seriously, if your user is seeing IDs from the database, you've done something horribly wrong.  The user doesn't give a crap about the numbers, and if they do, they've only learned to live by the numbers because the developers have trained them to do so.  Some users are so well trained that they don't even trust the text any more...That's just wrong.

Rule 2: If it's never enabled, don't make it look like a field

It's almost depressing that I have to say this, but there are some fields that the user is never going to change.  In the above example, the user's account # is displayed in a text field which is then disabled...as if the user was capable of changing it!  It's absurd.  Information is text.  Fields are for changes.  Don't mix the two.

Rule 3: Tabs are for organization, not so you can double your screen space

Seriously.  You don't add tabs to the product because the screen isn't big enough.  If that's the case, there's too much data on the screen.  Tabs are a way to segment data, organize it into small bite-sized chunks.  Not to take War And Peace and separate it by chapter...unless this is a book app, in which case that's fairly creative.  You get the idea.

Rule 4: The user isn't always changing things

In fact, most of the time, the users are going into your app just to look at data they entered previously.  If that's the case, why are you always giving them editable fields that are bulky and take away from the content.  Editing is not the same as viewing.  If you're always allowing the user to edit, they will, and your data integrity will suffer for it.

Rule 5: Color simply

Less is more in the color world.  3 or 4 main colors are really all you need in your app...and that includes white.& black which are your text world.  Do not get fancy with text, don't color fields red to indicate that they're important (if that's the case, why are you displaying all the unimportant fields?), don't think that each page needs a new color scheme.  KISS.  KEEP IT SIMPLE STUPID.

Rule 6: Scrollbars are ugly.  One is more than enough.

The only reason to put a div on your page that has it's own scrolling is because the rest of the page needs to remain fixed.  If there is a nested scrollbar monstrosity, you have done something horribly wrong.  If your content is long (like a book or blog) then the browser will provide it's own scrollbar.  In the case of blogger, I"m entering this post in a div with a scrollbar of it's own, which means that there is no scrollbar on the page, because all of the buttons for editing need to be visible all the time.  That's how it's done. Bravo Google, but we already knew that didn't we?

Rule 7: Tables should be small in both height and width

Don't use tables for style.  When you need to display data as a table, do so in less than 10 rows and less than 4 columns.  Your users will surely want massive data dumps though, right?  Export to CSV.  Let them play with Excel.  They like doing that anyway.

Rule 8: Use the right tool for the right job

I cannot count the number of times developers place 10 checkboxes and then forcibly uncheck them all when the user clicks on one.  If you need a radio, use a radio.  If you're not sure what tool you need for the task at hand, remember that you're not the first person to do it.  Someone else has probably done it better.  Do some searching.  You might be surprised.

Rule 9: Newer is better, but don't ignore browser compatibility

You can't ignore IE.  Your company surely installs it for the users as the default.  But that doesn't mean you can't use the latest stuff.  JQuery 1.9 is still compatible all the way back to IE6 or so, so you can use it's features to make up for what CSS3 and HTML5 would do in more capable browsers.  JQuery UI gives nice clean layouts with gigantic fonts that keep you from adding too much content.  Maybe consider leaving it in the defaults rather than shrinking it down to make all of your text fit.  There's nothing more exciting to users than their first time seeing a JQuery UI button instead of the default for their browser.  I'm not joking.  I'm speaking from experience here.

Rule 10: Don't ignore your users, Interpret them!

I am by no means suggesting you ignore it when your users tell you they want the button "Right There" (and I wince when they poke my screen).  But the truth is, your users don't know what you're really capable of.  They are treating you like they would their employees whom they're smarter than.  You're smarter than them, so it's your job as the more intelligent one to understand the WHY and make it the way they don't even realize they really want it.  Don't correct them, just ask for more clarification.  Once you know how they're using things, you'll understand what would make their life easier in the end.  That's the real goal of UX after all.

This is by no means a complete list of my rules, but just some of the ones off the top of my head that I needed to write down before the information started to overload and make me forget.  Feel free to add your own rules in the comments for discussion.