Open Search

Common digital design guidelines for offline designers

July 9, 2018 1:18 pm
Categorised in:
Reading Time: 6 minutes

Compared to the static nature of print, the web is an ever evolving beast where a rectangle can be a circle and designed dimensions can be meaningless or rigid and unbreakable. As such here are a couple of simple traps that offline designers can often fall into. The biggest win for yourself is to use Sketch as it’s a tool for the modern web design age and can hand off to a tool like Zeplin, where you can create a style guide which is much better for developers. However, most offline designers don’t know or use Sketch, so these ‘rules’ are predominantly for Photoshop, but it’s probably good practice to observe some of these ideas across different design applications.

1. Please work at 72dpi. DPI isn’t relevant to devs so they will ignore it anyway. However, screens are based on 72ppi, even retina devices refer to screens in pts rather than pixels, so a 1440×900 retina display is treated as 1440×900 not 2880×1800. Working at full pixel resolution, unless you are very aware of what you are doing, will lead to font-sizes being too small on screen.

2. Unless agreed otherwise, please use Bootstrap grids as a base. Bootstrap provides grids for mobile, tablet, small desktop/tablet landscape, and large desktop. By working to these grids you are working to a common set of formats in a language that devs can interpret and should be familiar with.

2A. This doesn’t mean you have to utilise the entirety of Bootstrap if you just use the bootstrap grid. A sensible developer will just grab the grid scaffold css and use that if no other elements reflect Bootstrap components. Although looking at the components within bootstrap will give you an idea of all the elements you will probably need to consider harmoniously.

3. Please work all mobile designs at 320px 72dpi, this ensures that the smallest screens are catered for. Scaling up a mobile display by simply adjusting widths (and where appropriate, relative heights) is way easier when starting at the lowest base width and makes sense rather than starting in the middle at 375px for example.

3A. However, when exporting images for mobile, you may find it better to export from a document sized at 414px width 72dpi. This means that 3x images for Plus devices are captured at optimal quality.

4. Optimise your images. Large images cause longer load times. You have 7 seconds of load time max before the user will sack off your page. At which point it doesn’t matter how pretty your images are because the user is gone and probably not coming back.

4A. For raster images ensure that within Photoshop you have smart objected at the highest possible resolution the base image and any additional layers for that image composition into one group. This allows you to set up Photoshop generator to output these at the required sizes.

5. Remember that unlike print, the frame of the document you design in rarely encapsulates the entirety of the window the user will use. So if you use an edge to edge image, at desktop, that image will not necessarily end at the 1336px width you’ve designed for (for example). You need to bear in mind screens up to 2560px in width or 5120px at Retina and have generator assets ready appropriately. Devs don’t understand or care as they have an awful lot of other stuff to be doing. So by ensuring your documents have assets exported already (or set to export) as you want them, you have a greater chance of the finished result looking inline with what you wanted and a more logical arguing point when they don’t.

6. Pixel perfect probably isn’t going to happen, and if it does it’ll just be in one browser. Pixel close enough across as many browsers and devices is what you should aim for. Not because pixel perfection can’t be attained by a competent dev, more because browsers themselves do not render the same content the same way. This effect is lessened with layout options in todays browsers but typography is the most noticeable example of a common difference in rendering. Pixel perfect often adds a degree of rigidity that works perfect for that design at that state, but doesn’t allow for a web page’s life cycle which can include imagery changes, copy changes, or entire sections being added or removed.

*** Update 11/07/18 *** And lo, Mark did receive one of his mailing list emails, resplendent with a link to evidence that proves exactly this point, using the most common element of all; the humble div.

7. 90% of making a design really work for screen happens in the browser or on device. Try to get your designs signed off as quickly as possible so that you have more time to be looking at how everything handles in-situ. If you don’t have the time to spend on massaging rough edges of the design when front end is being completed, you are leaving it in the hands of the developer to massage them as they choose. There are tools available to send your designs direct to your mobile device to give you a better idea of how it feels in the hand.

8. Communication is key. I’m terrible at this. But the more you can work together with your developer in the early stages, the more they can either mentally prepare for the task at hand via research or go off and find the solution to something with a prototype. Any requirements docs should capture intentions, but there is often a lot in requirements docs and your edge-case design thought can easily be lost in the mix. Especially when working waterfall when there may be gaps of time between designer/developer interactions.

9. Group elements appropriately in your document i.e. all header elements should sit in a top level group called header, with components broken down individually into smaller groups. It’s much easier to get hold of things when they are grouped together.

10. Your screen is probably bigger than your audiences. I look at a lot of Analytics and I look a lot at the devices used and the screen sizes. Don’t want to burst a bubble but 1366×768 is still pretty much the baseline for most popular desktop screen size (dependent on audience). This is good because you can capture everything in the large bootstrap grid. This is bad because inherently you will not view your designs at these dimensions unless you keep an awareness of this, so important information may not fit above the fold. Whilst the fold doesn’t exist in terms of a non-scrolling device that prevents users from going deeper into a page, if the user can’t asertain that content relevant to the need that drove them to that page is available on that page from first landing there is a greater chance of the user bouncing.

11. The grid is for content, but think about how your sections start. Do they start against the first gutter of the grid or do you actually mean to start against the chrome of the browser window?

12. Just like you can’t write code, your developer didn’t spend years mastering Photoshop or the rules of typography. Nor do they care. They have a big job to do and the reality is, you probably aren’t seeing below the surface of their iceberg. Help newer developers by explaining that right clicking over the name of a layer exposes a “Copy CSS” option. Using this the developer can copy out key attributes to ensure your designs look right. There is a lot of positional stuff in there not relevant to build, but they can remove that Allowing them to just get the stuff they need but never check like font-sizes, colours, leading (line-height), or drop shadows (box shadows). There is no better working document than a fully realised Photoshop document, but without the right stuff being in place at the right time, it’s useless.

13. Old browsers exist and usually need to be supported at an SLA level. This means certain features won’t work on certain devices. Work with developers early to ensure that your ideas will work across browsers and if they won’t you can work together to create a solution where the layout isn’t predicated on the existence of your things that can’t be handled in a browser. In the development world, this is called graceful degradation. The opposite would be enhancing something for users with more current browsers, this is called progressive enhancement. Supplying retina imagery for example could be considered progressive enhancement, where as supplying a png backup to an SVG logo is gracefully degrading.

14. Oh, that reminds me, USE SVG’S WHERE POSSIBLE FOR NON RASTER GRAPHICS. Seriously. Personally I store SVG data as a smart object that can be reopened in Illustrator. Illustrator has some really good SVG export tools whereas Photoshop is more fiddly for SVG. You don’t even necessarily need to outline copy with SVGs from Illustrator as you can embed fonts or glyphs into the SVG. This retains live text for the user which is good for accessibility and usability but also means you can change the text live in the browser if you require.

14. Anything is possible, but remember reality often comes with deadlines and budgets. For best results, make sure your design is more than achievable within these limits so that you have more time to play with the work on device, in a browser.

15. If you are creating a full screen interface, consider what happens when the browsers height is reduced. A full screen interface will have to not only deal with responsive break point changes in width, but also handle any layout changes that need to occur dependent on the height of the inner browser window, reducing font-size is one such consideration to make.

16. Ultimately, you want to be working at more of a component basis anyway, not holistically designing pages. The ideal is you design pages to show that these components work harmoniously on the page together, not knocking out template variants until you die. A pattern library provides a good intersection between brand guidelines, working documentation, and shared assets between designer and developer.

This joint was penned by @elmarko