Nowadays pretty much every website comes as a responsive design website. Despite the fact that responsive web-design (also known as RWD) is a term that to some extent is flexible, some people still use it simply as a replacement term to say, that they want a mobile site. I am not going into that direction in the current post but might touch on this at a later time. So the focus for me will be the actual responsive web-design today.

Things to consider when planning a responsive design

You do not just come up with the idea of creating a responsive website. There is a client asking for better usability on their smart phone, customers in a shop have trouble reading the type, etc. The good old 2006 website simply does not work so well anymore in many cases.

When planning the process of relaunching a website with a responsive approach, it makes sense to clarify the reasons upfront. Why does it need to be responsive? Or would it make sense to have a mobile site and a desktop site? How can one differentiate between the two? Does the device type trigger this? Is the plan to administrate only one website? Let’s get into a few core issues to check upfront.

Responsive vs. mobile and Desktop website

Both options offer great advantages and disadvantages at the same time. A responsive website is based on the same code and content for all devices visiting the site. When a device is smaller it might not get the same images loaded (often times these should be smaller in dimensions and file size) and it might be that a few decorative elements are not there to ease the load on the smartphone, but in general it is the same content. Only the viewport defines how the content is displayed and arranged. You might go to whatismyviewport.com to see what your devices say about their size. Based on these values a design is delivered to the device. The great advantage: Create the content once, serve it up in the proper design, done. But you cannot change too many things around, because that might create the need to have content only for a mobile version and hide that on the desktop and vice a versa. Google might not like hiding things on some devices and showing it on others.

The mobile plus desktop version on the other hand brings the need to manage and administrate two sites. Content might not be shareable and if things are limited by the systems being used it could mean that one has two entirely different sites to cherish. This could mean trouble. The problem arising as well: What is a mobile site? Some treat every device with touch capabilities as mobile (including your iPad and larger tablets). That can be quite a pain because you might try to cater one design to many different devices. And a blown-up design from a smartphone usually disappoints on a tablet. So what could work? Based on media queries / the size of the devices?

It is imperative that you think about the needs and implications before going down any path whatsoever, be it the RWD or the mobil/desktop way.

Who were/are/will be your visitors?

Here is a really important thing: Where are your visitors coming from? What are they using? Smartphones or desktops? Where is the best conversion. What are the trends? Is mobile on the rise? I bet it is.

When looking at these facts and data bits you should extrapolate the changes. See what has influenced the sites traffic and how. When did mobile visitor numbers get a boost?

This might severely influence the way you have to treat your plans and the importance for your mobile site design. Despite the fact that „mobile first“ is more of a development term, it has actually been adopted as a way of approaching the concept phase as well. You consider the website appearance and structure for a mobile visitor and only then you work your way up to the bigger breakpoints (the points where you decide to have a change in the design, based on the „width of a device“). Basically you are enhancing the design/layout with every bit of space you get.

Do we need layouts for everything?

In the past you might have had a designer creating the design for your homepage and that was followed by a category page and a  product page and maybe a contact page.

Now is that the way you need to work again? Consider this: You have 3 zones between your breakpoints, one for smartphones, one for tablets, one for desktops. do you really want a designer to create 3x the amount of layouts, costing 3x the amount? There is more work involved in general when it comes to RWD, but doing this is to some extent plain crazy. If you can somehow arrange for layouts not being needed for everything it saves money. I will talk about alternatives later.

Is your design and your development team within each others reach?

When it comes to RWD you cannot afford to have these two in their own respective silos. It will create time consuming and costly communication problems. These two trades need to move closer together. More on that later as well.

Which devices should I design for?

As mentioned above it is of great importance to check who is coming to your site, now and in the future. But do not design for the iPhone 7 and the Galaxy S8. Design for device groups. You do not know what happens within the next few months. A new breed of phones comes out. everybody loves it, but your site only takes care of a certain phone. Phones change, but they have things in common. Design for that and always assume that something might change beyond a breakpoint. And that is okay as long as you treated that area with the same love and care. When Apple started  to change the ratio of their screens after introducing the iPhone 5 and 6 respectively it became obvious that even the most change resistant companies might change things eventually. So be prepared and do not rely on two many facts from one corner of the market.

Which steps should be taken for a successful responsive design?

In order to keep the length of this post at a digestible length I will keep this part short and rather break the detailed information into separate posts in the future.

Conceptual groundwork

The important thing upfront is a conceptual base which includes and pays attention to all of the essential bits of information from all departments and groups involved in the process. This means design and development as well. It is important to get everyone on board in order to avoid trouble later on in the process. Collect and gather all information, demands, wishes and limitations first. Let all project parties evaluate the information and get together to see what needs changing or fine-tuning.

Wireframe and sketch

With the basics checked and the concept in place it is a great thing to sketch out your templates/views/pages/screens – whatever you want to call them. Use pen and paper to be fast for the first ideas. I personally use my own RWD pad to get things done super fast. Read more about the RWD sketch pad here on the blog as well. Let me know if you are interested in a pad.

Once you have things laid out and on paper it is a great idea to go back to the designers and developers. They love to give first feedback and help to improve.

Of course there are many other additional tools in the digital space: Omnigraffle, Balsamiq, Axure,  sketch … the tools do not really matter, it is a matter of preferences and what exactly needs to be wireframed.

Design by stiletiles

Use styletiles to get the design process started. Personally this is the way I currently think things should be going. Based on the creative briefs available to the designers one can get great first traction and move forward quickly without wasting time and budget. It is simple to get everyone on board and discuss design, not where a button should be positionedor whether that shirt from the top left teaser is still available.

The styletiles are a wonderful starting point to have a first set of interface elements ready for the developers to implement. In case the project is a bit bigger, it is more than valuable to consider using a pattern library / living styleguide or whatever one wants to call it. I will stick to pattern library for now and will dive deeper into this topic later on as well.

Browser, baby, browser!

Instead of creating all the things in Photoshop and producing layouts which will be of barely any value except for the design process and the presentations to the management board, things should come to live in the browser. This way one can shape the site from a design and content point of view, test on different devices, get a feeling for how the site will feel like.

The great thing: Changing a button colour in CSS takes seconds. Updating all 21 photoshop files takes an hour. So guess who is not going home early today? The team still using Photoshop all the way.

Content production

Personally I have experienced a lot of relaunches where the site and CMS were ready just hours before the launch date and time. And then the alarm bells rang: „All hands on deck!“ Everyone needs to stuff as much content into the system as possible. What a crazy approach, and how prone to error! The earlier everything is in the browser, the earlier the CMS will be there in most cases. This means that many things can be done in terms of editorial and content work at an earlier stage. It simply does not make sense to have the whole production pipeline running later because one runs the project on a strict waterfall style process where the design is blocking the rest of the development because some CEO still does not like the yellow as much as he/she would love to.

Summary

This is only the beginning of a series of many posts to come. There are so many aspects to how a great relaunch and/or RWD project should be handled. I hope that I have left you with a few first impressions and things to pay attention to. Feel free to get in touch with specific topics and questions which I would love to cover in future posts.

Last but not least I would love to point you to http://UIengineering.de (in german language): Together with my good friend Dennis, who is an outstanding front-end developer, we try to bring more of these things to everyone's attention. There is a podcast, a website and we share many articles (in english and german) under the hashtag #UIengineering. Feel free to follow this and contribute when you have something to add to the discussion. We are happy to see what you have to share!