SOLID UI: Bringing Development Thinking to User Interface Design

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!

Thoughts/Feedback

If you’ve been working on a design for something recently and you agree/disagree with any of the above, leave your thoughts below.



Stay Updated: Sign Up for Webinar & New Blog Alerts

5 thoughts on “SOLID UI: Bringing Development Thinking to User Interface Design

  1. Excellent read Pete – thank you. I’ve learned a lot! On your comment: “starting to move away from the same boring solutions we see everywhere” – I think we’ve barely scratched the surface of what we’re capable of on this point. While Bill Gate’s Diaries and Snow Fall are terrific examples, I see few if any commercial retail (or any vertical) for that matter, master the art of execution of a similar approach on something like a category or product page.

  2. Chris le says:

    Great article! Having worked on SEO reporting systems my experience is that making a simple to use, clean interface for big data is REALLY hard to do. Simplicity is the result of lots of thought and writing down the bible like this is exactly the right way to do it.

    I personally would advocate teaming up the user to a dev team. This is something while your in the weeds but find an SEO in the company to take ownership of a new feature. I like having them on the project to keep developers from getting themselves stuck in a vacuum and increases the chance you ship exactly what users will use.

  3. Fernando says:

    I wonder myself how good from the SEO perspective is to implement a site with the whole content in a single endless page.

    As well I wonder myself how the a reporting system would look like with that approach, in terms of performance, loading all the tables and charts… and how smooth it scrolls

  4. Chris Le says:

    @Fernando Probably OT, but if you’re asking about infinite scrolling? Like all UX trends you should only follow if it makes sense for your content. It worked at Pinterest (http://uxmastery.com/infinite-scrolling-fad-or-fab/) but didn’t work for Etsy (http://danwin.com/2013/01/infinite-scroll-fail-etsy/).

    Getting GA to work with infinite scroll will be a challenge if you have no interest in dealing with JavaScript code. From a developer’s perspective, it’s a lot easier to setup infinite scrolling if your site already has an API that can pass back parts of your website asynchronously. Otherwise, shoehorning your existing site is going to be an uphill battle.

    $0.02

  5. Bruce Werdschinski says:

    Hi Pete,

    Just thought I’d say thanks for sharing your thoughts. As I specialise in developing ecommerce sites both the Tractable Input Principle and Early Tolerant Erroring Principle are areas I can focus on in the short term. There’s a lot of low hanging fruit that can improve the user experience dramatically, and when it comes time to place an order anything that can be done to reduce friction in the sales process can translate to big $$$ pretty quickly. Sorry, that should be big £££ in the UK :)

    Discovering ways to improve usability is a non stop process, but it’s a lot of fun! As an example yesterday I started using Mailgun’s email validation API for all form submissions (http://blog.mailgun.com/post/free-email-validation-api-for-web-forms/), hopefully that will help our customers and their customers.

    The other principles are going to have to wait until the next greenfield project, we have a large legacy CMS that’s showing it’s age, it’s painful to look at. In a perfect world I’d start again from scratch using these and other cutting edge UX concepts.

Comments are closed.