How can I make sure that all developers in a team create a uniform user experience?

Question

In our development team we create many small applications, all targeted at a very specific needs of our customers.

Therefore we often have problems with creating a uniform user experience regarding:

• Choice of icons (GUI)
• Naming of configuration files
• Naming of configuration options
• GUI language (as in "formal or less formal" or "for novice/advanced users")
• Choice of names/titles
• General GUI layouts
• ...

I can think of several approaches to these problems...

• Create very detailed written guidelines
• Discuss everything
• Let one developer decide everything
• ...

What's the best way to achive a cohesive user experience or uniform results in general? Personally I don't like any of my approaches, but perhaps that's a misconception, so feel free to support them :)

Answer 1

Extensive guidelines and reviews by a "technical lead", a "design lead" and/or QA.

Make the guidelines "dynamic" and keep them accurate and up to date, in our company we use a Wiki for such collaboration tasks.

Answer 2

You might want to create a standard set of templates. e.g. If you create a web site template with pre-defined css rules, html layouts etc, then you make it 'easy' for developers to produce uniform output as far as look and feel is concerned.

Answer 3

Fred Brooks talks about this a lot in the mythical man month which I highly recommend reading.

Karl

Answer 4

I've had several positions where I've had complete ownership of the GUI. This involved me doing all designs/mockups and also supervised the use case writing to make sure it was all consistent. This is by far the best approach to ensure consistency, but it might not always be the most practical one.

Alternatives would be to write guidelines, but this is not really the same thing as having a good GUI design knowledge/HCI skills. At least it can teach developers to use custom libraries/components that your company might have.

A must is a dictionary that contains the domain language your ase using and how it should be used in the GUI. This is one of the most important things that a lead gui developer needs to do.

At the very least you should make sure that you review anything that is done by other developers unlessy you know and trust them to do the right thing. GUI design is often a vastly under estimated skill and it is important to remember that not everyone can do it without proper training.

Answer 5

I believe that the biggest problem is often that developers are not aware that there is a guideline for a particular design consideration, rather than the unwillingness to implement those guidelines. It is the management's job to make sure that they have that knowledge.

You will always require verbose written guidelines if you are to standardize any type of team effort and weed out the "individuality" that is going to inherent to system design.

However, you should keep in mind that no matter how detailed your documents are, there is probably going to be some unforeseen condition that will be missing. To counter this probability, you should have an open-door policy whereby team members can always come up to the team leader and discuss such scenarios. These new items should then be updated into the guideline repository.

Your guideline documents should be easily accessible to all stakeholders in the project. Creating a "cheat-sheet" ready reference is often a good idea.

Answer 6

You should use some sort of Dependency injection with XML files much like what Spring can provide.

All the developers shouldn't integrate their choice of GUI parts hard-coded into the program, but rather leave this choice to the XML file.

Then a single QA person will have to check the applications, and should it not be standardized, change only the XML file, rather than recompile, etc'... This will be much faster and simpler as there's no need to look at the application's code.

If Spring doesn't work with your environment, I'm sure other Framework will, or at worst, you can build a small one yourself, but that will take much more time.

Answer 7

create a document that discribes all of the general prooerties for the layout.

this document should include:

color of background color of text color of active text color of inactive text color of comment text font type font size etc

make sure (by testing) that the developers follow the guidelines.

you could implement punishment (fire, less salery, no promotion) if a developer does not.

Answer 8

One approach that worked for me before is to have a shared library for base classes that enforce or apply themes and layout.

We were a team of 7 developers, and almost we do desktop apps, so we created base classes for Forms and mostly used common controls and put all icons and images in the source code repository , and part of the testing we make sure that all icons and UI language (lables, messages and tooltips) are consistent.

Answer 9

Anything written and handed-out/emailed-out will be forgotten. I would suggest creating an internal wiki that you house the standards on, links to icons, steps to create/save work, naming conventions, examples of work, etc. Something everyone can access and update

Answer 10

ive had a position where i was the ui designer and that worked out fine. it was my responsibility to create mockups and bring them into visual studio as master pages.

the programmers would then come in and add the logic.

this is an excellent approach because it doesnt require a style guide or volumes of documentation seeing one person is in charge of it.

the reality is most companies dont hire someone specifically for a UI role (more companies are starting to do it now then a few years ago though).

having been a project manager for 5 years at 4 different companies, there is another approach.

i dont put much faith in writing a UI guide and expecting programmers to follow it. theres a few reasons for this: 1) programmers often arent good at UI design, 2) its a lot to remember, 3) its counter-productive.

UI style guides slow down programmers because you are expecting them to be good at something which they arent good at. they are good at coding - so let them code.

what do you get? inconsistencies in the interface. this even happens when you provide programmers with mockups to work from (e.g. your mockup might not contain an error message a programmer may have to show).

so whats the solution? easy - you have one person review the entire interface at milestone points and log bugs in your issue tracker. these bugs would be marked as UI or low. if theres a script error, its obviously much more important to fix that first then a UI glitch.

the next question is, who should be doing the review? again, easy - one person only (for consistency), and that person should be whoever is the most talented with HCI/UI design.

my point is; dont make programmers try and be UI designers. when you log a UI bug, its there in the issue tracker, the programmers will come and fix them when they are good and ready. and they are generally really easy to fix so they can act as a good break for a programmer who may spend 2-3 hours debugging a serious data corruption issue for instance (yes, fixing a UI bug can actually be a stress relief!).