Design is vital throughout the process of product development and at every layer of the stack. Typically design-specific roles are focused on User Expereience (UX)/Interaction Design (IxD) and visual design of User Interface (UI). While any form of interface — even programming interfaces (APIs) — calls for thoughtful design, I'll focus here on design of visual human-facing interfaces.
When giving direction or feedback during the design process, I'm comfortable discussing all of the following concepts regarding visual design, in user interfaces, as well as product marketing and sales materials:
- White space
- Brand guidelines
- Adherance to explicit or implicit style guides (for organization, site, etc)
- Clarity of copywriting (including labels, button names, etc.)
Examples of Great Interaction Design
While visual design is vital to developing great products, the foundation is really the experience or interactions. UI elements can be restyled relatively inexpensively (and should be restyled at some point, on a long enough time scale, for the sake of maintaining fashionability). However, clear and effective interactions never really go out of style, and doubling back around to redesign UX is quite costly.
Below, I've identified several examples of high quality interaction design in both consumer- and enterprise-grade SaaS software and highlighted what I appreciate most about each.
MailChimp Campaign Builder
The first IxD principle that this example illustrates is consistency. Throughout the process of creating a campaign, whether it's created/sent in a single session or saved as a draft and resumed later, the lower-left corner is a Back button that always returns the user to the previous step. Likewise, the bottom-right corner is always a Next button, advancing the user to the next step in the process — and consistent with this left-to-right movement metaphor, the breadcrumbs unit in the bottom-center of every page shows which step of the process the user is on and allows the user to click to skip forward or back to any step in the process. This consistency avoids confusion and allows the user to focus on their email audience and content, rather than being distracted by the the nuances of how to get the software to do what they want it to do.
The next principle this example uses to great effect is visibility. Every possible navigation from this screen to any other desired screen in a user's workflow, can be accessed from a link that is visible by default, on this screen. No navigation in this process is going to be easily overlooked or require time investment to find it. Also, this example illustrates the principle of giving the user feedback, as the breadcrumbs don't only allow you to navigate but also inform the user as to which step they've successfully landed at, by styling the active/ currently-showing step more prominently than the other steps in the breadcrumb unit.
Finally, similar to consistency (discussed above) but worth discussing separately, this example illustrates the foundational (in my opinion, but subjective, I suppose) principle of IxD — which is predictability. When the user clicks the Next button or the Back button, it is very predictable what will happen next, largely thanks to the consistency factors already discussed. But the consistency and use of a spacial metaphor really pay off in user interactions, by way of the user being quickly made confident that they can predict what each UI element can do for them.
Rdio Player Web App
This one has similarities to the MailChimp example, but the users and product are so dramatically different, it is fun to dig into this one too. Here, where the user is typical "living in the app" for an extended period of time, the tool bar at the top and the player unit across the entire bottom of the screen persist. If you never move the window or resize, the location of the toolbar and player controls never change, even when navigating up and down the hierarchy of pages in the app (search results, view artist, view album, view playlist, view user, etc) and even when scrolling vertically within a page.
This is another great example of consistency. And again, consistency bears the fruit of predictability for the user's interactions, because she can be confident that anywhere in the app she explores, pausing/skipping/ controlling volume will all still be immediately accessible.
Similarly, the use of visibility in this design is obvious, so I won't belabor this point. But these controls are always visible, no matter what (unless there's some obscure place in the app I'm unaware of, where they disappear).
Finally, the screenshot doesn't illustrate this, but I'll mention that the player's UI elements offer feedback on mouseover, which dramatically improve learnability in the IxD:
Shuffle icon, Repeat icon, and Chromecast icon all brighten color to highlight on mouseover — and when clicked to make each mode active, each will remain highlighted to show state as active until clicked again.
On mouseover, the Volume icon reveals a volume meter and a round "handle" UI element, giving feedback on the current volume setting and providing learnability for the job of adjusting volume for music playing in the app.
Similar to Volume, mousing over the player progress bar (timeline of the currently playing song) reveals a "handle" to make scrubbing a very learnable user job.
Basecamp Nav Paradigm
Since the full, ground-up rewrite of Basecamp (launched back in 2012), the views within a given project have made use of a metaphor of stacks of physical paper sheets. As you dig deeper into the hierarchy of the navigation (e.g. Project overview > Files in project > ￼Specific file, in context of a discussion comment), each page of the app is represented by what is made to look like sheets of paper, with the current "sheet" on the top of the stack (fully visible) and the others underneath, cascading out the top and left edges to show depth and allow access to click on each.
I like this metaphor, as an insightful use of visibility, making sure that the option to navigate back to an earlier, higher-level page in the app is visible.
While the fact that the entire top section of each "sheet" in the stack of papers is clickable may not be obvious, I like that using underlined text (to illustrate click-ability) for each page's title in the stacked papers metaphor enables strong learnability.
Lastly for this one, I'll mention that making the Project Overview always the lowest page in the stack gives feedback to the user, so they can be confident about which project the current page is a part of, when they to each subsequent page in their session.
Examples of Uncompleted Interaction Design
Design is really problem-solving, and often editing is needed to deliver the best possible experience for the user.
Below are critiques I offered on a specific product, at the request of that team. I've obscured names and branding as much as possible, because this produt is actually quite well designed — and not deserving of association only with these critiques.
These designs are goood, but I propose that they are not quite finished. Jason Fried, founder of Basecamp (formerly 37signals), nailed it when he tweeted this:
The design is done when the problem goes away.— Jason Fried (@jasonfried) March 1, 2012
Enable/Disable Kiosk Mode
Here, it is obvious how to enter Kiosk Mode, once you see the link in the footer of the page, basically. All good so far. But then once you enter Kiosk Mode, there is no such link in the footer, which is where I looked first (and I think where most users would look, especially if they are concerned that they just entered a mode they don't understand and want to leave right away, rather than exploring this alternative version of the UI).
Also, the arrows-pointing-in button for exiting Kiosk Mode could be interpreted as some sort of abstract symbol/logo/decoration, due to the symmetry and many parallel straight lines.
This example violates the IxD principles of consistency, learnability, and predictability. But, all that said, I understand that there are other priorities and considerations in this situation, which I haven't mentioned.
Platform vs. Plugins Labels
This example compares the Products list in the company's marketing homepage's top navigation bar to the single-level navigation bar at the top of the company's application containing seven descrete products (accessible only to authenticated users, signed in as a customer), where each product is listed as it's own link.
This example violates the IxD principle of consistency. I recognized every item in the app's top navigation bar as being a distinct product offered by this company, except for Plugins. I had to actually go do research on the marketing site and in the app, to overcome my confusion and fully understand how to make sense of the app's top navigation.
Now, I understand that Marketing owns the homepage and Product owns the app (signed in as customer), and I understand the right desire to make clear to the user what they will find when they click the Plugins link. I would say of this one also that it's not clearly bad or wrong — but is probably not done, for the reasons I've outlined.
Navigating to Alerts
This is a somewhat clearer example of a IxD shortcoming, without an obvious counterargument in favor of the current design. I'm not positive there's no good argument for this design, but if there is a good reason, my understanding of the product isn't yet deep enough to recognize it immediately.
From this screen, there is a second way to access Alerts — something that's always accessible from the second level of the top navigation bar of the app, any time you're in the APM product's screens of UI. This lack of consistency prevents predictability, and not just on this one page. Seeing two different links — especially on the same page at once — could result in a user leaving this page believing (or at least suspecting) that there are two different screens in the app for dealing with alerts (one of which they haven't actually navigated to yet), etc.
Losing Unsaved Changes
Finally, the Profile Settings screen uses a paradigm of being in a constant Update view (there's no pure Read state for this screen). I'm actually a fan of this paradigm, especially for seldom used data, like Settings.
The problem though is that if the user makes changes and forgets to (or doesn't understand they need to) click the appropriate Save button, they will be allowed to navigate away from the page (browser Back/Refresh buttons, click a link on the page, close the tab/window) without saving their ￼changes. Many users will leave the page, presuming changes they typed in or otherwise made have been saved and then return later to find the changes they believe they made have not been honored.
The two ways to solve this would be as follows:
- Complicate the front end code dramatically, to make each field live update as the user interacts with each field/checkbox/etc — rather than using the Save button metaphor that's currently employed. This seems elegant, but can have the opposite problem of the current design (unless very nuanced precautions are taken in the page's UI), where a user doesn't realize that a typo or other erroneous change to a field has been saved to the database without them explicitly asking for the save (e.g. user no longer gets notification emails, because they accidentally updated their email address to 'email@example.com' when they got distracted in the middle of typing in their new email, and it saved the new value automatically). Data validation can prevent some of this, but for some categories of data you can't validate against this kind of typo.
- My preferred method to work around this, to address this screen's issue, would be at least a browser dialog being thrown any time changes have been made on the page but not saved by the user, whenever the user tries to close or navigate away from the page. Doing an in-page modal dialog for any links clicked within the page would be more elegant (not requiring a pop-up and allowing visual styling of the dialog), but I suspect the somewhat ham fisted and intrusive browser dialog is the only option for a close/Refresh/Back browser action.