In this episode we are diving into how we can construct a better user interface (UI) utilizing the tools that our User Experience (UX) experts have put before us. If you recall last time we discussed the importance of UX and how it can help us to identify higher-traffic areas of our application as well as why certain views might need to be more prevalent within the application. Today we go one step further and translate UX into UI in terms we can all understand, including views, navigation, and everyone’s favorite click-count.
From Empathy to Navigation
One of the highlights from the last post was getting to look over the empathy diagram that our UX experts prepared. Not only does this give us insight into John’s fears about aliens, cowboys, and meteors (really, check it out, I’m serious), it also helps us to build a list of user requirements that will be added to the technical requirements. Combining both sets of requirements can help us to sketch out a navigation path through the application, moving us closer to writing some code. After all, if we can understand the concerns and resulting workflow that a user would use to best optimize their time, we can better construct an application that is targeted at that user. This translates to more time utilizing the software and less time fighting the system to get the intended results, something we have all experienced at one time or another. In other words, building better software through UX.
As our UX team loves their whiteboard, we have a diagram which looks roughly into what our requirements would dictate for a navigation path through the application:
Starting with a Dashboard
If you follow this diagram you can see that we centralize everything into a Dashboard for the purpose of surfacing the most relevant information first. This is incredibly important as if there is a hot deal that needs to close or an item that needs extra attention our user will see it first when opening the application instead of having to dig, filter, or run a report. In other words we’re starting with a Dashboard view as the opening screen of our application and then branching off from there.
You may notice that I’m shifting from UX terms like ‘empathy diagram’ and ‘meteor’ to something Silverlight or other developers are more familiar with – views. If we were to translate this navigation diagram into logical views for our application it might look something like the following:
- Dashboard (starting view)
- Company / Details
- Contacts List
- Opportunities List
- Activities List
- Contact / Details
- Opportunities List (default)
- Activities List
Each of these views would be a possible destination for navigation and all should contain the ability to navigate back to the main Dashboard.
Navigation + Interaction leads to UI
Moving beyond our look at what views are necessary, keeping the navigation as streamlined as possible we will want to minimize the number of clicks it takes to get from the initial view (Dashboard) to any number of general actions within the application including editing a contact, adding an opportunity, or being able to filter the companies list. Going by actions and click count, we can see navigation through a different light:
Looking at the above combined with the navigation/views picture we should hopefully see some patterns emerging, specifically along the lines of a clear navigation path and a minimum number of clicks to accomplish any task from any other part of the application.
If done correctly, not only will it be easy to move through the application but we can quickly accomplish any task – meaning if you just happen to get on a quick phone call with a customer regarding a hot deal you will never have to say “Just one second while my computer loads… it must be taking an early lunch!” and instead be where you need to be within the application for accessing or entering relevant data. This will both make you look good to the customer, since you can continue building rapport and carrying on your conversation, as well as to your bosses since you’ll always be able to capture necessary information and never end a call wondering “Oh drat, when did he say they needed their budget submitted by?”
The Next Episode
Now that we are several posts into this endeavor we know the technologies being used (Silverlight, OpenAccess ORM, TeamPulse, and Test Studio), we’ve taken a look into user requirements from the standpoint of the user, and this time around we utilized that to start talking in more development terms and how we can translate requirements into views that require a minimum of clicks to navigate and to interact with.
All of this folds into our topic for next time which is taking the first steps at constructing a UI. Now that we have laid a lot of groundwork in relation to understanding our users we can turn those investigations and thorough white board drawings into something a little more concrete. This will also include exactly how we structure our UI, including screen layout, sizing of important items and buttons, and the overall look and feel which will bring this application to life and make it not only effective but actually enjoyable to work with (yes, LOB applications can be a pleasure to work with!). Stay tuned for more!