Not too long ago, in order to make websites look good on desktops, laptops, tablets, and phones, web developers would produce what were essentially complete different sites. They might all draw content from the same database, but their layout, graphics, and styling were all carefully compartmentalized. You may remember domains preceded by the letter "m" (for "mobile") that were served up whenever you viewed them on your phone. Plenty of them still exist—even at hyper-advanced sites like Facebook (click here for proof).
As most developers knew at the time, this was a stopgap approach. What we needed were ways to serve up the same code regardless of device, and have that code detect the device and respond appropriately to it, making changes—sometimes radical ones—to the way content was displayed.
The past few years have seen tremendous advancements in CSS ("cascading style sheets"), the "language" that controls much of a website's appearance. While we had to wait on web browsers to catch up, we now have a wealth of "responsive" tools at our disposal.
Your developer may also mention terms like “LESS” and “SASS” - these are basically just advanced forms of CSS. All you need to remember is that they’re all the basis of “stylesheets,” which are just sets of rules for determining how certain things on web pages are displayed.
So as you proceed with your new website, you need to make sure it is responsive. Most developers will assume this is what you want, but not all of them will, and unless you’re in a very tiny percentage of business owners for whom responsive websites aren’t applicable, you don’t want to get roped into paying someone who can’t, or won’t, deliver a responsive site.
Have your developer send you several links to sites they've developed, and make sure to look at them on your phone and tablet, in both vertical ("portrait") and horizontal ("landscape") modes. If they "break" in any of these modes, then it might be time to look for another developer.
Responsiveness dovetails into another concept: "Mobile first," which is just another geeky term for "this website is designed on the assumption that most people will view it on their phone."
What flows from that basic assumption is: “If we as developers have to make compromises, we’re going to make the mobile stuff look good and function well, and just do the best we can with the laptop and desktop stuff.”
Whether your site needs to be designed "mobile first" is something you'll need to talk to your developer about, but every year that goes by, the consideration becomes less important for most businesses, because responsive techniques are becoming more ubiquitous, and the line between mobile and non-mobile sites becomes more and more blurry.
But we’re not quite to the point where you can dismiss this question entirely. Have some brief but candid discussions with your developer about the use cases of your site, just in case important decisions need to be made about mobile-first design. For example: What percentage of your users will be viewing your site on a phone? What kinds of things will they need to do while they’re on the site? Is there anything they need to do that’s significantly more difficult to do on a phone than on a laptop? How can those tasks be made easier through the use of everything from bigger buttons to a completely redesigned workflow?
Good developers will put themselves in the shoes of all different kinds of users, and they’ll be able to pose questions back to you to get a sense of how your site development should proceed.
Next in this series: We talk about “the cloud” and content-delivery networks.