selinov
In iterating my blog/portfolio I realized that I was missing a basic Information Architecture example. One of the very first tasks when redesigning the CloudForge application was redesigning the main navigation. This was more than just layout. This was the task of really figuring out a better way to group, extend, and display the major functions of the service.
Remember, the assignment was not to create a new product from scratch. We had to design a new UX while carrying thousands of existing users over to the new application experience. This meant implementing new ideas without leaving our current user base at a loss for familiar UI/UX.
Dashboard: Makes sense.
Projects: The heart and soul of the application. People tend to think in terms of Projects so let’s keep this.
People: Hummm… A bit vague. Are these users, admins, managers, customers? Who knows? We have to click and investigate in order to find out. This breaks some of the basic UI rules of being predictable and perceivable.
Publisher: This is actually a service that pushes code to various outlets.
Services: Wait… Isn’t publisher a service? Are they different in some way?
System: Again, the title is a bit vague. You mean system settings? You mean the whole CF system or one of the service systems?
There seems to be two levels of navigation without a clear demarkation of the difference. “My Settings”? Aren’t all the settings I’m making “My Settings”?
Aside from the actual architectural schema, the aesthetic looks like it could use a major upgrade from the tabs metaphor.
The answer was to create sub-buckets within larger buckets. For instance, instead of “People” we have an “Admin” bucket with the first sub-bucket being management of users, groups, etc. It’s like putting the people tab inside of a parent. How do we implement this?
From here I can run it by product and see make sure that it’s meeting all of the business goals. In this case the “Services” section drives folks to any new services, paid or free, that would complement their needs.
Initially I’d considered icons for each menu item but I quickly realized that we’d be up to our necks in icons. Now if we ever want to set an item apart from others we can use color/icons (make “Billing” red when over due for instance).
In the end we have an architecture that’s simpler to read, faster to navigate, and way more extensible. This makes happier users, engineers, and product owners.