-1

I will understand if you find this is more a discussion than a technical question and if you close the topic (then, where would be an appropriate place to discuss about that? thank you in advance).

The question : how do you decide between improving the user interface with a great design or adding more and more technical features?

I would like to meet people interested in Windows coding beautiful user interfaces in order to improve an existing (very powerful but not good-looking) open-source project, which has a lot of potentiality!

I know this is probably not the appropriate place for such a question, but maybe you would know a better place?

|improve this question

closed as primarily opinion-based by gnat, Kilian Foth, Dan Pichelman, user40980, Bart van Ingen Schenau Sep 2 '13 at 18:03

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • thanks to everybody for your helpful answers. I cannot vote up for now (since I don't have enough reputation)... which place (forum, etc.) would be great for finding people willing to help me (it would not be long work) on coding a better UI for an existant open-source software? – Basj Sep 1 '13 at 22:14
  • You have a good question there, but it seems that you're more interested in finding someone to work on the project rather than getting an answer. And advertising or looking for human resources isn't welcome here. – superM Sep 2 '13 at 7:47
  • Yes superM, I have both a general question and a specific research, that's why I added the sentence in introduction of the topic + "I know this is probably not the appropriate place for such a question, but maybe you would know a better place?". Do you have an idea for a better place? (It's been a long time I have not been in development, so I don't know nowadays' active places/forums) – Basj Sep 2 '13 at 13:07
  • Since the project is open source, I suggest you put it on Github or some other similar place and write that you are looking for developers in the description. – superM Sep 2 '13 at 13:18
7

If there are usability issues with the current software, then the argument is an easy one. If a significant part of your target users can not complete key tasks or take more time or energy than expected, then you should probably fix that before adding more features. Only a usability test can reveal such issues. Without objective data you will just get endless discussions about taste or gut feeling.

If the UX testing revealed that usability is okay, and this question is more about aesthetics, then it becomes a matter of strategy. Do you want to be the Swiss Army knife, or the designer cork screw?

|improve this answer
  • Nice way of considering this question ! – Basj Sep 2 '13 at 13:14
2

How do you decide? You ask your users. Everything we do in developing software should be about meeting the needs of the users. You shouldn't redesign just for the sake of redesign, and you shouldn't add features that the users don't need.

So, when faced with the opportunity to either add more features or improve the design, the first question you should answer is "what will make the product more useful to the end user?". And by useful, make sure you focus on making them more productive, rather than giving them more features that few will use.

Of course, the world isn't always that simple. For example, you may have a very functional product, but because it is ugly you can't get any users to buy it. So, you might need to consider that the business as a whole is also your customer, and you may need to address cosmetic concerns to improve sales. Even when that is true, however, the bottom line still needs to be focused on the end user.

|improve this answer
1

Make the UI complicated and users will:

  • not use your application as it'll appear too daunting
  • find the learning curve to steep (but may really like it once they know how to use it)

You will also find it incredibly difficult to sell to potential clients.

Making the UI clear probably means that the application will become more appealing to existing and prospect clients, but if the functionality isn't there, then nobody will use it anyway.

I think the answer is: both are equally important and you have to find a way to produce an application which is both user friendly and adds value to the end user.

|improve this answer
  • +1. As a side note, adding value to the end user and adding features to the application is not the same thing: many features are added either because 1% of the customers need them, or because the stakeholders believe somebody would need those features, while having no contact with any customer to learn that nobody needs that. – Arseni Mourzenko Sep 1 '13 at 22:09
1

For me that choice comes down to the purpose of the app.

As a designer turned developer, I always tend to lean on beautiful design that is functional. And any technical features that are added should serve a purpose that makes things easier on the user. Rather then overcomplicating things.

It's hard for me to imagine a scenario where lot's of technical features are needed just for the sake of it.

|improve this answer
0

There is another option that is the best of both worlds. Allow your users to modify the UI to fit their workflow. Every user is different and if you ask your users what they want, you'll learn that if you set the UI in stone, you're going to anger one group or the other. For instance, some will prefer using a keyboard, others will prefer touch screens, still more will prefer a mouse and pointer. Optimize your UI to just one and the other 2/3 of your clients will be raising hell.

Some Best Practices

  • Users should be enabled to customize the UI. This can be enterprise-level or set with user profiles. Being able to trim unused features or bring features into a higher priority location or view is key to having a UI that pleases a wide client base. Exception: The secondary views should probably remain uniform across the spectrum. If someone needs to find something, they should be able to go to the secondary view state and get directly to their destination, regardless of who's UI they are using. Everything should still be familiar. Same goes for the location of key navigation elements such as top-level menus. Keep them in a consistent location on the screen.

  • Lesser-used features should be relegated to a secondary view. The most-used features should be at the opening screen and be afforded more screen space.

  • The UI should be very simple. Easy on the use of heavy graphics, images, and animations. Animations should be rapid and limited to indicating an input was received (i.e. onclick color change), to indicated sending/receiving state, but never to entertain the user. Background animations should be subtle and slow to not distract the user. Or non-existent.

  • Keystrokes that jump to a desired state can save as many levels of clicks as you wish. Clicks are the Antichrist.

  • Be explicit. Don't assume something is obvious because it's got an icon. Design your UI for a child. Give hints, labels, and direction. If a child can figure it out intuitively, it will be a breeze for an adult.

  • Use inactive states. If it doesn't make sense to use a button prematurely, gray it out and focus the attention on what needs to be done first.

  • Individual users could opt for preferred states to appear on start-up that might be different than another user because their role in the business is slightly different. This could save them clicks to get there every time. Exception: The user should easily be able to navigate from anywhere with clarity and a consistent navigation system that is uniform and familiar.

  • Color-code UI elements. Make certain colors have meaning. Red usually means danger. Green usually means OK. Yellow is caution. Blue is action. Black is information. Gray is inactive. Exception: Do not go overboard with colors. The UI should remain uniform in appearance. Group similar items both in location and in color (i.e. breakfast menu with a yellow border, lunch in blue, dinner in red). Exception: Color schemes for functional components should not alter between users, but allowing the user to alter the color of a background element or overall appearance is OK. We see color before we read words, though, and having consistent colors for the same component can eliminate confusion when changing terminals when the same button is blue in one terminal and red in another.

  • Consider modules and extensions for users with specific needs.

|improve this answer

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