Do we need to make the user-interface look good (adding images, animations, etc.) for a program internal only to the company?

Making the user-interface look good might slow the performance of the software, slow the development process, add maintenance cost, and slow the user process, but it also might encourage developers/ux to perform better, encourage the users to perform better.

Will it be all right if the UI was like designed by a preschooler, or should we make the UI grande? Is there any UX cost-benefit analysis about this matter?

Do you want to look like a professional or a preschooler?
–
BarfieldmvApr 13 '12 at 9:58

29

No, you can force bad software upon your employees. In fact, most companies do.
–
DA01Apr 13 '12 at 13:23

9

@DA01 True, but if the option you force on them isn't one they want to use then often people will find alternatives which are then beyond your control. Companies still force IE6 on people, so they work around this by installing Portable Firefox on a USB key and using that instead. Then the organisation has no control / awareness of what applications are being used. If the app you give them is one they want to use then you don't have these issues.
–
JonW♦Apr 13 '12 at 13:50

3

Where is the line between the "good looks" of the interface and the quality user experience that isn't grande?
–
boisvertApr 13 '12 at 14:09

6

By "good looking" do you mean aesthetically pleasing? There are a lot of aspects of making a good UI that have nothing to do with prettiness, i.e. TAB order of the controls in a window: do they follow a well thought out order or does focus jump all over the place? Clarify if you are asking about looks or about functionality. I'd advice functionally you should spend effort in making a useable UI.
–
frozenkoiApr 13 '12 at 21:57

22 Answers
22

There isn't any difference between internal products and products for customers because everything is used by real people.

Sure, some executives will think that they can cut a corner here & there on design of internal products. Unfortunately, they're forgetting that a second lost here and a second lost there as a result of a poorly-designed software workflow will add up to minutes/hours/days/weeks/months of lost productivity over the long term, which means higher cost than an extra day or even an extra week of development.

Thus, just like the design efforts for customer products, the design efforts for internal software should be focused on making clean interfaces that follow the natural workflows and where nothing can be removed to simplify them.

The results showed that the beauty of the interface did not affect how users perceived the usability of the shops: Participants (or Users) were capable of distinguishing if a product was usable or not, no matter how nice it looked.

I agree that internal tools should be very well designed too. And from my experience companies are more and more realising that. however: when talking about app design, I look at apps that are sold through the AppStore a bit differently than - let's say - an internal sales tool. As said - the tool has to be really good from a design perspective too, but I would not put as much effort into UI polish as I do for an app that must produce revenues through the AppStore. You know you audience very precise in such internal projects.chance is: they maybe won't appreciate or recognise the effort :)
–
HeikoGApr 13 '12 at 7:39

3

+1 for the part about not being fancy. Given the specific wording of the question I would have simply answered: "No."
–
Joshua DrakeApr 13 '12 at 13:22

2

Agree. Having images and animations by itself certainly doesn't make interface more usable. You can make interface clean and easy to use without such measures, and without hurting performance or “user process”. And UI of an internal product, as of any other tool, definitely shouldn't be “grande” or “good-looking” if it means that the UI will attract more attention than helping to get things done.
–
Anton StrogonoffApr 13 '12 at 18:17

1

I agree with @HeikoG that it makes sense to polish your apps more than internal tools—apps often provide more entertainment value than utility, and you can win more users by providing more ‘polished’ UI (and having more users is important). While with internal tools you already have your user base—this makes things a bit different.
–
Anton StrogonoffApr 13 '12 at 18:24

3

Found a paper this afternoon that reminded me of this question and this answer. The results go along the lines that @dnbrv mentioned -- the usability of the interface is more important than the aesthetics. A clean (or even slightly unseemly) UI that is usable is better than a pretty but confusing UI. mmi-basel.ch/download/pictures/cf/…
–
Andrew ShipeMay 15 '12 at 2:37

You need to distinguish a good-looking, aesthetic design whose goal is to make the product easier and fun to use, from a "sexy" design whose goal is to market the product, have it featured in Smashing Magazine showcases, and have people send it to each other going Wow. The latter you don't need in an internal product, and it might do more harm than good. The former you do need.

+1: There's definitely a big distinction between 'pretty/sexy' design and a functional design for internal systems. Make it easy to use at first and you can always spiff it up over time.
–
Andrew ShipeApr 13 '12 at 15:40

Yes. I have standards and want to do my job well. Asking me to cut corners compromises the work ethic, and I am not going to put as much effort in if you ask me to do it badly.

The answer from the user

Yes. I have to use this, potentially frequently. Ugly software cripples my experience. An intuitive and simplified interface will help me learn faster and remember the features of the product, and I won't put my fist through the screen in anger when the product is well designed both visually and functionally.

The answer from a well informed business man

A company runs smoother on well designed software. We will receive less complaints from our users, which in turn means less maintenance. It should also aid in speeding up our business process as users are more effective with the software. We will make a return on this perceived investment.

A company's worth is highly affected by the worth of its assets. An assessment of our comapany's worth includes the software assets which we own. A well designed software product is worth more than the initial investment. That's how companies profit from hiring programmers afterall.

There's ample evidence that "making a user interface look good" contributes significantly to the interface's usability and user experience. Kurosu & Kashimura showed the link between visual design and usabiliity way back in 1995 (PDF) and Tractinsky found the link even stronger than expected in 1997.

Since then, there's been a ton of research that shows visual design and aesthetics influence everything from user satisfaction to perceptions of system quality to ease of use to usefulness (PDF). Don Norman sums it up quite nicely: attractive things work better.

The trick, of course, is defining what "looking good" means. The above research all argues that "looking good" means "looking appropriate to the task." Do you need to go overboard adding transition animations and perfectly kerning every letter? Probably not. Do you need to devote time to making the interface's visual design attractive enough so that it inspires confidence in your users? Absolutely.

+1 for the second sentence of your second point. Just as with bug fixing it's exponentially more expensive to change things the further down the product life-cycle it is identified. The earlier you can identify issues the cheaper it will be to address them. Even just changing how a single button looks while it's only in a designers sketchpad is much cheaper than redesigning it later, recompiling the code and shipping it out.
–
JonW♦Apr 13 '12 at 9:54

In general, yes, but there are a number of other variables here that may impact how much effort you put into it.

Who is the audience?
If it's "just a couple of engineers," quick-n-dirty may be just fine, and in fact preferable. Get it done and move on. If it's for more than a couple people, or for people in different groups, then spend a little more time on it.

How often will it be used?
This might be the most important question. If it is going to be used often, a good design will be not only appreciated, but the extra efficiency of your users will make up for any extra time spent on the design. I have used apps in the past where even simple things like Tab Order weren't taken into consideration, which made data entry a real pain.

How long will it be used?
This may be a little more difficult to predict, but in my experience, it will be used more often and for a longer period than you first anticipate, and may even evolve and be repurposed over time. A little thought ahead of time may make this transition easier.

Will it always be internal?
Again, based on experience, if the right "internal app" gets into the right users' hands, it could eventually be added to the "real" product suite. I've seen it happen numerous times.

Good design should usually be a general practice, and practice makes perfect
It's occassionally fine to "slap something together," but as a developer, I find that if I apply my general principles and coding style to almost anything I create, it becomes that much easier to do. The time it takes to create a good design will decrease as you get more experience, and you will become a better developer for it.

As designers we normally spend the entire day working within applications that allow us to do our work either faster, better or/and more conveniently. For us, this are "internal apps" because the client/customer won't see them (usually).

The same goes when developing UI and UX for different pieces of software that are going to be used within a company. The users have to be able to work within the app all day while maximizing their productivity.

Now... if the app/software looks and feels bad, the user will probably get tired of using it or wont like it straight away.. generating a "bad mood" state... and a happy employee ALWAYS performs better.

It's all a matter of balancing the performance of the software (being sluggish) and the looks of it, as both of these things end up annoying users/employees and it's part of the UX itself.

I like the focus on making the tool productive and useful. No matter who cool looking it might look, when the pain from using it becomes more then the gain, its time to use something else.
–
jwernernyApr 13 '12 at 11:56

"is photoshop/3Dmax/etc.. good looking?" - No, but those programs are also much harder to learn and use than they could be (eg. Paint Shop Pro does most of the things Photoshop does, but is exponentially easier to learn/use). Using Photoshop wastes a lot of time unless you have every shortcut/menu-position memorized, so I avoid using it unless absolutely necessary. "XYZ large software doesn't care about good UI, so I shouldn't" is not a valid argument.
–
BlueRaja - Danny PflughoeftApr 13 '12 at 19:11

1

@ blueRaja hmmm I think you misunderstood my point... Given its audience, Adobe does a good job on keeping their UI sleek while having to deal with the complexity of their software tools... Take for example the filter panel, the font/paragraph panel, layers panel, etc...they are all easy to understand for their main target users and at the same time is clean, simple and non obtrusive with its colour scheme. The font and icon sizes are quite small but yet still readable, making use of a quasi optimal space. Same goes for their input fields within panels and sliders, etc..
–
Emiliano RodriguezApr 13 '12 at 23:52

Er, no, they definitely did not do a good job. Every time I want to do something simple in Photoshop I've never done before, it takes me waaay more time than it should to figure out how. It once took me two hours to figure out how to edit a mask using the paintbrush (it is not stated anywhere at all in their help documents)! Whenever I try to do the same tasks in Paintshop Pro (which I've used less often than Photoshop), it's been without exception much easier to figure out. And 3DMax has an equally terrible UI (compare it to, say, Maya).
–
BlueRaja - Danny PflughoeftApr 14 '12 at 5:28

If you get in the habit of making ugly cumbersome software for internal use, you run the risk of using the same bad practices when working on external products. This is especially likely to be a problem for anyone who starts on internal products when first hired because their initial exposure to corporate culture will be the sloppy form.

The problem with adding images, animations attitude could probably be well illustrated by a comparison between StackOverflow website and OSQA project default UI. Both are quite simple and use few images or animations, and yet the difference is obvious (not in OSQA's favor[0]).

Good UI doesn't mean going fancy and using animation, but caring about things like visual hierarchy, whitespace, typography, and, foremost, intended use cases.

Yes, I would recommend paying attention to internal tool's interface as much as to its implementation. The company I work for runs OSQA as internal Q&A tool, and my opinion is that UI is at least part of the reason why employees don't use it much.

[0] Note: OSQA UI is in fact highly customizable, I just took the default one for the example.

As a person who has worked in a call center (which is privy to beta testing of internal programs) I will say this; Programs reflect on the care of the company itself and directly affects employee morale.

Its not that the program will not work the same with or without a nice logo and non-pixelated GUI. However it tells a message that you the company cares about your image whether its to an employee or to a client.

In easy terms its one less thing for employees to b@#ch about in the "smokers pit" when they are on break. Even if the system lags a bit...a nice well-cared user interface will show that you are serious about your image and making life easier for everyone who comes in contact with your company.

As far as cost analysis: It wont take much more to have the same team spend a little more time on a great looking interface. My guess is you already knew the answer before you asked the question. Not that I wouldn't do the same thing when it comes to me having to shell out a little more money.

+1. Making employees feel un-valuable, and perpetuating the idea that the company's technology is all sellotape and string behind the curtain, do not help them work well or enthuse about the company.
–
Jimmy Breck-McKyeJul 17 '12 at 16:28

Do we need good-looking design for a program internal only to our company?

No.

You don't need an attractive* design for an internal app in the same way that it's not necessary to have a beautiful* design for an external app. Easiest examples I can think of are Craigslist and Java docs. They are both highly functional, but I don't consider them particularly attractive.

The basic level of usability design should definitely be implemented. Reasonable font sizes, and colors that are readable. Enough white space to prevent cluttering and confusion.

That all being said, if it's something that is widely used by the company and is planned as a long-term application, you should definitely use an MVC approach. Once the functionality is in place and the app is successfully used for a while (month, year, you decide), improvements to the design could be made without affecting the underlying functionality.

*Beauty is subjective. When I refer to "attractive design" I am referring to a polished look that involves the work of a creative individual to create a pleasing aesthetic. This could be as simple as adding background images, and as complicated as hiring a design team to run the gamut of the design process.

I would like to point out that the design I am referring to is purely aesthetic, and not about functionality. Obviously an application needs to still be designed in a way that is usable, but it's not necessary to spend additional hours adding fancy graphics and pretty gradients. That doesn't mean you shouldn't, however the question (as I quoted it above) was not a normative one.

If the question had been:

Should we use a good-looking design for a program internal only to our company?

I'll disagree; Java docs and Craigslist are hardly "highly functional". They work, but they're poorly designed. Craigslist has almost made a brand out of the lazy design, and Oracle probably just doesn't give a damn about how the Java docs look.
–
Ben Brocka♦Apr 13 '12 at 18:09

If Craigslist wasn't functional, no one would use it. Java docs are effective because there is a massive amount of information that loads quickly. The content is there, the utility is there, the style is not.
–
zzzzBovApr 13 '12 at 18:13

4

Just because people can operate it doesn't mean it works well. People have been using terrible software for decades. Craigslist is unique because of what it does and how many people it reaches, not because it's effectively designed to do what it does.
–
Ben Brocka♦Apr 13 '12 at 18:25

Arguing that a design isn't effective simply because it could be better is fallacious at best. Yahoo had a functional design, Google improved on it. Just because your watch isn't made of platinum doesn't mean you can't use it to effectively tell time.
–
zzzzBovApr 13 '12 at 18:53

1

Woah, ok, first upvote. Actually, this was the answer I was going to post. You don''t need GOOD-LOOKING design. You need good design. It should just work, be intuitive, be easy. It need not have rounded corners, gradients, high-resolution images.
–
KonerakApr 14 '12 at 16:19

Software is the tool your employees use. Ideally, companies would give their employees good tools to work with. Sadly, that's not always the case. SharePoint, for example. ;)

A good looking UI should have little to no bearing on performance, though. Note that a good looking UI doesn't necessarily mean "images and animations". It COULD mean that, but what it really means is some thought was put behind the layout, flow, interactions and overall user experience.

Most bad internal software is bad as it the UI was designed to accomodate the needs of the back-end development team. Alas, users tend to have a different set of requirements, motivations and needs.

Unquestionably yes -- There are a lot of good points being made here, and all are very valid. One critical point in developing a product for any customer, internal or external, is perception. If a product looks at least decent, it will be perceived as a good product. If the interface is clunky, or just plain ugly, the perception is that as much attention has been paid to the coding.

In the food world it is often said that we eat with our eyes first. It could also be inferred that we judge the value and quality of the software we use by it's appearance.

If time and cost is an issue, you have the advantage of knowing exactly what environment your software will be used in. If it's a web based app you're building, you can spend less time (or no time at all) coding a version of the website for people accessing it with JavaScript turned off or via a mobile phone.

You'll have the advantage of knowing the general screen resolutions of the people accessing it as well, thus alleviating the stress of responsive design as well.

The time you save not implementing the above 3 features can be time you put into a great UI design.

The answer lies in the value you place on your users, be they internal and forced to view your app as part of their job, or external, who look at your app(s) as a barometer for your company. UI design is important in both instances.

A good UI will help the user by easing their workload, and, remember, the whole point of using computers is to automate that which can be automated and remove human error as much as possible. A good UI will facilitate all of this.

If you're good, you can automate the training process for an app by making a UI that is self-explanatory. You can make the app more useful and require less of your time in support and documentation if it's designed well.

TL;DR: spend the time and make it right, no matter who the audience. It pays off.

Good GUI design is very important.
User acceptance of a software is directly related to the efficency.
Each software has a goal the employee should use it, so making it better use, more simple to use, and good looking the goal is reached way better then without.
It is also a matter of TCO. You need to advise the employee even more and this costs a lot of money if you have bad looking software.

If you have software in use that you as vendor also sell to other companies then you own employee are the best critic feedback you can get, this should be used as well to improve the software.

We would all like to answer Yes or No, and a lot of us would have good reasons to do so, but at the end of the day, it depends on the company, budgets and a lot of other factors.

Some companies lose tons of money and wrongfully divert valuable company resources by "improving" their internal application ux. Even if you know you should, you are still faced with the question of how.

The only thing that can be said with any certainty is, that internal applications need to be analyzed for productivity, and if that analysis comes out with results that say "if we make these changes, we will see this improvement of productivity", and those numbers are worth it to the company, then they should be made. If you can't come up with a convincing, detail reason why a feature should be changed, then it shouldn't be done at all.

In a perfect world with unlimited budgets, Yes, improving ux for your internal employees is going to raise moral and productivity. If you make the internal application ux like playing an Xbox you may even get people to work long hours for lower wages.

If we think about this in a war analogy, you'd get a lot less pundits for solid Yes or No answers. Should we reinforce the fort, or charge the enemies fort? Now you'll begin to see how information and analysis should be used to determine what the next step is.

Also, on the end of every feature change is a person who writes the checks, and will only be motivated by clear reasons, usually ones that will benefit monetarily beyond the costs.

I'd just like to share my experience, since I write a lot of internal software for my company. In fact, I write very little software that goes to end users.

I've made a lot of usability mistakes in the internal tools I've made. These always end up costing my coworkers time. Sometimes it's a lot of time; sometimes it makes it look like the hardware (our main focus) is broken, and it makes people worried.

So I would say you should care about usability to the extent that you don't want to waste your coworkers' time. That costs the company money, and your coworkers' will get upset at you.

I haven't noticed any difference with respect to the aesthetics; most of it is kind of ugly but I haven't seen any problems from that.

You can also take advantage of the super-quick feedback you can get from your coworkers. If the employee at the next desk says "I wish it could do...", you can add that feature right away and give it to them. Over time those improvements add up to something decent.