UX No.1 enemy

From my experience the number one enemy to good UI and UX is when the interface becomes a reflection of the underlying data rather than the users perceptions and goals.

I once had to test a piece of software that was meant to be an emergency application for when server access failed.  It was designed to run standalone and then the data could be uploaded to the server when it was back online so that network outages would have a temporary method to allow work to continue.

Now the single biggest problem with this software is that the user interface was developed based on the steps the database required rather than the steps that the user should perform.

Uploading the offline data should have been a relatively easy process but instead it was an extremely painful process demonstrating a huge lack of user empath throughout.

Stage 1 was a form to define the offline data outage.  Then there was a second form where you imported the data files.  Then you had a third form to check the validity of the file, then you had to return to the definition to confirm everything is set ok, then select commit.  This is essentially because those are all of the underlying database process that need to take place and they are simply reflected with data entry forms for each of the steps.

The user interface should have been a much simpler process, just select the offline file test its validity and if there are no issues commit the changes.  If there are conflicts then alert the user.  This should take a process from 4 steps with lots of data entry to 1-2 steps with almost no data entry.  All the same processing would take place at the database level, but quite simply the end user should not care they should be lead towards their expected goal as simply as possible.

I see lots of this type of design that the user interface reflects the database, and most of the time this is entirely wrong, and can become embded throughout products.

Comments

Post a Comment

Popular posts from this blog

IE9 Intranet compatibility mode in Intranet websites

So you have written an HTML5 site on your local intranet with some lovely CCS3 and run it up in Firefox and you feel smug, all your HTML and CSS are perfectly formed, but you run it up in IE9 and all the CSS3 goodness has gone away leaving your lack luster IE7 version of your site.   Why is IE9 running in IE7 compatibility mode? IE9 has a hidden setting that forces it to run in compatibility mode when it encounters any intranet websites. Microsoft have detailed this behaviour in a Blog about what they call Smart compatibility mode . You can easily switch off the compatibility mode for specific machines using the internet tools mentioned in the article above, but most of the time developers do not have the luxury of applying corporate wide settings of this nature. Avoiding Smart compatibility with X-UA-Compatible Luckily there is a single line of HTML you can that you can use to override this behaviour: <meta http-equiv="X-UA-Compatible" content="IE=edge,c
Read more

User Interface Usability Checklist Part 2

So you made it through part 1 of the usability check list, how about part 2? 21. Poor Label Alignment If you have been through design 101 you have probably heard of the wonderful acronym for the basic principles of design, C.R.A.P. This of course stands for Contrast, Repetition, Alignment and Proximity. Proximity is very important when identifying which label belongs to which input. Each different form of alignment has its advantages and disadvantages. Left Alignment The label appearing on the left of a box is a common practice. This often helps with vertical space and keeping all of the elements of a form on a single page, which can be beneficial in aiding the user in form completion and making them aware of all of the possible options they can, or made need to provide information for. It does however have a few disadvantages. Long labels cause short label's input boxes to be far away from the end of the label, this damages that basic principle of proximity. In extreme
Read more

Procedural VS Object Oriented

What is the correct way to write code? If you have worked with PHP long enough you may well have come across the website  PHP The Right Way . This website is dedicated to helping developers learn the industry best practices. Interestingly another site appeared afterwards called  PHP The Wrong Way . In essence this website is a rebuttal to the many of the recommendations made in PHP The Right Way. With any sphere of learning it is important to keep an open mind, to listen and critically evaluate the received wisdom and determine if it is indeed wisdom or opinion built on shaky ground. There is one part of the argument I would like to focus on and this is the argument for and against " Always use object-oriented Programming ". While PHP The Right Way does not appear to explicitly state that you should always use an object oriented approach it is implicit from the examples and the recommendations to use design patterns. While there are programming approaches available othe
Read more