Navigation
Apple desingers knew how important navigation is. Let’s take iPod as an example. They came up with idea than favorite mp3 should not be more than 3 clicks away. So in just 3 clicks user is able to navigate through system to his/her favorite music. This is quite powerful feature and proof of importance of well designed navigation.
From my personal experience no effort at all is put into designing a navigation. Maybe because in case of business applications with lots of forms it is just minor concern. Navigation is just a product of grouping requirements together and interface mockups. Maybe projects I’ve worked on had no budget and time for it. Whatever the answer is the navigation is there and maybe because it is accidentally fine it is not noticable.
It is surprising that good navigation can be achieved using really simple and really cheap techniques like card sorting.
Card sorting technique goes like this:
- Determine list of topics
- Make cards
- Select participants
- Run session
- Analyse groupings
During the session participants have to rank cards according to their intuition. When finished, participants are asked to put labels on each group. Grouped topics show potential structure for the navigation.
The only tricky part about this technique is the requirement for the participants. They should be representative users. I think this technique could be used even without perfectly representative users internally in the company and still yield useful results or at least more useful than coincidental arrangement of topics.
Product style guide
Product style guide is the document compiling all the information concerning a software product UI. It consists of information how elements like controls, dialogs, statuses, notifications and pretty much everything else should look like.
To me it seems like very useful document especially when I look at my past experience. Even though we had some design done by graphic still some of the missing parts like notifications differed between screens. Sometimes notification were at the top of the form, sometimes below. Sometimes action button was labeled just “Save” and sometimes “Save changes” even though it was used in same context. We had to spent some time fixing these inconsistencies. Having style guide would be much help. It would be good to know how to present list of things, how to present descriptions of items and many more.
I am sure that time spent developing product style guide would be less costly than time required for developers to fix minor incosistencies. Think about your product. It is surprising how much time you spend after all works but still does not look good enough. It takes a lot of time to make all UI sound when there are no clear guidelines or when they arrive really late after most of the work is already done. Having product style guide beforehand would reduce greatly simplify whole process and also decision making of developers.
Now that I am thinking about it over the time we arrived at implicit style guide. Mostly because some useful components like paginated lists with detailed view were developed and incorporated by the rest of the team members. It would be much better to have explicit document.
However there are some problems. Requirements are changing, sometimes it requires change to presentation of things. For example from radio button group to dual multiselection list. It is not pragmatic to develop style for every possible GUI element. Also not all elements are known. That means that development of product style guide should be iterative. It could start with some common base of elements when mockups are done and then it would require adjustments when new elements pop up.