Skip to main content

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 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.


Popular posts from this blog

Teams and Complexity

Let's pretend you're a car mechanic (I don't know, maybe you are).  But you don't work at some shop in town, you work at a bigtime auto-maker onsite at the factory.  You help build cars from scratch.  You work with a lot of other car mechanics, and various engineers of different levels.  If we were looking at the 1910s, you might be working for Henry Ford on one of the first ever assembly lines.  Either way, you have a specific part of the car you're responsible for.  Your skills probably extend beyond that, and you might work on a different part of the car each day as your manager moves you around to keep the factory efficient.

One of your coworkers, Bob, is a superb engineer.  He is very good at building cars, far better than you, and he does it faster than everyone else.  Your boss really likes him.  You often get stuck after him in the assembly line, so you know exactly what sorts of things he does.  He's not sloppy, but he likes to do things his way.  He w…

Managing Programmers

Working with other programmers is tricky.  That said, it's nothing compared to the job of managing programmers.  One of my favorite quotes about Perl is that (paraphrased) "a Perl developer is like a rockstar.  Now imaging having a bunch of rockstars in one room together and you will understand why you don't want an entire team of Perl developers."  It's not about Perl here though. What's important to understand is that any developer worth his salt is going to be like a rockstar.  And yes, there are a lot of professional developers out there who aren't worth their salt, but that's for another post another day.  Rockstar may not be the right term here, but think of it this way.  These guys are smart.  They may not be geniuses, but there's going to be things that they know that you don't and probably never will.

I've seen it more than once and it's not going to make some Product Managers happy, but I'm going to state a fact, an eleph…

Managing Developers is HARD

I've been a software dev for a long time.  I've also been running my own software company for a few years now.  This is important information because of why I do these things.  I am a sofware developer because I love learning.  I slack off when doing a job that bores me, and software development always has something new to experience which keeps me excited and interested.  Why start a software company then?  That puts me in the role of manager rather than developer.  The truth is simple.  I've worked for a lot of companies, and I don't see any of them doing a great job of managing their software development.  That's not to say none of them have done a good job, but no one out there seems to be doing a great job.

How are they different?
A lot of companies get this part right.  Software developers are different from other employees.  The distinction is important in the same way it's important to acknowledge that an insurance agent is different from a construction…