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.
Original Navigation Scheme
The CloudForge came from a product called Codesion… same service, different platform. The original navigational scheme was based on tabs grouped into primary buckets; Dashboard, Projects, People, Publisher, Services, and System. At first glance this seems to be pretty sensible and it worked for years. The problem is that when you decide to go after new users in a more savvy market the paradigms break down.
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.
Imagining a New Organization
My first step was to take stock of what items are really important to a given user. The original seemed to look at the navigation from the perspective of the engineer building it. I wanted to approach it by asking “What do our users do now? What do they want to do? How can I get them there faster? How can I introduce them to other features without creating confusion?”
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.
Implementing a New Navigation
Finally, Bootstrap gave us a modern drop down menu scheme which is more aesthetically pleasing and WAY more extensible. We can simply fit more options in the drop downs than the strictly horizontal tab device.
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.