100+ Best Web Design Hacks and Tips 2019
A good visual designer understands how content and design are interlinked and how the designs they create will be brought to life. And a good developer knows how content and visual design affect their work, too.
Design encompasses many things; it is not just choosing fonts and colors, or even laying out elements on a screen. It influences and is influenced by, everything from content to code.
Web design plays important role in user engagement and Google ranking. This blog explores the 100+ New Web Design Hacks and Tips used in 2019 for rank higher in Google.
I assume that you and your team do not have the time for a complete redesign of your website or family of sites. So, your goal is to use the available time that you do have to create the maximum positive impact on how your users experience your website on any device and on any screen size.
In most cases, this constraint means the existing large-screen, fixed-width, desktop-first design will be reused if not in its entirety, at least partially. So it is this constraint that I will keep in mind when going through the steps in this blog.
Evolution, Not Revolution
The concept of evolution is the key idea that should drive the conversion of an existing website into responsive when you are not allowed the luxury of a lot of time and endless resources.
Responsively redesigning an existing website is the opposite of starting from a clean slate. You have to deal with legacy content, design, code, and processes, and these, for the most part, are likely to have to stay the same—at least, in the initial versions of the project.
You will have to leave perfection aside for a little while. The likelihood is great that you and your team will have to release the first iteration of your newly responsively retrofitted website with a few (or more than a few) edges left to smooth.
Consider some of the larger and most successful responsive redesigns of the last few years. And you will easily find examples, where alpha and beta versions were released as quickly as possible with many usability issues.
For users to experiment with and provide feedback on Many of these examples, were successful, not in spite of having being released with faults for everyone to see, but because of that.
Although this may not work for every type of website, allowing real users to try out your early prototypes is more often than not the best approach for testing.
If you multiply a few users by hundreds or even thousands, you may have a lot more feedback to sort through, but you will also have the benefit of your prototypes being tested in myriads of real situations, instead of just in the testing lab.
The big redesign unveil is out of date. These days, it is common practice to reveal at least part of the design process to the world at large.
This type of roll-out strategy is perfectly in sync with the idea of evolution and iteration. You and your team should accept that your website will not be launched perfectly, whether you launch it sooner or later.
You will prioritize the most important tasks that will get you the most bang for your buck—in this case, the best responsive experience for your users that you can achieve within your busy schedule. And you know that if you need to, you will keep on iterating and evolving your website based on real users’ feedback and testing.
Evolution means learning with the process, course-correcting when necessary, and keeping and refining the existing good parts for the next generations.
This is the way you should face the challenge of a responsive retrofit when you know that part or most of your existing design will have to be reused.
Slowly but surely, you and your team will achieve the design goals you will set out when you envision your responsive website. But that will not mean your website will have stopped evolving and getting even better.
Focus on Reusability
If the design of your website is going to evolve and not radically change, you need to be able to pinpoint what works well in the way you work right now, and which are the key areas to improve.
When time is of the essence, it is vital that you do not spend it redoing the things that are good enough to begin with—at least, in the initial stages of the project.
By using existing solutions, you will save time to focus on solving the trickier design problems and the issues that are most aggravating to your users. You want to spend your time fixing the issues that will have the biggest positive impact once they are solved.
This means reusing not only things you have done before but also things other people have done. You should understand that it is okay to copy and “steal” other people’s solutions—provided that adequate licenses are purchased and that credit is given where credit is due, of course!
Let me stop being vague: many things can be reused, copied, or recycled. Here are some items you can consider reusing from within your own team and organization:
Patterns and components
And here are some more things that you are likely to find in the wild, and that you can use on your own project:
Common responsive web design patterns
Scripts and other libraries and bits of code
Responsive grid generators
Typographic scale generators
You should also remember that you can get inspiration from something that already exists, but use it in your project in different ways than the most obvious ones.
For instance, you may want to carefully look into Bootstrap (http://getbootstrap.com), the popular front-end framework, not for its actual contents or to use it to build your website, but for the way its documentation is structured.
You may want to analyze existing grids of mobile operating systems and understand what you can learn and take away from them when developing your responsive grid, rather than simply analyzing the grid of responsive sites that you admire.
Make sure, however, that whatever it is you are using for your project is adequate. Just because someone spent time creating a framework or building a generator does not mean the product or its work is right for you.
Equally, just because something is prebuilt and somewhat generic does not mean your project’s quality will be compromised if you use it—provided you select wisely.
If your team is made up of clever people who are competent professionals, I am sure you will be able to reuse existing tools and patterns artfully and in such a way that the result translates into something that is your own.
Focus on Accessibility
Following on the ideas from the previous blog, of how accessibility considerations should begin in the way you produce content, they should also permeate your process through design.
If accessibility is something you tend to see as an add-on or one of the final steps in your testing process, your responsive retrofit project may be a good opportunity to start changing your ways.
As you have seen before, saying that someone has accessibility issues does not just mean they suffer from a permanent disability. Someone accessing your website on a slow hotel Wi-Fi connection has accessibility issues.
Someone who has broken an arm has accessibility issues. Someone in a highly stressful situation with a piercing headache has accessibility issues.
Making life easier for people with a temporary or circumstantial disability will, in turn, make life easier for everyone else: for the person with a super-fast broadband connection, for the two-armed person, and for the relaxed person. Everyone benefits.
Do not think that because you are actively making sure your website is accessible to everyone, you must create designs that are too simple or plain, and this constraint will limit your creativity.
With that concern in mind, I recommend that you read Sara Hendren’s “All Technology Is Assistive,” which exposes how accessibility considerations for a few can spawn incredibly innovative and interesting solutions for all: So, what things can you do in your designs and design process to ensure that accessibility is front and center?
The short answer is, loads of things—but that is not very helpful. Without getting into too much detail about such a broad and fascinating subject, here are a few simple things you can do to get started:
Install a color-blindness simulator that allows you to test your designs against common and less common types of color blindness, such as Color Oracle (http://colororacle.org/).
Make sure the target areas for links and other user interface elements are large enough and do not require fine precision.
Minimize the number of clicks and taps where possible.
Be consistent with the placement of navigational elements, and keep them in the same place across your website as much as possible.
Break up your content with headings and lists, making sure its hierarchy is well defined.
Avoid using large images where they are not needed.
Provide low-quality images as defaults instead of higher-pixel-density versions.
Do not hijack scrolling.
As I am sure you know, there are many other things you can do in your website to make it more accessible to more people, not just through its design but also in the front and back-end development.
Make it your mission to instill in your team the idea that accessibility is part of the foundation of any good website and that the effort and time spent on improving it will pay many times over in a more positive experience for all your users.
Discussions about performance are usually tied in with discussions about code and development. However, it is truly in the design stages of the project cycle that thinking about performance should begin.
The notion of setting a performance budget early in the project keeps growing in popularity, and for good reason. We are now designing and building websites that are viewed on a dizzying array of devices with completely opposing capabilities and on inconsistent connection speeds.
But designers tend to be working on super-fast Internet connections on the latest monitors, and more and more of them are using Retina displays. This is not a good representation of the reality of most users.
We have been hearing forever about how sites like Amazon work hard at making the website as fast as possible, to the last millisecond.
These efforts are backed up by testing and, for companies as large as Amazon, are reflected heavily in their profits. When your competitor is just the click of a button away, making sure you do not leave your customers waiting and frustrated is critical.
By defining a performance budget early on, designs can adapt to this constraint. In his article “How to Make a Performance Budget,” Dan Mall goes through a simple process to define a performance budget for the less technical of us.
He starts with comparing three key indicators—Start Render, Document Complete, and Fully Loaded—for his own website and competitor sites or sites he admires, and plotting those numbers in a spreadsheet.
He then sets a goal to reduce these indicators by 20%—a number that comes from research that states users perceive a task as faster or slower if there is a difference of at least 20% in speed.
This is not the type of constraint that designers are used to considering. But, as Dan says, “designers do their best work within constraints.” And I cannot think of a tighter (and perhaps more fun) constraint to work under.
No More Flats
On many teams, even the ones that work in a more iterative and agile way (whatever that means), the typical design process involves several iterations of Photoshop or Sketch mockups, which are exported and shared with stakeholders.
Once feedback is gathered from brand managers, art directors, product owners, the CEO, and so on, the mockups are updated, and another round of “flats” is shared. And so on and so forth, until all the design decisions are made and the ultimate mockup reflects all these considerations.
Even if these mockups are created in various sizes to represent different types of screens and devices, nothing will ever come close in terms of representing the final product as an interactive prototype that you can test on different, real, devices—that you can stretch and squeeze to your heart’s content.
There is nothing wrong with exploring the initial concept and flow of a screen or a page in a tool like Sketch.
It is important to sometimes have that time and freedom to just thinking about how colors, type, and space will work together to create a design that is beautiful and balanced. But do not think that this type of exploration can only be done when it is detached from code.
The serendipity that classic design tools can sometimes bring to a project can also happen in a prototype. And the color, type, and space that you want to get just right render in a completely different manner when you are dealing with HTML, CSS, and a browser rendering engine.
You can try dozens of different font family and size combinations in Photoshop, but when you try the same combinations in an HTML page on a small Android device, some of the options that looked beautiful before simply will not provide for comfortable reading.
Furthermore, making most of your design decisions in the browser is essential when you are trying to save time by cutting down on unnecessary steps in your process.
It is important that you and your team get your hands dirty as quickly as possible with the responsive retrofit project and start working with prototypes.
Making sure flat mockups are always up to date with the latest decisions and feedback wastes time that could be more cleverly used by iterating on a prototype. And if you are really, really pressed for time, there is even a way in which you do not have to open Photoshop and can jump straight into prototyping mode.
Setting the Rules
An easy way to delve into the prototyping stage is to start by creating a document in which you list the responsive rules that should be applied to your website.
This document consists of just words—no mockups and no diagrams should be needed—and it will be used by the developers to build the first responsive prototype of your website. That’s right, it is that easy!
These initial rules will have lived mainly in the heads of the people on your team. Writing down what you think a responsive version of your website may entail is a good exercise in taking that vision out of your head and making it into something more real that you can share and have discussions around.
The best way to gather ideas for the document is to get people in a room and start writing down all of their ideas on sticky notes. In my experience, this exercise works well if the group is not too large: maybe three to five people, making sure you include at least a couple of visual and user experience designers.
You may want to come into the session with a list of topics you would like to cover, so the brainstorming can happen in a more structured way and people have a better understanding of what you want to accomplish. You will probably come up with topics that are specific to your website, but make sure you cover the following topics as well:
It may also be easier if you suggest a couple of rules so that people understand what you mean by rule. And you should make it clear that these rules are not unchangeable. They will be used for the first responsive experiment, and you will iterate on them as you go along.
Once the first brain dump is finished, the next step is to sort these ideas within the topics and eliminate duplicates. If most people suggested a specific rule, it is likely that you will want to add it to your document; but you need to carve out time to discuss why some rules may be too complicated to try in this first test.
Do not discard anything just because you think it will not work, though—it may well do so. The goal of the sorting step is for the group to choose which rules you will include in the first version of your document and which ones you will put in the pipeline to try later if needed.
When you start working on the document, begin with common responsive patterns, but do not forget to be opinionated where you can. After all, you probably do not want to create a basic responsive website, but something that reflects your brand’s and your product’s personality.
Some examples of how to phrase common design patterns as rules that can get you started are as follows:
At the medium breakpoint, when there are four boxes in a row, the grid should make the row have two boxes instead.
At the smallest breakpoint, all content should be linearized into a single column.
The existing typographic scale should scale down proportionately by 80% (medium breakpoint) and 70% (small breakpoint).
At the smallest breakpoint, images that are floated within the text should have their floats removed and take up the full width of the viewport.
At the smallest breakpoint, all decorative images should be removed.
In smaller screens, the navigation should be replaced by a “hamburger” menu.
When clicking the menu, there should be displayed a list of the first-level navigation links, and links with sublevels should display a + icon to their right, which opens the list of sublevels below the top-level link.
Tabs should be converted into accordions, where the tab titles are stacked on top of each other. Upon clicking the title, its corresponding section is revealed. The user should be able to open all tabs at once.
If you are unsure whether you should follow one rule over another, it may be necessary to provide two (or more) alternatives so that the developers can try them both without interrupting the flow of work.
There may also be instances where you will not have any defined idea of how things should work, and summarizing a vague concept would be too hard.
In these cases, it is okay to state in the document that you want this particular element type or pattern unchanged so you can resolve it and explore different solutions in other ways later. You can do this for smaller elements, such as buttons or other form elements, and for bigger, more complex elements, such as navigation or images.
Leaving some things unchanged and giving them the opportunity to just “live” for a moment in a responsive space can lead to ideas that you would otherwise not have if all you did was stare at that particular design element on your large-screen design, thinking of how to shrink it.
If you are lucky, some of the elements you leave unchanged may not need any further work, at least in the first iterations of the responsive retrofit project.
Something else to consider, and that you may want to suggest, is that, while creating the prototype, the developer or developers also refactor the existing CSS to be mobile first.
This is not a small task by any means, but it is a great moment in the project’s timeline, when the team is in the mood for experimentation, to have a better understanding of how much work would be involved in refactoring the existing stylesheets to be mobile first, and whether that should be a step in the process or something to forget about.
Remember: these are the very first ideas you will try when making your website work responsively. They will certainly change and evolve as you go along. Some of these initial ideas will prove good or just good enough for a start, and some you will quickly discard in favor of some other solution.
After this meeting, it is easier if only one person is in charge of writing the document and sharing it with others to confirm that everything agreed on was indeed included.
The beauty of this exercise is that you can quickly experiment with some of the most common responsive web design patterns and assumptions, and test them straight away, to see whether they are the best solution for your website.
Designers do not have to spend much time coming up with rules, because they do not have to create sketches or comps; and developers have some flexibility in interpreting the rules and do not have to worry about replicating mockups perfectly.
Once you are happy with your initial document, the developers (or whoever is going to build the prototype) can take some time to go through the existing stylesheets and “add some responsiveness.”
I find it more effective if this is done as a group exercise, where two or three developers sit in a room together and can discuss any issues or ideas as they work through the rules. This can make for an intense and fun week that produces a tangible, useful deliverable by the end.
If questions arise during development that need to be answered or brainstormed with someone else, the developers can call that person into the room and have discussions about the pressing matter.
The goal is to move fast and get a prototype as quickly as possible. If it is too cumbersome to create a prototype of your entire website following the rules from the document.
Choose a key section or a selection of key pages that you would like to start exploring. But do not choose the easier ones. Choose sections that seem more challenging from the start—you want to dive straight into the deep end!
The result of this process will probably (or even most likely) be a bit rough at first, but do not let that discourage you. It is a great way to take that first step in making a responsive prototype and having something you can test on real devices.
You can use whichever format works best for your team to create your document: Google Docs, a Word file in Dropbox, a Basecamp text document, and so on. Just make sure whatever you use can be easily shared, edited, and commented on.
[Note: You can free download the complete Office 365 and Office 2019 com setup Guide for here]
Breakpoints are at the heart of responsive web design: they define the widths at which your layout will adapt to better fit and make use of the space available in the viewport.
There are a few different approaches to determining breakpoints on a responsive website. The consensus these days seems to be geared toward a more content-based approach, where the breakpoint is determined at the size where content starts to break, where it becomes harder to read, and where certain components do not have enough space to completely fit and need to be adjusted or moved.
Another popular approach (and possibly more prevalent) is to choose a few breakpoints, determined by the most common devices either on the market or used by the site’s visitors. At these breakpoints, the layout and order of content may change, and there may be significant differences in the way the grid works.
Both approaches are valid, but the latter one may mean the chosen breakpoints will soon become outdated by technology. When you link your designs with whatever devices are available now, once a new type of device comes along, you will have to revisit your decisions.
Decide in the Browser
In your responsive project, you are probably working from a large-screen design, which you will leave mainly untouched, down to smaller sizes. This is the case for most responsive retrofitting projects that do not have scope for a complete redesign.
In this case, the exercise I outlined in the previous section, of creating a fast responsive prototype based on a document with simple responsive rules, can be very helpful for making decisions about how and where to rearrange content and reflow design patterns. You can see where your content starts to break by looking at it on real devices, and you can make decisions based on that tangible experience.
Another interesting exercise that you can do quickly in-browser is to remove all floating, widths, and positioning rules from your CSS and see how your content behaves when it is stacked linearly.
Doing this, and then resizing the browser window, will very quickly give you a good idea of how many breakpoints your content may need, and you will see how your content responds to very wide and very narrow screen sizes.
Weak points and Breakpoints
A technique that I particularly like, and that is also content-based, is when you have a few breakpoints at which there are dramatic changes to the design and layout, but there are also breakpoints at which there are only a few adjustments to some components and style.
Jeremy Keith calls these weak points. This approach respects the content and the components of your website; it only changes them when they need to be changed, not just because everything else has changed due to a big breakpoint.
What to Keep in Mind
Regardless of which approach you decide will work best in your case, there are certain elements you should analyze carefully when you are determining where to add a breakpoint or weak point.
Mark Boulton recommends that you direct your attention to a few key elements that may need adjusting when you are studying the way in which your content adapts to a resized viewport:
Type size and leading
Micro and macro whitespaces, such as margins and paddings
Number of words
When to Use Analytics
Looking at your analytics will not answer the question of the points at which your content breaks when resized. For that, you need to look at your website. But getting an idea of the sheer diversity of screen sizes on which users visit your website is certainly something you should do.
By looking at your analytics data to check what common screen sizes your users are on, you will see that the gulf between the larger and smaller screen sizes can be immense.
You will also see that there is not one true mobile, tablet, or desktop size: the variety is never-ending, with countless tiny differences between them. This will open your eyes to the idea that your website should truly be fluid and adaptable to any size of the device.
Defining a Style Guide
Creating a style guide is not an easy or a quick step, but the benefits that it will bring to your responsive project will be collected in heaps. I really believe this is not a step that you can skip if you are serious about making the move to responsive and you do not already have a style guide in place.
Your style guide can be more or less detailed, to begin with, but it will create a framework for the work you will be doing, making it easier for people within and outside your team to communicate about design.
A style guide will help you and your team focus on reusability—an indispensable component of making your website responsive when time and resources are scarce. A style guide will save you and your team time because it creates a consistent style that is easier to manage and to understand.
When something needs to be designed, you can refer to your style guide to see what rules you have already defined for that particular type of element. When someone asks for a variation of your existing patterns, you have a document to back you up when you ask them about the reason for the deviation.
The point of defining a style guide is not to redesign your entire website in the process, but to examine your existing design, extrapolate design patterns that are used consistently, and define how those elements should be used across your website.
You may prefer to run the creation of your style guide as a separate project from your responsive redesign. If you do so, make sure you complete the first version of your style guide before you delve into your responsive retrofit.
Because the style guide will serve as a solid foundation from which you will make important design decisions. As you make your website responsive, your style guide will be updated accordingly.
Although the creation of a style guide from the ground up does not have to be a task that takes up a large amount of time and resources, it is important that you and your team are committed to creating it and that key people in the organization are on board and supportive of your efforts.
Just as you need a person who will champion the responsive retrofit project as a whole, you also need someone on your team who will drive and evangelize the creation of a style guide.
Even when the entire team is in agreement that making a style guide is important, having someone whose responsibility it is to see the project through is imperative. As with many other topics in this blog, the subject of style guides is broad enough to call for an entire series of blogs dedicated to it.
I will provide you with the steps you can take within the responsive retrofit project that will help you get started with your first style guide.
Screenshots, Screenshots, and More Screenshots
The first step you need to take when creating your style guide is to make an inventory of all your existing design patterns and components. The easiest way to do this is to go through your existing website, take screenshots of all the components, and save them into different folders.
Ideally, the screenshots would be taken by a few different people. But if it is not easy to find the time to do so, you can assign the task to one or two people.
You will probably end up with folders for the following:
… and so on
Organizing the screenshots this way, where you can quickly look at them together, makes it easy to see variations that should be rationalized, similar patterns that should be merged into a single one, and patterns that need to be removed.
Take screenshots of small elements (like a single button or an input field) but also of large elements (like the header of your website or a form fieldset with all of its components).
Do not take screenshots of every instance of the same component, but rather of every variation of a component. If you spot a button that looks exactly the same on different pages, take only one screenshot of it.
If you spot another button that varies by 1 or 2 pixels in border-radius, take a screenshot of it. If you spot another button that has slightly larger padding than the first one, take a screenshot of it.
I am sure you get the drift by now. You will be surprised to encounter slight deviations from an initial design pattern that you thought was consistent across your website. And this may happen frequently, so be prepared to spend a fair amount of time with your team defining rules for how the patterns should work.
The next step in the process is to, together with your team, go through the inventory with a fine-tooth comb. Whether you had to take the screenshots yourself or assigned another team member to do it, this step should be done as a group.
You need to have a discussion about each of the elements you have identified and its variations, to decide which patterns can be merged with others, which patterns are redundant and not needed, and which variations should be made into a separate pattern As important as visual consistency is, you also want to achieve naming consistency.
Keep your ears open, and write down the names that different people give to different components. Do most people call the navigation “main nav,” or is it “header nav” or something else? Make sure at the end of this process that you have agreed on every name in your style guide. Several cups of coffee or tea may be needed!
There are a few different schools of thought when it comes to organizing a style guide. Do you call patterns atoms, molecules, and organisms, according to Brad Frost’s Atomic Design?
Or style, layout, and components, like Google’s Material Design? As usual, you must make the decision based on what works for your team.
As part of these discussions, you should also consider how each element will behave in a responsive world. If you are creating a style guide for a fixed-width website (and if you are reading this blog, you are likely to be), this is an excellent opportunity to think about how each individual part of your website will stretch and squeeze depending on the size of the viewport.
By decoupling your design patterns from the pages where they sit, you can start thinking about them as repeatable objects in a system of templates and pages. You will focus on their reusability across the entire system, rather than what they look like on a particular page or screen.
As usual, remember that all the decisions made during these discussions should be well documented, shareable, and searchable.
I will not go into too much detail about how to build your style guide so I do not run the risk of taking up the rest of the blog on this subject. There are several tools you can use to create your own document; one of the most popular is Pattern Lab (http://patternlab.io/), by Brad Frost and Dave Olsen.
In all honesty, a simple one-page HTML file that lists all of your patterns and their names, and that is linked to your latest CSS, is enough to start with. This is what I recommend when you do not have much time.
Think about what information should be contained in your style guide and the level of detail you need to make sure your document is useful for its target audience. You will probably want to include some or all of the following elements:
Name of the pattern
An instance of the pattern, not just an image of it
Description of how and where it should be used
Description of how and where it should not be used
Other patterns that can be used alongside it
HTML and CSS code needed to use it
Link to the location in your CSS files
Make sure you talk to a variety of people who will use the style guide before you decide what information to include. Some may prefer to just be able to grab some code, whereas others may find it more useful to be able to read about correct usage.
Clean Up Your Style Sheets
After creating a style guide, and as part of the same process, you should make sure your CSS reflects the same thinking and follows the same rules you and your team have determined. Otherwise, the style guide will have been made in vain—a static PDF file that shows all your design patterns will not suffice.
Duplicated components should be removed, but you should also remove redundancy from your CSS files, making them more manageable and easy to understand. This step may sound like a no-brainer, but it is easy to forget after you have spent so much time rationalizing all your design patterns.
When You Already Have a Style Guide
If you have an up-to-date, non-responsive style guide, then a lot of the work is already done for you. You will still have to examine your style guide and consider how your patterns may change in a responsive world.
But if your style guide is not up to date, then you need to go back to the first step and make an inventory of your existing patterns, which you can then compare with your out-of-date style guide.
Standardize across Sites
It may be the case that your team oversees not just one website, but an entire family of sites that sit under a common umbrella, partially or fully sharing the parent’s brand and visual direction.
In this situation, the definition of a style guide or pattern library is paramount for making sure the brand is applied consistently across the different properties, especially when considering a move to responsive.
This is where the standardization process that you go through when defining a style guide will really pay off.
Each element and component that you define not only will save time for one team but also is likely to save time for several teams. A shared style guide will allow each team to consult a single source of truth for your several components.
They will not have to try to find who to speak to, to know whether a design for a certain pattern exists; they will not create duplicated work for a pattern that is already available and usable; and they will not ask teams further up the organization for resources to create designs that are already in place.
Flexibility and simplicity are key for this to work well. When you create a style guide that will be shared across different websites, you need to think further in terms of how prescriptive your design patterns should be, and which options you should give designers and developers when applying the components on their own website.
Should you provide less complex patterns that they can build on based on their particular needs? Or is it easier to provide a larger assortment of more detailed components from which they can pick and choose?
These are some of the considerations you should discuss when going through your pattern inventory and making decisions about which patterns to keep and which to adapt. It is worth noting that the inventory itself will be bigger because it must include as many sites as you think necessary, so you can compare the different usage of the same pattern.
Remember that standardization does not translate into sameness. There is always a place for new ideas and for thinking outside the box, even when you are working with a solid style guide.
Think about how chaotic and difficult to manage it would be if every single element of every single page of your website was designed differently. (I am certain there are use cases for this scenario, but that is not applicable to most sites.)
You should explore this idea more deeply than I can cover in this blog, including how to technically implement a style guide that trickles down onto different sites that may have different needs.
The solution will depend on your current development stack and your processes, and also on who owns each different website and how easily you can reach those owners.
I think I have established by now that this blog’s main focus is on using your team’s time cleverly while you convert your fixed-width website to responsive. But what about research and user experience? How can you get things right with so little time on hand?
We all know that to truly understand the goals of a project and, most important, the goals of your users, research is not something you can skip. If you want to improve the experience of your users, you need to be able to put yourself in their shoes and know what they want to get from your website, and how.
I assume that the main goal (or one of them) of your responsive retrofit project is to provide your users with a great experience when they visit your website on any device, be it a massive iMac or a tiny Sony Android.
You want them to be able to easily read your content, navigate your pages, and perform any tasks they want to or need to, whether they are at their desk or on the train.
On the other hand, you already have a website, which your team probably put a lot of effort into creating and improving, even though it is not yet responsive. You probably have at least some knowledge about your users and some data on which you can base decisions.
You will have to improvise and understand that it is not the end of the world when you do not have the time and money to follow a rigorous UX process.
Sometimes you have to go with something faster and cheaper, making sure you use cleverly all the skills and expertise of the members of your team. There are a few things you can do to make smart decisions—using the information you know and your team’s experience—that will keep moving your project forward.
It can be a bit daunting to have to visualize an existing fixed-width, wide design in a small viewport when you have not done so before, or when the content is so complex that you do not know where to start.
I find that if you make little wireframes or quick sketches on sticky notes that represent one small part of the page, such as a single row, it makes it easier to begin exploring small-screen solutions for that particular element.
Not everyone is a fan of printing out web pages, but a simple exercise that you can do to start generating ideas of how your pages may reflow on smaller screens is to print a few of them and quickly sketch on sticky notes how each part of the page could be constructed in a small viewport.
You can stick the notes alongside your printout to make a tool that can kick-start interesting conversations around your design and content flow within your team and with stakeholders.
Let’s clarify one thing: prototyping does not necessarily involve code. And it probably should not involve code in its first stages. The first thing that should pop into your mind when thinking about prototyping, particularly when you are moving at the speed of light.
Despite the immediacy of paper, getting to a point where you have a prototype that you are happy to share and the test may take time. But it does not have to be that way. Let me show you an example.
Let’s say you want to design new navigation for your website that works well across different screen sizes. A good way to kick things off is to gather a few members of your team from varied backgrounds for a brainstorming and sketching session.
Do not only invite designers. You can mix things up by having visual, UX, and interaction designers, developers, and copywriters, for example.
You should set aside at least a couple of hours for this session, perhaps even an entire morning or afternoon, with a break or two in the middle. Start the session by looking at other sites’ navigation patterns and discussing how those examples could potentially work, or not, in your case.
This is an easy way to get the creative juices flowing and break that initial awkwardness that is so common at the start of many workshop-type sessions. You can ask people to think of one or two examples beforehand, or you can propose the examples yourself at the session.
After this, grab big sheets of paper and markers and sketch the ideas that have come up during the initial discussion. Use as many sheets as you need, and draw as many ideas as you can in the allotted time—you do not want to discard any ideas at this stage; you will get to that soon enough.
As you draw and discuss the sketches, you and your colleagues will find issues with some of the ideas, and you will begin to sift through the options. At the end of this session, you may end up with a couple or a handful of ideas that you think might work for your website.
The next step, building a prototype, will likely be completed only once the session is over. You must decide, based on how much development time you think you can afford, whether you will build all the ideas you think may work, or if you need to whittle away some options and only test one or two alternatives.
Once the first iteration of your prototype is built, you should reassemble and test the prototype on a few devices. Having first-hand experience with how it feels to use your design is paramount for being able to create a great mobile experience.
You will know where the prototype fails and where it succeeds, and you can gather feedback from the other team members and iterate based on that until you reach a solution you are happy with.
If you have time, you can and should test the prototype with people who are not directly involved with the responsive project.
You can test either the original paper version or, if you prefer, a digital version of it, which can be reproduced in a tool such as Axure or InVision. Even informal testing can help you to quickly test a new design pattern or a certain device and to validate assumptions.
Testing does not have to take a lot of time and cost a lot of money. Finding participants and hiring testing labs can be an expensive endeavor in itself (albeit worth it), let alone the time it can take to analyze the results and produce digestible findings. The solution is guerrilla testing.
If you have not heard of this concept before, guerrilla testing is all about getting feedback from users quickly and cheaply. To run a guerrilla testing expedition, take the following steps:
Choose a location where your target audience may hang out (choose somewhere they would have 10 minutes to spare, not somewhere they would be in a hurry).
Set a goal for the test. What do you want to know? What questions do you want to be answered? Be specific. Knowing whether people love the design is not very useful, but you may want to know whether people can find more content to read after they have read one of your article pages, or if they get stuck.
Define what tasks the users can perform that would answer the questions. You do not want them browsing aimlessly until they find what you want them to find.
Here is an example: “A friend just posted this link on Twitter. You click the link and look at the article. You like the website and want to read more. Where would you go from here? Do you know what this website is about?”
Gather all the necessary gear, and head outside. Ideally, you would be a team of at least two or three, making sure there is one designer and one developer present.
Someone should be conducting the interviews, and another person should be taking notes, or recording the sessions if the participants have given written permission to do so.
Select between five and ten people with whom to test your prototype, and go through the testing protocol.
Ask people to think out loud as they try to complete the tasks. Some users will keep quiet unless you keep prodding them to think out loud.
Do not just ask them what they think about what you are showing them; be specific. Where would you click now? What do you expect to find once you click there? Did it match your expectations?
Avoid asking leading questions, and do not explain too much of what they are looking at.
If testing on paper prototypes, keep non-relevant screens out of sight from the user, so as not to distract them, and only reveal the screens when appropriate.
You can also test around the office or with people you know if you are looking for answers that do not require a very specific type of user. But be aware that these people may be tempted to be positive in their comments because they know you and/or are close to the website.
Once the testing is complete, remember to catalog your findings, even if you did not do formal testing. It is a good idea to summarize the key findings in a digestible format, highlighting the most important actions that should follow and things that can wait. After you have improved your prototype, go do some more testing!
Key Things to Test
If you feel overwhelmed by the idea of doing usability testing with users, because you want to find out whether many parts of your website are working well, start with the following topics. They greatly influence the experience of the entire website:
Can they navigate your website? Are the labels in the navigation self-explanatory?
Can they find further content once they have read a certain article or page?
Can they find help easily?
Is the search functionality helpful? Are the results produced usefully?
Does the product information page include all the details they want to see?
Is the checkout process easy to go through? What are the main obstacles when trying to pay?
For all of these examples, how well can they be performed on small and medium-sized screens?
Grids and Type
Websites are mostly words aligned within grids, inside rows and boxes. This is certainly a simplistic way of describing a site’s design; but based on these very simple elements, we create a multitude of different designs that are starkly different from each other, each with a different personality and looks.
That is why spending time considering your type and grid will provide a sound foundation for your refactored responsive website. The reality of an existing large-screen design that you have to work with will not make it easy to create a solution that diverges much from the common responsive solutions.
But you can still create something that works well for your design and for your content, and that works beautifully across all screen sizes.
Convert Your Grid to Percentages
If you are feeling a bit overwhelmed by the amount of work ahead of you, a quick exercise you can do is to convert all the units used in your existing CSS grid from absolute units (such as pixels) to percentage units, while keeping the site’s main container (or containers) using absolute units. You do not even need to touch your HTML in this case.
This exercise will give you the ability to—by removing the fixed-width container— test how well your existing grid and its underlying CSS will react in a responsive world. You can test a very rough fluid prototype on small-screen devices and determine how much work is required to come up with a robust, flexible, responsive grid.
This does not have to be a time-consuming exercise, especially if the product of the experiment is not going to be made live for users.
However, if you do choose to make it live, remember that your users will not notice the difference anyway, because your website will still be in a fixed-width container. The changes will all have been made beneath the surface.
As with many other steps in the process of converting your website to being responsive, this will be a collaboration between developers and designers, and a step that not everyone on the team needs to be involved in at the same time. One developer can make the CSS changes for the rest of the team to test later.
Explore Responsive Grids
Understanding your site’s underlying grid and how it will change and behave in a responsive world is an important part of the foundation of a good responsive design.
Things do not have to be complicated. Some simple rules may help you to visualize how your grid works and how it could behave depending on the size of the viewport.
If you have followed my suggestion of creating a document with some initial responsive rules to build your first prototype, you have already written down some basic principles for how your grid could scale up and down.
Let’s start with a very simple example: A 12-column grid in large screens scales down to 6 columns at its medium breakpoint, and then down to 3 columns at its smaller breakpoint.
Now, if you consider how the same content would fit on a screen size one-third smaller, you will notice that not everything can stay the same as before. You must make decisions about what happens when parts of the content become harder to read because they are squished too narrowly.
In this case, the first row can still be divided into two boxes that take up 50% of the width. But if the contents on the second row keep their proportions, the smaller box becomes too narrow.
So maybe you need a rule that says at this breakpoint, in rows that contain two boxes, those boxes should all take up 50% of the width, even if they didn’t initially. And what about the third row, with three boxes?
It is really up to you. You could continue from the previous rule and state that in this case, the boxes in the third box should fall down to their own row
The order in which elements have been laid out in your HTML can dictate how it will reflow on small screens. Depending on your existing designs, it may well be the case that less relevant content comes first in the markup.
In many retrofitting projects, touching the HTML is not an option, but there are a few tricks you can put to good use to make sure the most important content is seen first.
One very simple way to lessen the importance of a block of content is to show it only partially. You do not want to completely remove parts of your content from small screens. In this scenario, you make it so that only the title of that section is visible; to see the full content, the user has to click or tap the title.
Wikipedia applies this trick on its mobile website for all the sections of entry except the introduction. Rather than having to scroll through what can be extremely lengthy pages, the user can have a quick glimpse of all the headings and select only the one they are interested in.
If you have related content, advertising, and other things that are not part of your main content area and that exist on some type of left sidebar, chances are they come first in your HTML.
If you squash these into headings, you will save the user some scrolling to get to the meaty bits. A more complex solution for unorderly content is to apply an off-canvas solution.
Here you effectively hide the part of the content that you do not want to show front and center. This is typically applied to navigation, but it can also work on sidebars.
A link or button on the edge of the viewport, when clicked, opens what usually behaves like a digital drawer, revealing more content or links I will not go into detail about how this can be implemented, because it can be complex. But it is a pattern to consider when restructuring and reorganizing your content for smaller screen sizes.
Finally, you can also consider using CSS flexbox to reorganize your content based on media queries. The power of flexbox lies in the ability it provides designers and developers to lay out content in any order or direction, regardless of its order in the markup, in the section “Improve Your Markup.”
Adjust a Strict Typographic Scale
When moving from large-screen, fixed-width website design to small screens, it is unlikely that you will be able to maintain the same font sizes. When defining font sizes across different breakpoints, you may start by determining the ideal sizes based on a precise typographic scale.
You may even have already applied a carefully crafted scale to your existing website. If this is the case, you can start with what you have and iterate from there.
If not, there are several tools you can use to generate the most appropriate typographic scale for your needs, based on the size of key elements in your designs such as an important widget, the size of your featured images, or the width of your main content area, to name only a few examples.
These typographic scales usually produce font sizes that provide the perfect visual balance and ease of reading when used side by side. But you should not feel that you have to stay married to a strict typographic scale.
If you have a defined large-screen typographic scale that you plan to maintain, you can, for a start, reduce all the font sizes proportionately as the screen size reduces. Once you have done so, and you have a working prototype of the responsive scale, you should test the prototype on real devices to get a better perception of how it feels to read your content.
You will easily spot where the text becomes too small or too large to be read comfortably, and you can improve the prototype until you have a typographic scale that works well across different screen sizes.
It is very different to read a piece of text in a narrow window on your large screen (or even an emulator) and to read it on an actual small-screen device, like a smartphone. So, make sure you test the prototypes on the real deal.
This process may sound simplistic, but it involves a lot of trial and error and testing across a range of devices; do not be fooled by how simple it seems at first. The readability of the words on your website should be one of the main goals of your responsive retrofitting project, and there is truly nothing like testing and iterating on real devices.
Handling Your Images
Most responsive retrofitting projects have to handle responsive images to some extent. One of the big differences when making an existing site—with lots of existing content, and therefore many existing images—responsive is that you may not be able to go through every single image and reformat or resize them to adapt perfectly to a new responsive state of affairs.
So what can you do when the time is sparse, to make a difference when making your website responsive? What should be at the top of your priority list, and what things can you leave until later?
Make an Image Inventory
Before making any kind of image-related decisions regarding your responsive project, you must understand what kinds of images are being used across your website.
Without this knowledge, you will not be able to make the best decisions for your website. To find out what types of images are used on your website, you need to conduct an image inventory.
Just as in a content inventory, this involves a thorough investigation of your website, with a focus on images and, potentially, other types of media such as video and audio.
This may sound like a daunting prospect. If you do not think you can accommodate a full image inventory in your schedule, you can consider analyzing only a representative section of your website.
Do this if you think that it is more appropriate for your case and that you can confidently cover all the different ways images are used across your website.
The most common image types that you may find on your website are as follows:
User interface icons
Purely decorative images
For each type, you want to get a better understanding of
The image’s importance
Where the image will be placed
How the image plays with the rest of the content
In which contexts the image is being used
Who produces the images
Who is uploading the image to the website
Just as you did for your content, create a spreadsheet in which you can catalog all the information you find about your images. You should highlight the images that may be trickier to deal with, such as complex diagrams and infographics, by assigning to each image the difficulty of handling it in a responsive website (for instance, from 1 to 3, where 1 is easy and 3 is difficult).
You can use the following list as a starting point to lay out your own spreadsheet:
Name: Name of the image, include a thumbnail if possible for easy recognition.
Location: Where the image sits in your site’s IA.
URL: A link to where the image lives.
Type: Illustration, UI icon, photograph, and so on.
Format: The file format: .png, .svg, .jpg, .gif, and so on.
Author: Who created the image?
Owner: Who commissioned and is in charge of replacing or updating the image?
Difficulty: Is it a 1, 2, or 3? (Or use whatever another scale you have decided on.)
Notes: Anything else worth noting.
Only after you gather this information can you compare solutions effectively and possibly arrive at a few different solutions for various types of images. Many of the ways in which images can be handled in a responsive retrofit have to do with the way the website is coded and built.
I go into more detail about these in the blog. But there are a couple of things you can do in your design and design process that will greatly impact how difficult this task is later.
Mind Those Bytes
It is easy to forget about the impact your designs will have on how fast and lean your sites are when visited by users.
By creating designs that are respectful of the user’s time and money (many times, more bytes mean slower loading and more expensive data charges), you will save your team a lot of headaches later on in the process.
Before splashing enormous, transparent, Retina-ready PNGs all over the page you are designing, think about whether that will truly improve the user’s experience. Do all the images need transparency? Do they all have to be full width? Can you do with only one larger image at the top and then smaller ones throughout the page?
Can you design another solution that does not involve images at all? Do not assume that users will take in stride whatever you throw at them. If the big images you put on your website do not provide any value, they may consider going somewhere else.
This tip may not necessarily be realistic to apply to your existing images. You probably do not have the resources to reconsider every image across your website and think about whether it can be removed.
But it is something to keep in mind as you work through future iterations of your design, as you add new pages and new sections, and as you make further improvements to your responsive designs and processes.
SVG stands for Scalable Vector Graphics. The name says it all. SVG images work like Illustrator or Sketch vectors. You can scale an SVG file without it losing quality, which is a super-useful thing when you are dealing with a responsive website.
Clear candidates for a transition from bitmap to an SVG format are user interface icons, logos, diagrams, and illustrations.
As images go, this is one of the most important steps you can take when making your website responsive. Converting to or sourcing your icons and illustrations in SVG format may take a little time.
But the benefits of using an image that does not become pixelated when stretched, and that is usually smaller in size than its bitmap counterpart, will keep paying you back. You should also remember to put in place a process that makes sure in the future these types of images are always created in SVG.
Do not think that all images should be converted to SVG, though. If an image has more complexity, such as gradients and drops shadows, re-creating it in SVG will likely increase its file size. So make sure you carefully compare the file size before and after and assess whether any increase is a compromise worth taking.
If you want to go a little further, you can even consider a more radical change to a flattering style of images and illustrations in future redesigns or updates to your website. Along with other responsive image techniques, I explore the more technical side of implementing SVG on your responsive website in the blog.
Some Useful Responsive Web Design Patterns
Several design patterns have become commonplace when creating responsive sites and are becoming more and more intuitive for users as they come across these patterns on many different sites. You want to make sure when you are converting your own patterns to responsive, that you look at what the most common design patterns are.
In many cases, those will be just right for you. Other times, your particular case will require a little more design exploration, and you will need to come up with a different solution.
Do not disregard commonly seen responsive design patterns in a quest to be different. Many times, perhaps even more often than not, the common patterns are prevalent.
Because they are the simplest to understand, not the other way around. Here are a few key responsive design patterns that may be useful for your website when handling two of the trickier elements: navigation and tables.
Smaller sites with a simple information architecture may find easier solutions, but when things start to get more complicated, thinking about navigation responsively can give you headaches aplenty. The following patterns tackle websites with complex navigation systems using intuitive solutions that may work for your website, too.
Dropdown and Slidedown (Single and Multilevel)
This is arguably the most ubiquitous solution for websites with sprawling IAs, including newspapers and e-commerce sites. It usually involves either an icon or a label (or both) that sits in the header section of the screen and opens a list of links to the various sections of the website.
The list can either cover the content (dropdown) or sit above it (slidedown) when it is open. Variations of this pattern include multiple levels of links, which can be opened and closed from within the list of top-level link.
This pattern can be useful when you want to maintain the horizontality of wide-screen navigation on smaller screen size, also giving you the flexibility to have as many top-level links on your navigation as you need.
In a way, it works similarly to the priority+ pattern; but in this case, to be able to see all links, the user scrolls horizontally within the navigation area to reveal more links. If you apply this pattern on your website, you may want to consider purposefully cropping the last visible link, to hint to the user that there is more to see
If we put images to the side, I think tables are one of the trickiest design problems to solve when converting what was once a fixed-width website to be responsive. The patterns that follow will provide you with some inspiration and ideas on how to handle these unwieldy creatures.
This is possibly the simplest solution for responsive tables. In this case, the table shrinks with the viewport just until the content would become too squished in the columns.
At this point, the table does not grow any smaller. Instead, part of the table overflows the width of the viewport, and the user can swipe to see the rest or change the orientation of the screen to increase the visible area.
Getting the Most Out of Feedback and Reviews
Reviewing the work as you go along is part of the process of any design project, and yours is probably not an exception to the rule. There will be stakeholders who want to be kept up to date with your progress and others whose decisions will influence the path of the project.
Whether they are the design director or the company’s CEO, you should make sure you define the design-review and sign-off process for your responsive project.
When time is restricted, it is important that feedback is requested in a clever manner to be useful and actionable, that reviews run smoothly, and that they are translated into useful time spent first discussing designs and prototypes and then making improvements that in the end will benefit the user.
It is also of the utmost importance that you and your team be able to justify with solid arguments why you have made certain choices over others in your designs