How about a high-tech box that travels around Brazilian ad agencies collecting ideas that, for some reason, weren’t produced, broadcasted or spread?

Google was interested in establishing a closer relationship with Brazilian agencies. But they wanted this relationship to be unlike the traditional ones that happen between the agency's Media team and Google's commercial department. Google wanted to build a truly engaging partnership with the creative department of those agencies - to show how Google can make their craziest ideas come true.

And we all know that the craziest ideas are rarely the chosen ones. Instead, they are kept within the creative's moleskine, waiting for the right moment to happen.

Let your ideas play

In 2012, Google and R/GA built a platform to collect those ideas and collaboratively select the best ones to be produced. A jury composed by the most awarded Creative Directors from the top 10 digital agencies in Brazil was responsible for evaluating and selecting the best idea - that would win three prizes: investment (a cash prize to boost the idea), coaching (mentoring sessions in Google's headquarters in the US) and a videocase (to promote the idea and attract more investors). 

And, of course: we created a shiny-looking box to collect the ideas that were left behind.


What does it do? It collects the handwritten ideas and shreds them right after they were inserted into the box. A few minutes later, you receive an email from Google inviting you to login and claim the ownership of that idea on Google Creative Sandbox website.

But those users hold a very peculiar attribute regarding their web usage habits: they browse on the web through a great variety of gadgets. Ok, not really: only iPhones, iPads and iMacs. But with that in mind, R/GA has chosen a Mobile-First approach when designing and developing the website that would host the ideas submitted by the creative teams.

What is Mobile-First Responsive Design, anyways?


A common procedure amongst designers is to start thinking of a website as a desktop version. That comes from a tradition in the way designers are used to work: the web was born on a desktop and only after a decade, it started to populate other gadgets such as smartphones and tablets. The designer habits, by inertia, ends up following pretty much the same path. 

The issue is that users do not think that way. They want to access the website, and they don’t really care if they are going to access the “desktop” or the “mobile” version of it. 

That concept does not exist within people’s minds.

I’ve had a chance to work on many other projects where Interaction Design started with the desktop version. The same things happens with Visual Design and Development.

At a given moment, the team magically remembers that the site will also be visualized on mobile phones. What they normally do is to try to adapt the desktop site content that is being developed to a narrower version that will be read by smartphones.

That isn’t Mobile-First Responsive Design.

A great problem with this old approach is that designers spend days struggling when trying to “cut” or “making it fit” within a smaller screen. But that isn’t necessarily the solution people want or need when they are browsing on a smartphone.

The first step before getting your hands on it is trying to understand the user’s needs with each gadget. 

A practical example. If you visit a restaurant website when you’re at home, sitting in front of your computer, it is very likely that you have time to see its pictures, learn more about the chef and read some of the options on the menu. But if you access the same website on your mobile phone, you’re possibly in your car, parked in a double lane, and you need to confirm the restaurant address in less than 5 seconds. 


Those are different functions that the website does depending on the context.

“Every device does not need to have the same experience. Trying to maintain the same experience in all devices is dated. It is an obsolete approach. People understand different devices provide different experiences.” -Jeffrey Zeldman

Understanding that context and deciding which content is more relevant to each case is a task that could/should be done by a Developer and a UX Designer at the same time. Without that initial logic, Responsive Design ends up being only for show - not becoming relevant to people that will use it.

Enough said, now I’ll dig into the details of my first Mobile-First Responsive Design website. I hope you enjoy it.

Same website across all devices

The website URL is always the same. You don’t need to type “” or “”.

That may sound a little obvious, but for users, it is interesting because they don’t need to think if they want to browse on the mobile version, or tablet version, or desktop version. Also, the transition between devices feels seamless, since the URLs for pages are exactly the same on every device.

For developers, it becomes an interesting solution because it means that a single website will be built - mitigating the issue of dealing with different versions of the same website when you’re working on its maintenance or evolution.


Navigation and Information Architecture also need to be thought out for each situation. On the Google Creative Sandbox website, navigational elements that were hidden under the “Menu” button on the mobile version before, now are all visible upfront on the desktop version. Another concern regards the relation between global header, local header and footer; it was important to take into account that the smaller the device, the smaller the time people navigate on it.

A lot of patterns are being created around the reorganization of the website layout from the Mobile to the Desktop version of it. That’s what we call “Adaptive Layout”. If you want to take a look at cool examples of that, I recommend visiting; if you want to learn more about those patterns, I suggest this blog post by Luke W.

Content (not only layout) adapts to each screen resolution

If you are accessing a website on your mobile phone, you’re not likely to browse on a video gallery and watch all the videos one by one (and you probably can’t rely on a good mobile connection for that). If you are accessing the same website on your huge iMac, you’re very likely to be a designer that cares a lot about the interface visual details and about your own comfort when you’re reading something. 

Instead of simply “making it fit” within the user’s screen resolution, we developed a different reasoning for each usage context. Elements and functionalities that appear on screen change; navigation changes; the amount of time that you have to read copy changes. And of course, there is no “mouse-over” state if you’re browsing on a tablet and using your own finger as a mouse pointer.

The image below explains the content distribution on the website homepage. The content we used to explain the project is different on the desktop version, on the tablet version and on the mobile version. You’ll also notice that the amount of copy changes from one version to the other.


That required very close work sessions between UX Designer and Developer. It needed to be clear for both which content would be loaded and shown on each website version.

The iteration cycles were short and frequent: any changes needed to be decided in real time throughout development, sketched on paper and documented by the designer afterwards. The fact that both UX and Developer had some good Visual Design knowledge was also helpful to speed up the process: if we had created one PSD file for each screen resolution, we would have needed dozens of Visual Designers working at the same time on the project. 

Copy was one of the things that needed to be adapted as the website was being built; agility was an important aspect to make the project fit in the timeline. If you are used to work with a cascade methodology (where your work is done after you finish your wireframes), maybe it is time to reorganize the team and rethink some practices.

Images also needed to be rethought depending on the screen resolution. It does not make sense to load a 640x480 pixels image if it is going to be visualized on a much smaller screen. But it’s not simply about resizing the image and forgetting about its size in kilobytes: the HTML needs to display a reduced version of that same image, or sometimes a different image, or even do not display it if it’s not really important for the mobile user experience.

In order to reduce images, we needed to take into account their content. When you reduce an image that has a dominant subject on it, reduction works pretty well. See the example below: even on the smallest size, you can still understand that the picture contains “a hand holding an iPhone”.


But when the subject is not dominant in the picture, reducing is not the best solution. If you simply reduce it, its content will not be clear enough.


In those cases, we needed to come up with the best way to crop that picture in a way the user is still able to see what is important in it. That’s the type of decision that needs to be thought case by case.

Progressive loading

Now taking a look at the code: the shortest path would be to simply make the browser load the desktop version and then just “hide” from screen the chunks of content that wouldn’t make sense if the user is browsing on the mobile version. But if you do that, you are forcing users to load content that would not be visualized and to spend one of the most precious resources they have on a smartphone: kilobytes of data.

When you build the website using the progressive enhancement approach, it will only load content that is essential for that specific device on which users are browsing. The order in which elements are loaded was also thought to fit the way people navigate on that device.


The html page is the same. Once you increase screen resolution, the html creates new ajax requests for specific content that has not yet been loaded. But you need to find the balance, since not all content needs to be loaded via ajax; part of it, the lighest one, could be already hidden within the code.

Choosing the best breakpoints

“Breakpoints” are screen widths (in pixels) where the website starts to transform itself and to add extra content depending on the device you are using. For example: after 410px width, we understand users are not browsing on the “portrait” mode, but “landscape”. And we offer them a different interface and a different content based on that.

Breakpoints we used for this project:
• Mobile
• Mobile Landscape
• Tablet
• Tablet Landscape
• Desktop

Do a quick test: open the Creative Sandbox website on a new tab and try to resize the browser until its size looks like a mobile phone screen. You will notice there are a few “key moments” on this resizing process where content is hidden or shown or edited to give users more comfort while reading it. 

Choosing the breakpoints is a definition that depends on the type of user that is accessing the website. On that subject, I strongly recommend some research to understand who are the visitors and what types of devices they own.

Responsively building, responsively learning

This was only my first Responsive Design project and I am quite sure many more will come - each one of them bringing a lot of learning along. Hopefully I’ll be able to share more of it here.

The fact is: there is no “right way” or “wrong way” of build websites that adapt to multiple devices. If you have ever worked on projects like that, feel free to drop me a letter at 

Bonus: backstage photos and docs.