Think of developers as users too

UX designers are skilled at designing for the user’s needs; at empathising with them and testing to ensure that things really work. We’re also good at understanding business objectives and marrying them with those user goals when planning digital products. But occasionally I come across UX designers who don’t make so much of an effort to understand the development team that they are going to pass wireframes and visual designs on to. This can result in all sorts of issues; in the worst cases the designs can be badly degraded or even abandoned altogether if they don’t work for the backend team. Luckily we are really well placed to deal with this situation. All it takes is to re-focus some of the user-facing skills we practice at the research phase and train them on the development team instead.

So here are some things we can do:

  • Meet face-to-face early on and listen to the developers. What are their pain points and concerns?
  • If possible, try to meet developers in their place of work or in an informal setting. Sitting round a boardroom table can reinforce the ‘us and them’ feeling and people can clam up.
  • Sometimes clients or partners will send a ‘Technical Director’ to project meetings. But it is important to meet with the developers who will actually be doing the coding. A visit to the development team’s offices may help overcome this.
  • Send early sketches or prototypes to developers as soon as possible and ask for their views. This avoids last minute surprises.
  • Include developers in sketching workshops or other stakeholder meetings
  • Be open-minded and listen to developers just as you would listen to users or to the client CEO. They may have a great idea about how to solve a UI problem. Sometimes just listening to their views can re-assure them.
  • Include developers in user testing sessions. Just as it is for high-level client stakeholders, this can be massively powerful.

Remember, developers are generally just as interested in designing stuff that works as we are. Actually, the rise of UX design should help to bring designers closer to developers. In my experience development teams respond really well to the research and interaction design part of the process, perhaps more so than branding or purely aesthetic issues.

When we work in separate teams, developers are the real ‘users’ of our designs in a very real sense. So we should practice user-centered design on them too!

Don’t start with a page template

One of the most important lessons I’ve learned in web design is this: don’t start with a page template. Focussing your initial design effort (and front-end coding) on a homepage or indeed any other kind of layout template is not the way to get the best results (unless you really are just designing a tiny one page site). In recent years responsive design has reinforced this philosophy but even for fixed-width websites the same applies.

Start by specifying a system. This system should grow as part of the branding (or visual identity) to form a visual language. You can use style tiles as a way to explore the character and tone of a design – and to facilitate client involvement in the process. Then, once a visual treatment has been agreed, the visual language can be fleshed out further, making the transition directly into a set of base CSS styles which are applied to a comprehensive range of types of content and UI elements.

What we are basically producing here is a style guide. As well as the range of basic HTML elements (buttons, forms, headings, lists, and so on) it pays at this stage to include any more complex or customised UI elements that you are likely to need. These might include tabs, panels, icons, error messages, navigation, calendars, and so on. Existing frameworks like Bootstrap are good places to go for inspiration to remind you of the types of elements you might need. You might also have a set of wireframes to work from. It is worth putting a lot of effort into these base styles so that they work well across your target browsers and use contexts. They then become the building blocks of your UI, and you can pass these files to a backend development team.

style-guide

A better way to design

Large web projects are continually growing – having new screens added to them, bits changed here and there – and the best way to ensure a consistent visual experience is to create a system. Once you have such a visual system it becomes easy to add new layouts because you already know the ‘rules’ for constructing each building block. Of course this has been true of graphic design forever: book design needs a system in just the same way. But websites grow and change much quicker than books; and the emergence of responsive design means that even a single page of content may morph into several different layouts depending on the kind of device you view it on. In this situation thinking of a website in terms of a set of page layouts really doesn’t make much sense anymore.

Of course, while you are designing your visual language you do have to consider a range of specific layouts too, to make sure that the elements you are designing will cover the type of screens you’re going to need, and to see some examples of how things hang together. In practice I may start out with a style guide, then create some actual layouts and move back to work on the style guide to tweak the system. In addition, you usually will need to hand over at least some specific templates alongside the base styles, to show the headers and footers and how the grid and modules work, etc. So page templates are still important; just not the primary focus in the initial stages.

A better way to code CSS

There is another big win to be had from the style guide approach: you will end up writing much better CSS. It is far easier to construct a neat ‘object-oriented’ system of styles if you start by considering a good range of element types up front. It helps to focus on a sensible system of sub-classes while each is fresh in your mind, and it is much easier to tweak your class structure when you only have one of each element, rather than having to trawl back through several templates making multiple markup changes each time. Approaches like Jonathan Snook’s excellent SMACSS have helped me to improve the maintainability of my CSS; but it is far more practical to pursue an approach like this when working from a base set of elements, rather than building a site one layout template at a time.

Also, in my experience developers love having a set of good-looking base styles. It means that whatever they create at least looks right at a fundamental level. There is not always a designer on-hand and this way you can keep things pretty neat and tidy no matter who is working on the site.

A better way to prototype?

A lot of UX designers are starting to prototype and test directly in code. While I still tend to work with a sketchbook and then Axure or Omnigraffle most of the time, I can see strong advantages to the HTML prototyping approach, especially when working with and testing responsive web pages. It strikes me that rather than the traditional approach of prototyping with generic ‘wireframe’-type styles, maybe the brand and visual language could be completed first, and then those styles used for prototyping and testing. Of course you may not know all the different types of widget you’re going to need before the detailed interaction design is completed, but at least the basic, common styles could be put in place. I’ve not actually tried this yet, but it’s something I’d be keen to explore.

Is ‘flat design’ really flat?

I’ve been following the growing trend for ‘flat design’ with interest. But is it really ‘flat’ or more a reaction against over-used design details like the drop-shadow?

I would argue that the visual impression of depth in a UI is very useful and not something we are going to lose, particularly for very complex UIs. Take this page from Layervault, for example (Layervault’s Allan Grinshtein is one proponent of ‘flat design’):

In the design shown above, the boxes for each plan are clearly designed to be placed in the foreground, relative to the other elements on the page, an effect created by use of contrast. The text that contrasts less with its background colour seems to fade into the background. The same is equally true of the rest of Layervault’s excellent UI design. And it is true of Microsoft’s new web app UIs.

A page doesn’t really have any depth of course – it is flat as your screen. So maybe an extreme anti-skeumorphist would take issue with the use of contrast to create the impression of depth. But the fact is, depth is an extremely useful tool in UI design that helps us establish context and focus. And this impression of depth on a flat page inherits its potency from the way we perceive real 3D objects in the world around us.

I really like some of the new refreshing ‘flat design’ UIs and I think generally simplicity is good. I may well end up moving some of my own design work more in that direction. But I also don’t see anything wrong with the occasional subtle gradient or shadow. And sometimes these can help reinforce the impression of visual depth of in interface in a useful way, like with buttons.

In Defence of 3D Buttons

There’s been some discussion in the web design community recently about ‘flat’ UI design as the arrival of ‘honest design’. See this post from Allen Grinshtein for example. Of course ‘flat’ design has been around for a long time (here’s a flat design I worked on back in 2007), but has been getting more attention with the arrival of Microsoft’s nice-looking Metro design language for Windows 8. In much of the design community there has been a fairly strong reaction against over-use of 3D gradients and drop-shadows on the web and ‘flat’ design seems like a refreshing way forward. In particular Apple’s use of skeumorphism in the Calendar app in iOS 6 was widely disliked. But having said this, I find that in my UI design work I still tend to favour using the 3D metaphor for buttons. Yesterday I had a bit of a discussion about this with Ben Joyner (chief web designer at the University of Bristol) which has caused me to think a bit more about why this is. I think these are the main points from my point of view.

In usability, familiarity is king

I think that on a web form, the familiarity of a button that looks slightly 3D can give a slight usability edge. People are used to the 3D metaphor and if a submit button has a slight gradient and seems to pop slightly from the page, I think this helps to key people into the function of that element. It doesn’t have to be over the top – the effect can be quite subtle and the casual viewer might not even notice it. But I think in some cases the extra texture of a gradient can help.

Brochure sites vs. web apps

I reckon there is a slight difference here between a standard ‘brochure’ website and a site comprising a lot of interactive forms (e.g. web apps). While I think the choice between flat or 3D is largely an aesthetic design decision in both cases, in web apps (including mobile apps) the greater density of interactive elements on the page makes it slightly harder to mark out affordances with other means such as colour contrast, white-space, etc. In these cases I find it particularly useful to mark out a button with a subtle gradient and/or drop shadow. Although I’m not saying a flat web app can’t be done successfully! With a brochure site (for example where you have little more than a submit button on a search bar) I would have no hesitation in using a flat style.

Working with browser defaults

Although it is possible to replace default browser form elements like select boxes and radio buttons, it is hard to do this consistently across different browsers and results in a lot of extra work. Generally I prefer to work within the flow of the constraints of the medium and accept browser defaults here. So, given that select boxes will look very 3D, I think it can potentially be slightly confusing if submit buttons then look flat. Yes, you can certainly work around this but I usually prefer not to. This is one way in which working with web forms is a bit different from creating a stand-alone new design language from scratch like Metro: they already have their own history and baggage.

So what do you think – are there any real usability implications of the flat vs. 3D styles? Does anyone know of any testing aimed specifically at 3D vs. flat buttons?

Sleeping Columns Using the Semantic Grid System

So a couple of weeks ago I was working on building a complex responsive grid that had different column widths at different breakpoints, and blogged about it here. I found this system works pretty well and is very scalable, meaning I can quickly build complex responsive templates for new layouts on a site. However, all those classes are pretty cumbersome to work with and also mean that you’re putting all that presentational stuff into your markup. Then I came across Tyler Tate’s Semantic Grid System and I thought it might be useful to try this as an alternative.

The nice thing about Tyler’s solution is that it hides all the complexity off somewhere else (i.e. in the file grid.less that you need to include) and lets you specify your grid in a fairly simple way. Even better, there’s no need to add all those unsemantic classes into your markup. The extra constraint is that you have to use a CSS pre-processor such as LESS, so if you’re not already doing that, it does mean making some changes to your workflow. But after a bit of fiddling around I managed to get my example layout working with the Semantic Grid method instead.

@total-width: 100%;
@columns: 12;
@column-width: 5.625;
@gutter-width: 2.5;

#wrapper { padding: 1.25%; }
        
@media (min-width: 768px) and (max-width: 959px) {
        
    #header { .column(12); }
    .main-wrap { .column(8) }
    .side1 { .row(8); } /* Nested column container needs to be a row */
    .side1a, .side1b { .column(4,8) } /* Nested columns */
    .side2 { .column(4) }

}

@media (min-width: 960px) {
        
    #header { .column(12); }
    .main { .column(6) }
    .side1 { .column(3) }
    .side2 { .column(3) }
        
}       

As with my original approach, there is quite a bit of complexity in getting the nested columns to work, and this probably is the most fiddly part of the Semantic Grid code. Basically you need to pass a second parameter to the column mixin to your nested columns, as well as applying a .row mixin to the parent column. But having figured this out, it’s not too hard to use. Another small issue was that Tyler’s grid uses a system of equal numbers of columns and gutters, which means that you get right and left page margins equal to half a gutter width. I wanted a full gutter width either side, which looks a bit more balanced to me. Luckily I found it was possible to achieve a close approximation of this by adding an extra wrapper DIV around everything and applying a bit of padding to it.

CSS Sleeping Columns in Responsive Layouts

Fluid CSS grids are great because they give us a way to align content into a grid that responds to the width of the browser or device screen. However, as the underlying grid gets narrower we usually want to rearrange the columns so as to retain a comfortable amount of space for the content. Sometimes, of course, this means splitting a column into two new columns as it drops down into a new position.

Fluid CSS grids like this and this don’t seem to cover these kinds of complex break points. If your site has only a few templates then it’s not too hard to give each column a class and then assign them different widths as your media queries fire. But while I was working on some responsive templates for a really big website recently I started wondering about how to code these columns in a more systematic, re-usable way.

@media (min-width: 768px) and (max-width: 959px) {
    /* Tablet layout columns wake up here: */

    .tcl3, .tcl4, .tcl6, .tcl8, .tcl12 {
        float: left;
        margin-left: 2%;
    }

    .tcl3 { width: 22.5%; }
    .tcl4 { width: 30.666666666667%; }
    .tcl6 { width: 47%; }
    .tcl8 { width: 63.333333333333%; }
    .tcl12 { width: 96%; }
    .tcl-last { margin-right: 2%; }
}

@media (min-width: 960px) {
    /* Desktop layout columns wake up here: */

    .dcl3, .dcl4, .dcl6, .dcl8, .dcl9, .dcl12 {
        float: left;
        margin-left: 2.5%;
    }

    .dcl3 { width: 21.875%; }
    .dcl4 { width: 30%; }
    .dcl6 { width: 46.25%; }
    .dcl8 { width: 62.5%; }
    .dcl9 { width: 70.625%; }
    .dcl12 { width: 95%; }
    .dcl-last { margin-right: 2.5%; }

}

So what we have here is a system of classes for both ‘tablet view columns’ (.tcl) and ‘desktop view columns’ (.dcl), both working off the same underlying 12 column grid. Sometimes a tablet column and desktop column can share the same DIV. So for example <div class="tcl4 dcl3"> takes up 4 grid columns on a tablet, but only 3 grid columns on a desktop screen. But in other cases the columns will require separate DIVs, for instance if a single long desktop column needs to split into two separate tablet columns because it is slipping into a wider area.

Granted this is all quite complicated and can make your head hurt at times, especially when trying to put the markup together for a complex page. But the advantage of this approach is that after it is set up, we end up with a system of classes that can be applied to different layout templates fairly quickly, and without having to worry about percentages. Source order is still a limitation of course, and prevents us from using some layout combinations. To get round that you probably have to use Javascript to manipulate the DOM.

Adobe Illustrator Responsive Web Design Template

Responsive Web Design is a challenge for the traditional processes of visual design, where the standard Photoshop (or Illustrator) mockup tends to be geared towards a single fixed width view of each page. One way to meet this challenge is to decouple the overall look and feel (or ‘design system’) from the layout by using style tiles. I think this method has a lot of merit and is generally the best way forward.

Sometimes, though, it may still be useful or necessary to mockup how a given page will look at different sizes, before you reach the HTML stage. This might be the case if you’re still working at the branding and design system stage and want a bit more context for your style tile. Or maybe you need to show a client a quick preview of an important page.

If you’re like me and prefer Illustrator to Photoshop for web design work, you might find this template provides a couple of useful shortcuts. I’ve included five standard view sizes each on their own artboard and with device chrome for iPhone, iPad and a desktop browser (The device graphics come from Teehan+Lax who were kind enough to let me use them here).

I’ve also included a sample grid on its own layer, which represents a fluid grid with a maximum width. This is unlikely to be exactly the right grid for you, so you’ll probably want to delete all the columns and start again. I’ve found that the easiest way to create grids in Illustrator is just to use the Object > Path > Split into Grid command – although it can be a bit fiddly to balance gutter and margin widths if you want to end up with whole pixels!

In practice I tend to find that five sizes is too much and I usually end up deleting a couple of the artboards. Let me know if you find it of any use or have any suggestions for how to improve it.

New identity, new website

I’ve been running a small web studio now for 7 years. At the start I called the business Jackfruit (after the large, exotic tropical fruit), but in the last couple of years I began to feel that the name wasn’t working as well as it should.

I work in small collaborative teams and directly with clients as a consultant, and hence my customers tend to know me by my real name. Thinking about my business as a brand, I came to the conclusion it should be as simple, direct and honest as possible. Although I work a lot in teams, I don’t sub-contract or directly employ anyone else. So using my real name as my business name just seems to make sense at this point.

benhayes.com responsive web design layout shown at different screen sizes

Responsive design

I made the decision to ‘re-brand’ quite a while ago but it’s taken me ages to find enough time free from client work to create this new website. I can’t believe it’s finally finished! Part of the reason it took so long was that half way through I decided I really needed to learn the new techniques emerging in responsive web design (RWD). RWD is a solution to the growing problem of how to make your website work for the increasing number of mobile and tablet browsers. Instead of having to create a separate mobile version of a site (and all the extra production and maintenance work that entails) in RWD the layout of the page responds to the size of the screen by reconfiguring itself. If you are viewing this page on a desktop computer you can try this for yourself – gradually shrink your browser window and you will see the layout re-configure itself. Look at it on an iPhone, for example, and you will get a single column of content without the need to endlessly pinch-zoom to use the page.

Web type

Another huge leap forward for the web over the past couple of years has been the advent of viable font embedding. This site uses the excellent Museo Sans and Museo Slab typefaces, which are embedded using Typekit. What’s really nice is having a family of typefaces that are designed to work together like this, giving a large range of styles, all of which harmonise beautifully. I find that Museo also renders pretty well across OSX and Windows operating systems.

Finally

So finally, after far too long, I again have a website where potential clients can look at my portfolio, rather than having to cobble together endless emails of links and PDFs. Let me know if you spot any typos or bugs!