What UI design principles like “separation of concerns” can I use to convince developers that the UI needs fixing? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 5 years ago.

I　had a big discussion with team recently related to UI design for our recent software project.

We need to integrate a special version control system into our existing product, which is a software testing tooling for testing by writing and playback testing scripts.

The design team has come out with a design which I can't agree on, and think it against basic design rule.

The biggest problem of the design, from my point of view, is that they add version control special things (like create a view, check in/out script) into our existing UI (actually copy existing UI　and change it another and add something on). For example, in our Open Project dialog, copy the UI then add two button to trigger special version control thing (like before open script. must have a version control view that contain the project source code).

I argued a lot with the design team that this is a bad idea to put different things together, in our example, the software testing tool feature and version control script feature. And I　explained that by doing these will come out duplicated UI, and more situation for the same to solve, also maintenance big problem. And I prefer to separate the two from UI, one UI (a dialog or wizard) should only focus on only one of the two different things.

I summarized as a UI design principle that "one UI should not contain two totally different things". While they argued that, they want to pay such effort and all side effort (like more UI, more situation for the UI to solve, more dev/test/maintenance effort compared to a UI design that separate the two different things), for user to get a easy to use and good usability software. Of course, I totally disagree with such declare, how can an software not good in every other aspect be good for user? And there is nothing to measure as design team has no full design yet.

And it end up with i can't convince the team. Everything seems still objective.

This has lead me to think , is there any good UI　design guidance/best practice/principle that covers our situation (to separate different concern,in detail debug/run script needs and need to version control script, by not to put them together in one special UI, dialog or wizard ,etc..)

I would appreciate any comment, and suggestion,related to the whole problem, not special to the question above. also i will answer anything i didn't express well here.

Please don't close this:) this is really BIG problem for me as a dev manager.

Answer 1

I agree with @JanNeilson that design principles won't help you convince developers to change a UI design.

What works is usability testing. Watching a few users get stuck trying to use the software will make developers squirm and want to fix the UI. On the other hand, if you see that real users can use the new software just fine, then there is no problem, and the design principles don't matter.

Usability testing can be a formal process where you bring customers into a lab, ask them to do specific tasks with your software, and record video of the user and the screen.

Important: Be sure to tell the test users that you're not testing them; that you're asking them to help you test the software. Explain that you won't be offended if they don't like the software. You want honest reactions. Periodically ask them to say what they're thinking, i.e. to "think aloud" as they figure out what to do. Don't answer their how-to questions unless they get totally stuck.

Usability testing can also be an informal process where you ask some random coworkers to try it out. I've done this in the cafeteria, just showing some coworkers a new UI and asking what they think some new icons mean (represent).

Take notes during or right after each test. You can have the developers watch the recorded video afterwards (edit out the waiting parts so the developers will watch it all), or watch the video from another room during the test. Or without the video, you can bring one developer at a time into the room to watch, but ask them to sit on their hands. The developer must not answer the user's questions without first saying "I'm sorry I built such a lousy user interface."

If your software is not ready to for this testing, you can do usability testing with a paper mockup.

There is an entire field devoted to usability testing. There are well trained experts. You can bring in experienced consultants to do it or learn about it and try it yourself.

A web search turns up many articles and books. Here's a very good article to begin with: http://alistapart.com/article/usability-testing-demystified

The first paragraph from Wikipedia on usability testing says:

Usability testing is a technique used in user-centered interaction design to evaluate a product by testing it on users. This can be seen as an irreplaceable usability practice, since it gives direct input on how real users use the system. This is in contrast with usability inspection methods where experts use different methods to evaluate a user interface without involving users.

I added the italics. In other words, you cannot get good usability without usability testing. In contrast, having experts evaluate a UI using principles and experience can help but is not essential.

Answer 2

You touch on several different aspects in this question; I'm going to focus on the management of the UX.

Instead of arguing generalities like "separation of concerns", I review specifics issues with a particular UI design, both from a UX perspective as well as more abstract or general notions. To do this, you will need a UI mock-up. And prior to the UI mock-up, you will need a basic set of descriptions of the intent of the UI which will drive the UI mock-ups. Once you the UI mock-ups, then you can talk through the use-cases for the UI and highlight why a UX issues is concern because of separation of concerns or other specific principles.

In my experience, it is ineffective to argue the generalities because those who understand it don't need to hear it and those who do not understand it, need the mock-up to have sufficient context to understand.

If you are concerned about the resources necessary to build the mock-up of the UI, you might consider time-boxing the effort, e.g., "take 3 hours to put a mock-up of the UI together on paper and let's review."