Over the past n years, I’ve been doing 3 different things: marketing (10), UX (7), and development (more than I’ll admit to). More recently, I’ve been building a bunch of interesting things for the team at SEOgadget, ranging from Twitter Streaming API storage and infrastructure, to a project management system, and a reporting suite.
What follows here is a bunch of thoughts from building a reporting UI, based on my experience and current work. Note that everything that follows is as a result of the slightly strange history in the aforementioned areas, so there’s things I’m going to reference that you may not be familiar with, if you’ve not worked in dev or UX before. I’ll explain as much as I can. Also, to make various concepts readable to non-developers, I’m going to use more normal human-friendly terminology. As a result, things like the SOLID definitions are not entirely correct, but they’re close enough that non-developers should understand what I’m getting at. To any devs reading this: don’t flame me for these being slightly inaccurate: I already know.
SOLID Principles: Development
In the development world, we have the mnemonic SOLID, which outlines certain principles which mark great software, and that outline how code should be written.They are:
- Single Responsibility Principle
- A component should be assigned a single, specific task, do it well, and only do that one thing
- Open/Closed Principle
- Components should be able to be extended for extra functionality by other components, but should not be modified themselves
- Liskov Substitution Principle
- If component y is a child of component x, and we’re using x in a part of a program, we should be able to use y instead and still have everything work
- Interface Segregation Principle
- Components should not be made to access code they don’t need to use to perform their specific task
- Dependency Inversion Principle
- Any component shouldn’t directly talk with any other component; instead it should go through an interface, so each component can be modified without breaking the other
These allow for code that is easy to understand, simple to maintain, and that fiddling with any specific part shouldn’t cause issues that move through the whole application. However, in my work designing the reporting system we’re going to be using soon here, I’ve noted that there’s a similar set of rules for user interfaces, which I’ve not seen codified anywhere (if anyone has come across these somewhere else, ping me a tweet @petewailes), so I thought I’d take a minute to write down. As a result, I present: ROUTES.
ROUTES Principles: User Interface Design
So let’s take a quick tl;dr for these, and then we’ll break them down and have a more reasoned look at the why behind each one.
- Rational Navigation Principle
- A screen’s navigation should balance the needs of comprehensiveness against the addition of unnecessary complexity
- Ordered Detail Principle
- Child screens should only be used to display more complex or detailed data that is given in overview on their parents’ screen
- Uniform Layout Principle
- Elements of the design that re-occur on many screens should be consistently located for fluency & discoverability
- Tractable Input Principle
- Any input should account for predictable, real-world correct formats of that input that a user might try
- Early Tolerant Erroring Principle
- If a user performs an action that causes an error, the system should alert them as soon as possible, and help them correct it
- Sole Element Principle
- A screen should be dedicated to displaying a single element of information and its metadata
…and now the detail.
Rational Navigation Principle
Let’s make this clear: navigation on a screen should be the bare minimum possible. A clickable logo in the top left hand corner for getting back to the home page, primary navigation for getting to the top level sections of the site, and then child navigation under those areas for moving inside them. That’s it. Anything else should either be on a different screen, or just not there. This also has the effect of forcing you to look at your analytics regularly to work out if there’s content missing, or content that needs removing.
Ordered Detail Principle
Anything that navigates down hierarchically from the screen a user is on, should display a more detailed view of something that the parent screen covered more briefly. There’s almost no situations where completely non-contextually relevant linking is a sensible thing to do. With every screen you design, as yourself what navigation is absolutely necessary, and include that and nothing else.
Navigation for going back up can be more flexible, as a user may wish to change areas. However, the best way to deal with this tends to be to take them to the top of that next branch and allow them to navigate down, rather than presenting all options all the time. This also allows you to better control and refine the user experience through those paths, and to adjust your navigation to better tailor it to your users as you get better data on how they use the system.
Uniform Layout Principle
This is the most obvious of the various principles here. If you’re using a navigation element in once place on one screen, and you use that same element on another screen, keep it in the same place. No-one likes to play hunt and peck.
Consistent blocking for screen types is important. Not only does it keep your devs happier as it reducing the number of templates needed, it makes for a more consistent user experience too, and reduces cognitive load, creating happier users.
Tractable Input Principle
This is probably the hardest piece, from a development standpoint. This means doing things like making sure people can use multiple date formats (YYYY-MM-DD, D/M/YY, D-M-YY, DD.MM.YY etc…), making sure that if they have caps lock on when they log in, that they still get logged in correctly, checking for pesky whitespace and new lines at the end of content, and trimming them off and so on.
The problem with these is that they’re non-obvious. As a result, I’ve found the best way to test these is to watch real users interacting with your software, and to log errors so you can visually represent what most often went wrong, and deconstruct why and how to best address those issues.
Early Tolerant Erroring Principle
This is probably the simplest point. If someone manages to enter something that just isn’t gong to work (for instance, they don’t notice that they’ve put their name and credit card details in the wrong boxes), you should alert them as soon as possible. This means client-side validation, highlighting when something’s wrong.
Look at other places where this can apply too though. 404 pages tend to simply say that the page is missing, rather than suggesting similar or related content, or showing a category structure so the user can go back up a level and re-navigate from there.
Try and make your error messaging as helpful to the user as possible, and get them in place before they end up having computer rage.
Sole Element Principle
The last element is to do with how you design your screens more generally. When you get right down to it, most sites use exactly the same template. Top left logo, navigation beside or under that, search box top right, a left sidebar for links, a footer for other links, the right panel for content. Sound like anything you’ve seen before?
This is part of why I love what the NYT are doing with their newsgraphics recently. Stuff like Snow Fall and Bill Gate’s Harvesting the Biosphere review of the book of the same name. Here we see people looking at the web and the tools and freedom it gives, and starting to move away from the same boring solutions we see everywhere, to make something incredible. So here’s a challenge – next time you’re thinking of putting something in the footer, see if you can find find a better solution.
This means you may need to rethink some of what you’re currently doing in terms of design. However, the upshot is you’ll start treating your websites as if they’re on the web, rather than thinking about them like glorified magazines. Your site deserves better!
If you’ve been working on a design for something recently and you agree/disagree with any of the above, leave your thoughts below.