3

Inspired by this previous question on UX SE: Good reasons to use bad UI? I asked myself the question, "Are there bad reasons to use good UI?" And just to clarify, I am talking about UI design and not UX design here.

The person who asked the first question gives the QWERTY paradox as an example, which I think only makes the argument from the existing user's perspective, which I believe that the convention wisdom is to weigh up the existing dependencies on the QWERTY standard and the continued cost of inefficiency for future users (which people don't look into enough for various reasons). This is basically the "if it ain't broke, don't fix it" argument.

It seems like the opposite statement of this question is also valid to ponder, as good/pretty UI sometimes takes away the problem of a bad underlying process, system or architecture temporarily, allowing users or companies to resist changing their solution even though a problem does exist.

So the question is whether a UI that reflects the underlying system/process is a better UI design compared to one that tries to cover the problems with a visual or interaction 'fix'? This is basically the "if there's a problem then you should fix it" argument. I believe that if you are only limited to working on the UI, then we should aim for the UI to reflect the way the system works so that the problems can be more clearly identified for a proper UX design to be done and reflect the way the user's mind works.

  • 1
    The "If it ain't broken, don't fix it" argument is a heavily flawed one since it assumes binary nature - that things are either broken or not - where in practice it's all a spectrum. You will fix your windscreen if there's a chip on it, albeit not broken. And do I hear someone saying 'code refactoring'? – Izhaki Jan 6 '15 at 23:04
  • And more on QWERTY. – Izhaki Jan 6 '15 at 23:06
  • Great question BTW. Definitely unique, yet so obvious and well-asked. Bravo for a good question! – DripDrop Jan 7 '15 at 0:48
  • @Izhaki Do you think it is possible to deliver good UX with poor UI? Or deliver good UI with poor UX? I would consider using UI to solve underlying system issues is not actually UI design but UX design because the system is still the problem and only the perception or the experience of the user is been changed/manipulate. – Michael Lai Jan 7 '15 at 3:21
  • You can't deliver a good experience if the UI is poor. (You may, however, be able to deliver an adequate experience). You could have a great UI but bad UX, though, as UX can encompass much more than just the UI. – DA01 Jan 7 '15 at 4:26
1

I think this is perhaps a bit of the 'lipstick on a pig' situation.

I agree with you in that the ideal UX incorporates a UI that is compatible with the business logic and technology that's running it.

I'm often asked to design 'the ideal' independent of the particular technology. This can be a fun exercise, but rarely produces a result that is optimized as much as it could have been had the UI design taken into account the system it is sitting on top of in the first place.

A hopefully clear example from a previous project:

The client wanted a more 'google-like' search experience with a single field.

This particular field was to search a person's name. As we were tasked with designing the ideal, we gave them a single field.

However, the underlying technology wasn't there to handle a single field easily. In the database there were first name fields, last name fields, some had middle name fields, some prefixes, suffixes, etc. And the data wasn't edited in any way, either. Sometimes a ", Sr." was added into the last name field along with the last name.

What happened was that because it was a single field, with no obvious way to parse the name into first/last/middle/suffix/prefix, we had to do a massive wildcard search across all fields based on individual words in the search field. This, as you can imagine, impacted performance, and also returned massive amounts of irrelevant data.

Had we been able to design to the technology in the first place, it would have been quite clear that we needed a two field solution (First and Last) to make the parsing more foolproof.

Less ideal from a UI perspective, but much better from an overall UX perspective.

  • I guess that means if you are going to put lipstick on a pig, then you have to also dress it in a skirt and tie a ribbon around its tail. I always thought that regardless of what UX means, UI design is still about balancing usability and utility, so making something usable but not useful is just as bad as something useful but not usable. While making something look nice is a completely different issue. – Michael Lai Jan 7 '15 at 2:33
  • @MichaelLai consider the analogy a bit more abstractly. It's trying to make something out to be something that it really isn't. It can apply to aesthetics as well as usability and utility. – DA01 Jan 7 '15 at 4:23
  • Ideally you would have been able to re-engineer the underlying technology. Addresses are my absolute favorite, odd balls like 5715 95th st sw #P211 is about as odd an address I've ever HAD, but I've SEEN weirder. Ultimately, I just assume that any address with less than 2 spaces and no "number only segment" is a lie and reject it. – Patrick Pease Jan 7 '15 at 4:46
  • @PatrickPease yes, that would have been the best solution. The next best solution would have been to design a UI that catered to that particular underlying technology as best as possible. The worst solution is the one we came up with...an idealized UI that has no real relation to the technology it's on top of. – DA01 Jan 7 '15 at 4:56
  • 1
    @PatrickPease yea. I've found in larger companies, Front End Dev is actually a forgotten role. The IT teams typically have no interest or strong skills in it. The UX teams rarely have interest or strong skills in it. So it just gets lost in the middle. Ideally there'd be a dedicated Front End Dev team that would work within UX and along side of IT at all times. – DA01 Jan 7 '15 at 5:07
0

Good Question. Personally, as a big fan of UI design, I would say it is in fact better to use a good UI, using 'fixes'. I say this because old user interfaces like early windows versions (Win3.1, Win95,etc.), were SO hard on the eyes (See Below)

Windows 3.1,

While new interfaces (Take for example the Windows GitHub client (See Below), Utilize the flat modern trend, and make their data easier to look at, and ultimately easier to use.

The GitHub Client, Using A Flat Interface

This also raises the question 'should you ditch the underlying GUI altogether?', with the answer being no. You DEFINATELY not make a program that looks entirely different from the underlying OS (Take for example a flat program on Windows 95). I recommend using at a bare minimum the colour scheme of the underlying OS, to make the program blend better with the operating system.


Good Luck!

Thank you for reading my o-so-long answer. Sorry it couldn't be shortened.

  • 2
    A lot of people see the UI as the bottleneck or problem that needs to be solved rather than the underlying system, so problems that exist which are partially solved by good UI design doesn't get fixed because it is less of a problem with a 'fix'. Do you think about good UI design as treating the symptoms rather than fixing the underlying cause of the disease? Thanks for your answer. As designers we should all spend more time thinking about what we are doing, so good on you for taking the time :) – Michael Lai Jan 7 '15 at 1:02
  • 1
    @MichaelLai that's also a great question, but likely a different question. Great UI design should be done in tandem with the underlying system architecture. When it's not, I think you're absolutely correct that one is typically just treating the symptoms. – DA01 Jan 7 '15 at 1:30
  • Good question... Treating the symptoms is the only logical way, as the underlying cause is not always changeable. One cannot simply change the underlying operating system to make their program fit, so making your software look good is the easiest and most logical solution. Good observation. – DripDrop Jan 7 '15 at 2:31
  • @DripDrop I'd argue that the logical way would be to change the underlying causes. But I do realize that's not often a luxury in a lot of situations. – DA01 Jan 7 '15 at 4:24
  • 1
    @DripDrop You've made a good case for designing first, and coding after. – JeromeR Aug 22 '15 at 23:20
0

Good ui comes from a well thought out back end. I can make the interface as simple as the technology allows, but if my back end forces me to ask you to choose 1 out of 75 options then the best interface possible will not result in a very usable product.

Now, if the technology gives me (the front end guy) awesome tools so that I only have to show you 3 options (a human optimal) then that app will generally see much greater adoption and utilization.

0

In the simplest terms, [Strictly avoiding UX terms and references :)]

A good UI is the one that allows the user connect with the application/system. By "Connect" I mean a combination of - pleasant to look at, easy to work/move through and willing to come back.

The coming back part may be due to "I liked what I saw, I saw something unique etc.."

This can be either by the underlying system/processes or by a solution the user is looking for or a little bit of both. Based on what you are building.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.