As it is becoming increasingly important for companies for their website to work properly on smartphones, tablets and desktop computers, the demand for responsive design is also increasing. It’s no different at UNITiD. We are involved in a number of responsive design projects and today I’d like to share with you some of my personal experiences in the form of a few practical lessons.
1. A responsive design project takes longer…
When we design something to be responsive, we design it to cope with different screen formats. Usually we work with four different formats: large (desktop), medium (tablet), small (small tablet) and extra small (mobile phones).
This means that once a page has been designed, the design then needs to be adjusted to the different screen formats. For every viewport the layout is optimised, during which we often redesign a page for every screen format mentioned.
Even though we’re mostly reworking existing designs, optimising these layouts to work properly on all screen sizes takes up more time than designing a static, non-responsive website. Not even taking into account the additional work needed for testing and (front-end) development.
2. Users expect the same information regardless the device.
User tests and web statistics indicate that users expect to find the same information on a website, regardless of the device they are holding in their hands. Showing information on a desktop and leaving it out on a mobile view is simple not-done. But how do you make content accessible on every device?
A workflow that has worked well for us at UNITiD, consists of taking a webpage design and deriving a set of components from it. For each of those components we then define how this component should behave at different screen formats, for which we have four options:
- Show: We show the component as it was originally designed.
- Change: The component changes according to the screen format. The component can also be merged with another component.
- Hide: The component is moved into a dropdown, collapsable menu, carousel, etc.
- Delete: If the component is not suitable for use on certain screen format, leave it out. But only if there really is no other viable option.
3. Design templates first, then components.
Working with components can vastly improve the workflow for the development party, but to ensure a visual hierarchy of individual components within a page, it is recommended to design a page at a template level.
Even though it seems time efficient to work at component-level, to ensure the developer can already start on that first component, it will soon become clear this is not the ideal process when at a later stage the absence of a visual hierarchy on the page becomes apparent. At that point a redesign will be necessary, a process consuming considerably more time than it would have cost for an initial template design.
This is why we recommend to first design templates and then divide them up into components. This also works better for testing, as end-users will always judge the full page, not their individual components. Preferably testing is also done on different browsers on various devices in order to cover a wide range of screen formats.
4. Define device-specific rules for content you can’t control
More content is being generated by end-users every day, and we don’t always have full control over this content. To ensure a certain level control, it is recommended to define a set of device-specific rules, based on screen formats, to deal with worst-case scenario’s.
To define these rules, ask questions such as: Across how many lines may a title run? When is a line break allowed? What should happen when text doesn’t fit in a content block? Do we cut a line short by using ellipsis and do we add a hyperlink for the full text? What is the maximum amount of characters allowed on a button? etc.
5. Document frequently used elements in an online styleguide
Often multiple designers work together on a responsive project. In order to streamline the design process, it can help to define a styleguide at the start of the design process. New elements can be added to this guide as the project progresses.
A styleguide is a manual for designers to help guard the visual identity of the client. In this document frequently used elements (such as atomics) are defined; for instance buttons, links, carousels, arrows, scrollbars, promotion stickers, ribbons, ratings, social icons, tooltips, etc. But also layouts, icons, margins, typography and color values are specified in the style guide.
A style guide can best be placed on a testserver in live coded form. This way style elements can be individually developed and presented and ensures easy access for everyone. It also prevents inconsistent or incorrect use of previously designed elements.
Continue reading
Want to find out more about responsive design? Continue reading on our responsive web design page.
