How to detect bad UI design [closed]

Question

I am a software developer who also does UI design. My question is, is it for me possible to detect UI issues during development. The big problem I know from other developers, they don't see bad UI design, cause they can use it. Same for me.

Here is an article from Phil Haacked, which I'd like to take as reference:

It is just about the first two paragraphs around the pictures, which says:

GitHub for Windows (often abbreviated to GHfW) is a client WPF application written in C#. I think it's beautiful.

This is a credit to our designers. I'm pretty sure if I had to design it, it would look like

The last picture is, how I see developer designed software a lot. My point is, can you detect issues during the design process?

Answer 1

Think of travelling to a new place and being lost, and being frustrated and worried because you don't know how to go where you need to go. Imagine your car, dishwasher or stove is causing you problems (or any device which you care nothing about - only having it work) and then you will start having a feel about what most computer users think about computers and their apps.

Your users don't care about your app. They just want it to work. If you keep that in mind - and find a place within you that reaches that - then you've taken the first step towards good UX design

Answer 2

UXD is Bad UI Detection

User Experience Design itself, when effectively practiced, could be described as a methodology for "detecting bad UI" (when the concept of UI is applicable).

A fundamental reason to practice user-centricity in the form of empathetic problem solving, and use an iterative continuous-validation design process, is to detect those aspects of the design that are "bad" and remove/improve them.

Don't Confuse Bad with Ugly

The quote you dropped in from the Haacked article makes reference to "beautiful" UI. In most cases, it's not important whether a UI is aesthetically pleasing. One of the biggest (and most disappointing) lessons I've personally learned from surveying users is that they are usually much less sensitive to how things look, than to how they work. (The first time I researched this I was looking for data to back up my case for a redesign, but the result that came back was pretty clear - users didn't care).

UI is "bad" when it creates a barrier between the user and the their goals - Good UI can be ugly.

Answer 3

The best way to detect usability issues with your application is observing people actually using it.

However, even without user testing a lot of design errors can be found with Heuristics evaluation.

The most used design heristics are probably those developed by Jakob Nielsen.

The ten Nielsen heuristics

1. Visibility of system status
2. Match between system and the real world
3. User control and freedom
4. Consistency and standards
5. Error prevention
6. Recognition rather than recall
7. Flexibility and efficiency of use
8. Aesthetic and minimalist design
9. Help users recognize, diagnose, and recover from errors
10. Help and documentation

The rules are explained at the website of the Nielsen Norman Group.

By checking your application against these ten rules you can find and prevent a lot of errors in UI design.

Answer 4

While others stress empathy, and ability to view UIs from other perspectives, I am going to be less nuanced:

• You cannot test your own software, and as a corollary:
• You cannot design the UI of your own software without input from another person, hence
• Great UI designs are much more likely to result from an iterative process involving (non-dev) outsiders than from any other kind of process without their involvement.

Reasoning:

• Developers' mindsets are statistically different. You can be great both at UI design and at software development, but the chances for that are statistically very low.
• UI quirks are qualitatively the same as subject matter ("edge case") bugs found by QA - a developer's perception is often hopelessly biased and tends to discount bug reports and negative UI reviews (GNOME 3 and Windows Metro interfaces are prime examples).

---

Please also note that the pictures you post in your question are factually misleading - not because they were developed under different frameworks, but because they describe different workflows/levels of mastery/complexity levels. A wget GUI wraps a batch operation workflow, a GitHub application is much more interactive. Apples to apples, they say.

---

Note #2:

The above does not mean I disparage the importance of "dogfooding" (using your own software) - it's obvious that the emotional investment built during "dogfooding" helps to motivate further development of expert-level features. You simply have to listen to your users, QA testers and UI experts and value their experience more than your own.

Answer 5

Absolutely. To be able to do that, you need to recalibrate your brain slightly to know users' model of mind. It may sound scary but it isn't. Think of it as running a virtual machine with some OS that you don't typically use. Just the machine you are going to run is going to be a generic user, a Layman. This model of mind will be entirely different from your own. Different MOs, different values, different experience and different way of thinking. What you understand, they don't. What you know, they don't. You have time for this, they don't. You might like this feature and find it useful, but they may not.

The simpler design is, the quicker it gets user from point start to finish, where finish is some user need satisfied, the better it is. By answering what would make your users happy and what would deliver them from [over]thinking you can do better design and better UX. To answer those questions, you need to understand your users.

Run every development iteration by this user virtual machine, and soon thinking from perspective of user interests will become automatic and intuitive for you.

Answer 6

The very fundamentals in creating good user interfaces is to be able to view them from other user's perspectives - not from your own. If you are a user of the software it can be a good thing, but don't expect others to see the product as you do.

This is the basics of why programs designed by the programmers often ends up hard to use for "regular customers" - they haven't programmed the product, hence they know little or nothing about how its working internally.

To read more about this - check out "user mental models" and "implementation models". Basically - it's about how users see the model vs. how it's really working.

Answer 7

From Joseph Cooney's article about 'Developer UI':

Here's my quick checklist of things to look for if you're trying to avoid create "the dialog" yourself:

• Strange aspect ratio/portrait aspect ratio (I think portrait just looks odd for dialogs, except maybe property-page style ones)
• Lots of controls (because you've allowed too many options)
• Controls of same type with differing sizes near each other
• Non-standard behavior for controls (checkboxes that function as hyperlinks etc)
• Non-standard placement of controls
• Looks different to every other screen in your application
• Options don't seem very cohesive
• Lots of explanation required for options
• You wish you'd just used a property grid, or think you might need to add just one more tab

Answer 8

This is difficult, in that it depends a lot on the size of your team, and the roles of the people in the team. It also depends on the target platform of your product/service.

If you can get to a point where your developers are following a set of conventions (patterns/rules) about how to implement functionality for the specific platform, then you've made progress. You can sometimes find these "patterns/rules" for specific platforms (see the Apple user interface guidelines, among others). For web development it is a bit harder (there is a lot more freedom). The developer community has tackled the problem through frameworks like Bootstrap (for better or worse), that provide a consistent look-and-feel.

In the end it is about educating your development team on UX best practices -- an ongoing task that they are already familiar with for their day-to-day development (coding) work. Think "design patterns", but for interaction design. Your question is about "detecting" bad design. You can perhaps start with detecting the biases in your own designs, by investigating how they violate the guidelines for the platform (and motivating why it matters). The more educated the team gets, the easier it will be to detect "bad design".

If your team is not fortunate enough to interact with users, then instrument your application to provide as much usage information as possible (with the necessary privacy protection of course). Analyze the results for usage patterns, and iterate on design. If it is an online application, and you have the infrastructure, perform A/B testing.

Once you've settled on a consistent design (both functionally and aesthetically), you can focus on building the more expensive automated integration tests to ensure that you don't "break" the design (although there is still no automated way to detect that you are following design conventions, as far as I know).

Hopefully this will fit within the time/budget constraints of your project. Perhaps try to get feedback from other teams that have struggled with similar problems. Like I said, it all depends on the organization and the team. If this is something that interests you (which I assume it does), then perhaps you can take ownership of this part of the development process, and help to educate your team. It's not always easy, but you have to start somewhere.

Answer 9

If you can make it out to a DevExpress UI Roadshow, they do a very good job of educating developers on UX, and the training is free (as long as your boss lets you go to it during work hours). I attended their training a month ago and picked up a lot of pointers.

Answer 10

A number of answers cover activities at different stages. There are numerous opportunities "to detect UX issues during development". UX work should be done at discovery, design, implementation, test, beta and over iterations of the software.

What is important is to have a reasonable technique to guide you at every step of the way. UX benefits from getting attention at each step. For example:

• Discovery & analysis: Model the user (Persona) and their domain and goals

• Design: Heuristic evaluation, paper prototypes. Also competitor analysis

• Implementation: Hallway test. Standards, consistency and patterns, true to design and performant
• Test: User Tests and Beta feedback
• Iterations: Collect and act on real world knowledge

The security mantra of "defense in depth" pretty much applies.