Is the user interface a valid indicator of internal quality?

When looking at the countless types of software written in our company, I immediately jump to conclusions about the quality of the entire product based on the user interface. If I find errors, strange tabs, margins not lining up, odd colors, I assume the whole application is of poor quality.

My guess is that if the programmer doesn't care about the look and feel that they don't care. I am NOT suggesting that the user interface looks good, that the application does what it needs to do, although I don’t jump right at it - it gets more options when evaluating.

Is this a valid solution? For commercial software?

0


source to share


10 replies


I think this is a good indicator of the care that a developer takes for their work - mostly a sense of professional pride.

This is something that most developers don't create fantastic UI designers, but there is a basic set of rules to follow when designing professional software, and they apply to both UI and internals.



So basically I agree with you.

+3


source


It may or may not be. But this is not very relevant. For your end user, crappy UI = bad code.



+5


source


IF the app was written by a single developer, it is not an unfair assumption that an unscientific user interface indicates the quality of the underlying code.

However, if it was written by a team of 5 or 7 or 13, there is likely to be a wide range of quality under the hood (just as that might be given to UI beginners).

Also, if an application is designed to last 5 years in its lifecycle and maintenance is done by contractors or FBN trainees or anyone else who is comfortable with it, you can find a lot of good code under the hood that slowly rots due to indifferent managers and undisciplined developers who just throw a "patch" on it, compile it, check it in and throw it on the wall for production.

A crappy user interface can be indicative of many things, none of them good, some worse than others.

+2


source


This is a valid solution in my opinion. And you are right when you say that good software is not necessarily good software on the inside.

But definitely, if programmers don't care about the usability of a program, they probably won't like it.

0


source


As much as I really want to say, "Yes, absolutely," this is not always the correct conclusion. A programmer or QA team may have a great understanding of the application, but a terrible understanding of the language or presentation.

Some people just focus on what they think is important and get it close enough to perfection - all but ignoring what they think is "fluff" or "window dressing."

But I have a very strong tendency to judge the overall quality of software in advance based on first impressions.

0


source


If the UI is riddled with typos and inconsistencies, it's probably fair to say that the QA process and project management is a little lacking. Doesn't really mean the codebase is riddled with bugs.

In a commercial product, this likely means fewer people will buy it, so while sales are not really an indicator of quality, they are very important in the overall scheme of things.
 People are more likely to buy things that look good, behave the way they expect them to, and "Don't make them think."

Many programmers suck on user interface design, and that is not their fault, that does not mean that they suck at coding. They are simply more interested in the inner beauty of what they do, otherwise they would be great specialists in the humanities.

0


source


It really depends. I know software developers who are great at all aspects of design and implementation but have lousy user interface skills. Many times the user interface is an afterthought as a nod to the user. In the case of scientific software or other software where processing is central or key, it would be a good idea to evaluate the quality of the rest of the code in the user interface. Overall, however, it can be a good indicator that the software company hasn't done a good job.

It all depends on each case, but if the user interface is not used or a pain in the neck, then the main code is more difficult to use and not worth the time I suppose.

The opposite is also not true - bright, beautiful user interfaces don't mean that the underlying code is good. Anyone can wrap a piece of junk with a good user interface.

0


source


I would agree with the masses here. Poor user experience means the product development team has dropped the ball. I consider myself a good coder. Excellent in math, but dyslexic and attention deficit. Give me a set of headphones and some code and I'm on my way. However, don't expect me to be mocking a great GUI. Linear affairs ... It's me.

Now add to that the fact that as a "programmer", even when I see things in the GUI that are giving me shit (as the person who uses it), I cannot fix them .. Hell when I fix them, I get QA, demanding from me a project document and high-level approval. After a while, I stopped caring about the GUI.

I am writing solid code that works. It's fast, clean and small .. this is where I get hit. The GUI is beyond my pay tier. :(

0


source


In my experience, this is usually the other way around. You get a quality user experience by having people spend "huge" amounts of time focusing on widget behavior, and you also feel like a domain model or automated tests.

Some of the best quality systems I've worked with were auto-generated user interfaces, which were pretty frustrating to use.

0


source


No, the user interface does not point to internal code. A lot of times we come across things that look cool and shiny but have no purpose. Think of it like Ferrari parked in a store. It looks amazing, and you wonder what it would be like to get behind the wheel - only to find out that it was a body kit that was applied to a late 1980 Acura model that's 500,000 miles away.

A personal example, from my current employer, we have stellar code in our software (and I say this subjectively, since I was not there for 99% of creating it). But when you look at our interface, it might seem a little old and rusty. That and many times UI designers don't even touch on a lot of internal code.

“I assume that if the programmer doesn't care about the look and feel that they don't care,” I don't believe it's true. I think most programmers are looking for functionality rather than brilliance, as they tend to be logic creatures and not artists.

Take linux as an example - stellar backend code, but the UI has been out for a long time, so none of the main thread has used it extensively, unlike Windows or Mac.

Short version :! UI.Equals (InternalQuality)

0


source







All Articles