16

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.

Github for Windows

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

wget GUI

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

closed as too broad by msp, Matt Obee, Charles Wesley, DA01, Rahul Dec 2 '14 at 4:20

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    Anyone concerned with this should read Mr. Norman's "The Design of Everyday Things". – Almo Dec 1 '14 at 15:52
  • 1
    I make sure to have non-developers involved in the testing process to check out the UI. They find so many little issues that I would've never considered. After a certain while, I'm so used to dealing with the UI however it's designed that I don't even notice issues any more. – Michael McGriff Dec 1 '14 at 17:50
  • @Knerd I remembered where I saw that wGETGUI UI before. The ex-Microsoft engineer and UXer Everett McKay has written a series of blog posts called "Don't Design Like a Programmer", in which he points out a long list of reasons why UI ends up being bad when it was "designed" by a programmer. One example he gives is letting variable types determine control types e.g. booleans map almost too easily into checkboxes and radio buttons, and can result in their overuse. Well worth a read uxdesignedge.com/2010/03/dont-design-like-a-programmer – dennislees Dec 2 '14 at 1:18
  • Knerd, can you try and refocus this question a bit to be more specific? What kind of situation are you facing and what problem are you trying to solve? As it is, your question is just leading to very broad comments from people, which is more of a discussion than a specific answerable question. – Rahul Dec 2 '14 at 4:21
  • @Rahul give me some time, I actually do not have a real problem. I am just interested :) – Knerd Dec 2 '14 at 9:18

10 Answers 10

18

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

  • 1
    Great answer, I had this case just last week monday with my senseo machine :) – Knerd Dec 1 '14 at 14:38
  • 2
    @Knerd What does this answer have to do with detecting bad UI design? – dennislees Dec 1 '14 at 17:00
  • 2
    @dennislees like Zoe's answer it says, that it is a good idea to try to look through the users eyes :) – Knerd Dec 1 '14 at 17:11
  • 1
    @Knerd - Right, but that's hardly ground breaking stuff, is it. Your question about detecting issues during the design process is a good one. The answer "think like a user" doesn't seem to warrant the label "great", at least through the eyes of this user. – dennislees Dec 1 '14 at 17:19
  • @dennislees that is the reason, why it isn't the accepted answer :) I just really think this answer is very good, because that is seriously something I tried just one or two times, failed heavily and never tried again ;) – Knerd Dec 1 '14 at 18:28
16

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.

  • You're absolutely correct. Beauty and functionality don't always go hand in hand. And a functional design trumps beauty. – Mayo Dec 1 '14 at 17:07
  • 3
    @dennislees "Good UI can be ugly" just like Craigslist – Matt Rockwell Dec 1 '14 at 18:15
  • I'm not a UX Expert but I have been in software development for 10+ years and the conclusion is always the same. If you can afford to pay someone to find the perfect shade of blue then good for you but that is essentially pouring money down the drain. The users simply won't care. – Stephen Jan 5 '15 at 19:54
7

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.

3

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.

  • I think this is a great answer. It is about developing empathy for others. Your design might makes sense to you but can your design explain what user's need to do or can do quickly and effectively is the key. A good place to start is with Dieter Ram's Ten principles of good design. Share this with your team and they will be off to a good start! vitsoe.com/gb/about/good-design – Andrea Tate Dec 1 '14 at 12:49
  • Thank you, Andrea. Exactly, this is all about empathy. It's just not everybody knows what empathy is and many people believe this is some inherent untrainable skill whereas it can be actually trained. Another great technic to build up and understand Users' models of mind in the process of development is Personas. – Zoe K Dec 1 '14 at 13:12
  • @ZoeKulsariyeva great answer. But there comes the first problem around, I am not able to think like normal users. That is why I am first developer, then designer. I am able to design pretty apps, but I need a lot of time to go through things and a good friend to help with the user aspect. The last part is the part I would like to eleminate :) – Knerd Dec 1 '14 at 13:52
  • 1
    @Knerd Cheers! I think we all are able to learn this (for some people it's naturally harder, though), did you try various techniques to raise your empathy? There is another way to it — to plant some real users on board and consult with them while developing. And, well, as an Sr UX I can tell you that even if you learn how to think as a user (which is relatively easy, just imagine you are your Grandma), you will still need those user testings with your friend :-) just maybe you'd foresee many things that your friend/users will point out. :-) – Zoe K Dec 1 '14 at 14:02
3

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.

  • 1
    +1 for "You cannot design the UI of your own software without input from another person" Ultimately other people are using your software. Unless you're a software company building for software developers then you have to ask, ask, ask. And, even if you are designing for "yourself" it still makes sense to get as much feedback as possible. – Mayo Dec 1 '14 at 20:17
  • 1
    Dogfooding works well if your target audience is similar to you, e.g. building tools for developers or designers. Dogfooding can bring a negative effect if the target audience has substantially different needs, habits, skills and biases than you do - a common result of such dogfooding is emphasizing obscure features that are very useful for a particular niche use case of a developing individual or team, at the expense of usability or learnability of core functionality that the normal users need. – Peteris Dec 2 '14 at 3:34
2

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.

2

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
  • A commenter on that article mentioned that "Inconsistent capitalization" is another sign of "the dialog". – Jasper May 22 '17 at 21:51
1

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.

  • At the moment there is no specific project,I was just wondering :) in general we use for web stuff bootstrap and pure and we are good with that :) – Knerd Dec 1 '14 at 22:15
1

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.

  • Thanks for the hint, but I love in Germany so that is unlikely :/ – Knerd Dec 2 '14 at 6:40
1

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.

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