Is The Corporate Website Dead?

According to some trend watchers, a little research, and a few live examples, the corporate website as we know it may be ready for some disruptive evolution. 

To put it more plainly, the corporate website may be dying a slow and painful death.

Corporate website visits for most large brands are declining. Your best content is lost among too much product promotion. And more attention is being stolen away by more progressive brands who have started acting like publishers and displaying content that your customers actually want to consume.

This is not just headline bait. There appears to be a growing consensus that the corporate website as an online brochure displaying “About Us,” “Our Products,” “Latest News About Us,” and “Speak To A Representative” isn’t working.

There is some convincing research to support this:

  • According to Webtrends, nearly 70% of Fortune 100 corporate websites experienced declines in traffic, with an average drop of 23%.
  • 90% of website traffic comes from just 10% of the content and more than 50% of the traffic is from just 0.5% of the content. ~ InboundWriter
  • 60-70% of B2B marketing content goes unused. ~ Sirius Decision
  • 60% of the buyer journey is complete before prospects reach out to vendors.  ~ CEB

I guess this shouldn’t be a surprise. We’re all watching the slow death of the newspaper industry. We’ve heard a lot of talk about how brands need to act like publishers.  We’ve seen major advertisers talk about how their advertising is evolving into something more closely resembling content marketing.

Now that there is a steady drum beat decrying the death of the corporate website, I sought to get to the bottom of this to see if we’re actually going to see some real change. And after reviewing some of the research and reading up on the evidence, I think there just might be something to this trend.

Why Your Corporate Website Should Die

In early 2011, Forbes Contributor Christine Crandell wrote that the customer experience for most buyers is inconsistent and disconnected.

She pointed at the corporate website as a “traditional marketing vehicle” (ouch!) that companies should abandon due to the overwhelming evidence that most visitors scan the page and leave because they are not looking for information about your products. She believes corporate website visitors are looking for useful information such as best practices tips, human stories and the ability to interact with real people.

Her guidance to corporate website owners:

Rather than boring your customers to death, there is a clear opportunity to put the dull corporate website to rest.  Then resurrect it as a platform for true community engagement that functions as a hub for interaction.

Corporate Websites Should Facilitate Moments of Authentic Interaction

All the way back in January, 2010, Brand Consultant Simon Mainwaring penned “The death of corporate websites” blog. He declares that “the online presence of a brand will increasingly become the sum of its social exchanges across the web and not the website that many currently call home.”

He also defines a massive change in the role of the brand manager to become one of a “social officer, facilitating as many moments of authentic interaction with consumers each day as possible.”

Four years on Mainwaring contends that “this shift is largely complete as we see brands shifting their media weight from traditional to social media, sharing stories across multiple channels and responding in real time, and training their employees to become social media brand advocates. So while the corporate website persists, it has now been reframed as a point of departure for customer engagement, rather than a destination.”

Content Is King And The Corporate Website Is Dead

A few brands are getting into this game and they are not looking back. In November, 2012 the Coca-Cola company declared the death of its own corporate website.  They re-launched their website under the tagline of “The Coca-Cola Journey. Refreshing The World, One Story At A Time” which featured content driven by their “Unbottled” blog.

I had met their super-sharp Group Director of Digital Communications and Social Media, Ashley Brown a few months before this announcement and was just blown away by what they were doing.

Even more important, is that they paused 6 weeks in, looked at the data and realized that what they thoughtwould resonate with their audience wasn’t working.

They endured their way through an “editorial scramble” based on hard data and implemented a new design and content strategy based almost completely on the kinds of stories their audience wants. According to Ashley:

Replacing a transactional corporate website with a digital magazine upended how we work

He continued:

The corporate website is dead and “press release PR” is on its way out.

Michele Mehl agreed that the corporate website is dead when she talked about how Coke successfully turned their website into an online news channel in her article on Geekwire.

Brand Publishing Is Not Just For Consumer Brands

I know what you’re thinking. Coke is not a B2B Marketer. But I believe the evidence they pointed to, the cultural shift they implemented and the approach they took to make content their main product are all just as relevant to B2B marketing professionals.

Maybe even more so. The B2B decision process is harder, longer and more complex. Delivering effective information and telling stories that build trust are still the cornerstone of effective B2B marketing.

Luckily, just in time for my research on this article, Sam Fiorella at Sensei Marketing published “Why Build a Corporate Blog Instead of a Corporate Website?” According to Sam:

Our goal is not to promote ourselves but our thinking; our website is not a sales tool but an educational one.

They realize that the main goal of their site is to build relationships and trust. Not to promote their products. And they also realize that this is a gamble. I think they are onto something. And I wish them luck!

I realize this nearly 1,000 words is a lot to take in. Thank you if you made it this far! Now, please share your thoughts in the comments below. And please follow along on TwitterLinkedInFacebook  and Google+ or  Subscribe to the B2B Marketing Insider Blog for regular updates.


Change your focus and design “Content First”

Content is king, it always has been and always will be. Content is why users visit your site, subscribe to your newsletters and follow you on social media. Content is the single most important aspect of your website yet for some projects that I’ve worked on, content seems to be one of the last things to be taken into consideration by clients when it comes to the redesign and rebuild of their site.

“Content First” is a term that I’ve been using for a while. As someone who doesn’t have a background in content writing or strategy, I’ve found it particularly difficult to express myself about this in more than 140 characters while at the same time not resembling verbal diarrhoea… so here goes.

Where “Content First” came from

Having your client’s content before starting the design process isn’t the be all and end of designing content-first. “Content First” is about giving the website’s content first priority over every other aspect in the design process. This is a concept I learned to realise after years of mocking up homepage layouts with nothing more than filler text and placeholder images or a fuller idea of what the client wanted to achieve.

As designers it’s not only us who are required to take on a “Content First” mindset, this is a process that will require the full co-operation of our clients. Communication is always a vital part of the client/designer (agency) relationship and it may take some convincing on your part to help guide your clients towards a content first methodology. I think we can all for forgiven at times for expecting too much from our clients with regards to knowledge and/or experience in the web but for content first to work, you will need to work hand in hand with your client to make sure that their goals are achieved.

Being asked by a client to ‘mockup a few ideas’ seems great at first, you can create a few layouts, throw in some filler text and some placeholder images and you think you’re there. You feel good, you’re happy that you’ve been able to turnover some designs for a client that you really want to impress and you PDF those designs up to send them over for feedback. You provide design concepts hoping to get the ball rolling on the project, give the client some idea of where to start from and ideally provide some inspiration to get the client on a similar level of enthusiasm as you.

This is where it can all start to go wrong. Designing blind like this may actually have the opposite effect on the client, seeing designs they might not have been expecting from an initial meet may actually result in them ‘reassessing’ the project and leaving you in a position to claw back the positivity that was originally invested in the relationship.

Changing Focus

How many times have we been asked to use ‘filler’ content and stock imagery so that the client can gauge and approve the layout of their new site? The correct answer is too many. The benefits of adopting a content first method can include optimised, relevant and efficient content which will increase awareness, visitors and ultimately sales but the process can also result in an overall more efficient project. Would working with Lorem Ipsum do this? If you answered yes to this, you’ve been very fortunate thus far.

By having content that you and the client have worked closely on to hand rather than dropping in filler text, not only are you already closer to a more complete, finalised design that can be signed off for development, but your design is a lot more content focussed and will give the client a more accurate idea of how their message is going to be delivered to the website’s visitors.

Say no to Lorem Ipsum

Lorem Ipsum and, to an extent, content management systems have given clients a get out clause of supplying designers with finalised and approved content before the design process gets underway. If I had a pound for every time I’ve heard “we’ll know what to supply when we’ve seen the design” or “we can replace the text in the CMS anyway can’t we?” I’d have been able to retire years ago on the interest alone. It is lazy on the client’s part for not being particularly bothered about supplying content until later and dangerous on the designer’s part to rush through the design process without it and underestimate the effect final content would have on the mockups.

5 lines of Lorem Ipsum in your mockups may initially fit well and the client might love how it looks but what happens as soon as the client eventually replaces the filler text and either shoehorns their own content into the design or they realise that they don’t really need 3 calls to action? The design breaks and you’ve wasted time.

Wasting time is dangerous for both the designer and the client. Time wasted can result in slipping deadlines, disgruntled management and what about the knock on effects with budget? Would your client be happy to continue paying for you to produce concept work with content they’ve not supplied? How many concepts would you be happy supplying until you’ve realised that the fee you’ve quoted is resulting in a smaller rate by the day?

The lesson I’ve learned is that I’m an idiot for designing a site with filler content and an even bigger idiot for developing a site designed with filler content. All problems and issues that would be avoided by using a content first design process.

Designing “Content First”

We design for the web, a singular entity that isn’t defined by a device’s resolution but a format with only one constant – the content. By designing “Content First” we’re stripping away all of the nonsense and focussing on what is important. Designing “Content First” is about gathering your client’s assets and laying them out within the design in order of importance, optimising the content for a web audience and ensuring that the message(s) and/or features that the client wants to get across to their users is consistent across all devices.

It’s a workflow that puts content at the centre of the focus, not the style, not the transitions between slider frames, but communicating the goals/product/mission in a user friendly fashion and one that I have found greatly beneficial.

Discuss using a content first method with your clients, as I previously mentioned it may require some arm-twisting as it will require more involvement from them but the benefits far outweigh the negatives. By adopting a content first design process your projects will become much more efficient with fewer design iterations, more accurate design mockups, less time wasted while waiting for assets and from the client’s point of view, projects will meet not only deadlines but budgets too.


Why you should move that button 3px to the left

When a product is close to launch, I become a perfectionist. Each misaligned element or awkward interaction is like a thorn in my side. There’ll be a dozen tiny implementation mistakes that taunt me each time I run into them. Everything seems so broken.

But to everyone else on the team, the product seems fine! It’s functional. They ask, “Will moving that button by 3 pixels really improve our product?” They argue, “The last time we fixed a small design bug, the product didn’t feel any different.” And so the team moves onto the next big idea and the next set of features.

If you’re anything like me, this situation can be incredibly frustrating. As designers, we are held responsible for the overall quality of the experience. Yet we’re at the mercy of our teams. We can design beautiful, intricate, delightful details — but we can’t build, test, and deploy them all.

How do we convince our engineering and product counterparts to care about design fit and finish? I’ve struggled with this issue many times. Here’s what I’ve learned.

It’s not design for design’s sake

Designers notice the gap between functional and delightful, and that’s why we obsess over the little details. (littlebigdetails.com) But there’s a very real tradeoff between perfecting the design details and building more functionality: getting the details right often means moving slower.

So it’s not enough to say “it looks better this way”. Designers need to make a case for why the team should spend time on fit and finish.

Trust increases when we get the details right

Customers judge online credibility by evaluating visual design, copywriting, and interactions. If trust matters to your business, then design details should matter too. Check out the academic literature on the topic of interface design and trust, or look into Stanford’s Web Crediblity Project.

MintSquare, and Simple have all done a fantastic job of getting design details right, and earning customer trust. They all began as unproven products, yet customers trusted them to store financial details, process payments, and safeguard accounts.

Usability improves when we get the details right

The MailChimp logo makes me smile every time! The lack of clutter on the Google homepage is so peaceful. The glossy pixel-perfection of Apple interfaces is delightful. They got the design details right, and it’s creating a positive emotional state, but why does that matter?

There’s a curious brain hack at work here. Our minds are deeply tied to emotional states. Being frustrated or happy changes the way we approach problems. I have certainly been in a bad mood, gotten confused by a product, and found myself repeatedly smashing a button to no effect. In my frustration, I try the same thing, justharder. But it doesn’t help me accomplish my goal.

When we’re happy, using an interface feels like play. The world looks like a puzzle, not a battle. So when we get confused, we’re more likely to explore and find other paths to success. There’s a whole book on this topic: Emotional Design by Don Norman. But here’s the important bit: Getting design details right can create positive emotional states that actually make products easier to use.

Batch up the work

If your product needs a massive helping of fit and finish, fixing one issue won’t do much to delight you or your users. Filling one pothole won’t turn a bumpy street into a smooth one — you’ll barely notice the change!

So here’s the trick: Batch up UI bugs into one sprint. If your team regularly holds a fix-it day to squash bugs, then piggyback on that habit and hold a design fix-it day. As a designer, you can do advance work like putting all the changes into a spreadsheet or bug tracker and prioritizing issues.

On the day of the sprint, everyone can just focus and crank through the list. Maybe you don’t fix everything — that’s OK. The small changes you do make will add up, and by the end of the day your product will be noticeably better. That makes everyone feel great and it’ll be easier to get people focused on fit and finish issues in the future.

Polish as you go

I really screwed up the first time I tried to keep quality high as we were building features. It always started fine: an engineer and I would agree to a design, I’d send him a few mockups, and the next day he’d show me the progress. What I saw: a sloppy version of my design. Ugh.

I’d moan and complain and point out all the mistakes, which wasn’t any fun. So the next time he was less likely to ask for my feedback, quality slipped further, and I became more upset. Classic death spiral.

I came to realize that when a feature is 90% done from an engineering perspective, it can still feel about 10% done to a designer. Now I get excited about the functionality and celebrate that there’s only a bit of surface details to finish before the feature is perfect.

I also try to build in triggers for feedback sessions while engineers are in context. I’ll say, “Grab me right before you check this in.” That way we can go over any small changes while all the files are open and checked out.

Avoid customization icebergs

Designing a custom button in Photoshop is easy — that’s the part of the iceberg we can all see. Below the surface it takes a lot of effort to get the details right: building pressed and inactive states, preventing text highlighting on double-click, adding right-to-left support, testing accessibility, and so on.

I often hit this iceberg when I stray from native controls. For example, Ajax interactions require more polish than basic web pages. Custom mobile menus require more polish than the built-in version. If the team doesn’t have the time to polish custom UI, it’s often better to stick to the boring native controls that work.

Those are some of the techniques that I’ve learned over the years to get design details built. And I’ve noticed along the way that teams vary widely in their culture around quality. Some teams obsess over the details and take their time. Other teams tend to launch sloppy products fast.

I’m interested in how teams create norms for quality. How do you create a culture where a team can quickly come to agreement about whether to spend more time on design details? What has worked for you? What hasn’t? Let’s discuss in the comments below.


Resource: Good Kickoff Meetings


Resources from my SXSW 2011 presentation, Your Meetings Suck and It’s Your Fault.

These resources are identical if you attended my workshop at UX London, UX Week, or UI16.

If you work at a design agency, government agency, university, for-profit, not for-profit, or even a wish-I-had-profit, you break your work down into projects. Every project has to start somewhere. Traditionally we call those first meetings “kickoff meetings.”

The metaphor of a football kickoff for a meeting implies a time in the project where the game is just beginning, but that implied simplicity is deceptive. The reality of a kickoff in football is that a lot of analysis and preparation happened off of the field before the ball is kicked. Unfortunately that amount of thought and effort doesn’t traditionally go into project kickoffs.

I decided to undertake a different approach to kickoff meetings, applying design thinking, constraints, and interactive exercises to develop a kickoff framework that was more similar to a playbook of activities I could pull from to begin to define and begin to solve problems for clients. I am in the business of creating experiences for the web, and although these exercises are designed to support that type of process, you might find them useful in putting together kickoffs for other kinds of projects as well.

Whether you get one useful idea from this site, or it helps you plan a multi-day, 60 plus person kickoff meeting, I hope you find this site helpful in building trust, energy, and positive culture around a successful project beginning.

Two that stuck out to me:

Design Studio/Prototyping Exercise

The 20 Second “Gut” Test

A responsive process. Brad Frost for TechCrunch

TechCrunch responsive design

I got shot out of a cannon at the beginning of 2013. I had been contemplatinggoing out on my own for a while, so I decided to reach out to the great Josh Clark for career advice. In addition to providing me a ton of great advice, he asked if I’d be interested in working on a potential project that was in the midst of coming together. Of course my answer was yes, and for the next few months began working on a redesign of TechCrunch.

The Team

I had the honor of working alongside some of the smartest and nicest people I’ve ever met on this project (and thankfully most of us ended up working onEntertainment Weekly right afterwards). Here was our crew:

  • Josh Clark steered the ship. He got the team together, led the design process, constantly managed the client relationship, and gave off positive vibes that carried us through a lot of long nights.
  • Jennifer Brook is an absolute beast. Never before have I seen someone conquer content and information architecture so adeptly.
  • Dan Mall led visual design on the project. Dan constantly amazed me at how thoughtful, utilitarian, and gorgeous his designs were. It was an honor to work with him.
  • Jonathan Stark slung some serious JavaScript. It was my first time working with a bonafide JS expert, so I did my best to learn all I could from him. He also helped me with my abysmal Git/Github skills, and for that I’m eternally thankful.
  • Kristina Frantz brought to the table some serious project management chops, which were essential in managing our entirely remote team.
  • And as for me, I coded the HTML and CSS for the site. As it turns out, there was a lot to create, so thankfully Pon Kattera and Greg Sarault stepped in and helped me prototype a ton of stuff. I most certainly couldn’t have done it without them!

We all worked remotely, and since the majority of the team were also frequent speakers we found ourselves collaborating on this project while criss-crossing the globe. Our calls would start with “Greetings from Stockholm!” “Greetings from Chicago!” “Greetings from Sydney!” It was pretty wild, but hey, we got the job done.

The Process

Our merry group of makers had the opportunity to revisit what the modern Web design process looks like, and this post is going to step through how we did things.

Set expectations

A lot of the failure to move into the Post-PSD Era has been a problem ofsetting the right expectations with clients and colleagues at the beginning of the project.

We did our best to help the client understand the reality of the Web landscape, and that because our website was going to be fluid, our process needed to match.

200+ Laptops, tablets, and mobile phones

We helped everyone understand that development is an essential part of the design process. A few months before starting the TechCrunch project, I was deep in my thoughts working out what would ultimately become atomic design. I had even begun work on a tool that would allow me to establish a robust pattern library and stitch together interface patterns to form pages. That tool would eventually evolve into Pattern Lab. I introduced everyone to atomic design and demoed Pattern Lab for them. We talked about the benefits of creating a robust design system versus an ad hoc collection of page templates. Everyone seemed to get it without any wailing or gnashing of teeth.

Kickoff and Planning

We kicked the project off at TechCrunch’s office, where we conducted stakeholder interviews, did a 20-second gut test, and design studio exercises to get everybody aligned. You can read more about the exercises because we repeated these effective exercises for Entertainment Weekly, and I used them for my current redesign of the Pittsburgh Food Bank website.


Armed with insights from the kickoff meeting, we retreated back to New York to comb through the site, establish content types, talk information architecture and brainstorm interaction design together. After that Jennifer rolled up her sleeves and got to work organizing the mountains of Post-its and sketches the group had generated.

establishing site-wide patterns

Jennifer did a hell of a job setting up some global patterns for the sites, establishing what she referred to as “rivers” and “islands”. Rivers are lists of objects like news stories, while islands were featured content areas.tc-wire1



The great thing about establishing these site-wide patterns was that I was able to immediately represent these patterns as organisms in Pattern Lab. Because of the blocky, gray-scale nature of Jennifer’s sketches, I was able to quickly recreate all the sketches in HTML using a simple .fpo class. Once established, creating and modifying wireframes was as easy as copying and pasting an include.

In addition to translating Jennifer’s sketches into FPO blocks in Pattern Lab, I was able to get to work right away on a whole slew of molecules and organisms. Just by looking at TechCrunch’s existing site I knew I could roll up my sleeves and start marking up a whole host of things: text elements (bold, emphasis, blockquote, pullquote, etc), image types (logo, post image, avatar, etc), forms (search, newsletter, submit a story, contact, etc), ads, and a whole lot more.

Different FPO ad unit sizes

We knew that ads throw in a monkey wrench into a responsive sites, so I created FPO ad unit atoms and chucked all the ad requirements into the HTML wireframes right out of the gate.

establishing visual direction

While Jennifer was working on information architecture and I was setting up molecules and organisms in Pattern Lab, Dan was hard at work establishing visual direction.

Because TechCrunch is a destination for people to read, Dan thought a logical place to start exploring would be type. So using Typecast, he created some type combinations to facilitate conversation with the client.

TechCrunch type explorations in Typecast

The client was able to comment on type (“That’s too blocky” or “Number 3 is a little too thin”) by looking at real type displayed in the browser, the same place where their users will ultimately be experiencing the site.

Rolling Up Our Sleeves

Once we had a solid sense of information architecture, visual direction, and HTML scaffolding, we were able to really get into the weeds to start designing things.

html wireframes

Jennifer blocked out all of the different page templates, accounting for variants of a template (such as how the homepage looks during a live event versus a normal news day).



And I was right there behind her creating each page template, which consisted of the appropriate molecules and organisms. Slowly but surely, I started replacing those FPO divs with marked-up molecules and organisms.

TechCrunch HTML wireframe

Now, these HTML wireframes looked absolutely hideous. But that’s alright because at this stage in the game I was just getting everything wired up. Layout, color, and other visual design-related stuff would come later.

element collages

Armed with insights from type and branding explorations, Dan went to work creating element collages of the interface. Element collages are a bit more tangible than a style tile, but still not a full-on comp. Here’s one that demonstrated how things might adapt across multiple screen sizes:

TechCrunch Element Collage

The great thing about this is that he didn’t have to worry about what the footer or featured post area was going to look like in order to get the client’s feedback. By honing in on one organism rather than a whole page, the client was able to focus on getting the header right rather than getting distracted by what FPO image Dan might have decided to use on a homepage comp. Element collages allowed us to have the right conversations at the right time.

Once the client was comfortable with the header direction, I would take that direction and start styling it up. I started with the global header and footer:

HTML wireframe purgatory

Now this is where things start getting weird, because what began their lives as HTML wireframes were slowly transforming into the final designs. I thought this would be awkward from a client relations standpoint (we certainly had a lot of internal conversations about how to address this), but ultimately because they were involved in the process the entire way they understood what was going on. Because they had a better perspective on where the design was coming from, we were able to get feedback on certain components despite the fact that the rest of the site guts still looked like grayscale throw-up.


Believe it or not, we did indeed create a few full comps. Gasp! Horror!

But the difference between this and all the other projects I’ve ever worked on is that we didn’t lead with the comps. By the time Dan made some comps (for the homepage and featured article page), we had established many of our key molecules and organisms, and had an understanding of the systematic nature of our design.

We presented the comps to the client, and they’d come back with some (usually) minor change requests. I’d then take the comps and their feedback and make the requested changes in the browser, so that we weren’t dwelling in Photoshop any more than we had to. Dan and I would Skype and chat through the issues to ensure the initial vision remained intact.

behind the scenes photoshop

And so it went. We’d create visual styles for particular organisms, and design full comps if absolutely necessary. I would style each organism appropriately, and slowly but surely replace the remaining grayscale blocks with detailed styles.

Sometimes things just weren’t looking right in the browser. Maybe a few components didn’t not look quite right sitting next to each other. In these instances, I’d bring them to Dan’s attention, who would screenshot the working code and shift things around to solve the design problem. We’d talk about it and I’d get back to work implementing his suggestion.

After a while, we realized that a whole lot of the Photoshop documents being created weren’t ever intended for the client to see. Instead, these little Photoshop hotfixes were created to help me style things better in the browser. Strange days indeed.

The Final Push

We worked hard styling each of the templates, and addressing every variation in a template. What does an article look like when there’s zero comments? What about when there’s 60? What does a topic page look like for a product versus a company versus a person? What does an event page look like before, during, and after an event? We created a new page for each template variation. Here’s what the final page list looked like in the Pattern Lab menu:

TechCrunch pages list

That’s a lot of pages.

Once the templates were complete, we cross-browser, cross-device tested everything (we had been testing on different browsers and devices throughout, but only on a subset during core development). From the design end of things, Dan went through and created an incredibly detailed list of minor design tweaks that tightened things up and got things ready for final delivery to be implemented into their WordPress backend by the fine folks at10up (who by the way were involved throughout the course of this process). What was great is that we weren’t just handing over a bunch of templates, but rather an intentional, robust design system that can be built upon and evolved.

After some time the site went live. It was a long few months, but I think our hard work paid off.

Lessons Learned

So that’s that. Here’s some things I took away from the project:

  • It’s not Agile–So we didn’t do the traditional waterfall approach. So we must have been Agile right? I don’t really think so. I think there’s a false dichotomy between waterfall and Agile, but at the end of the day I don’t know what I’d call our process. All I know is that we communicated a lot, collaborated like I’ve never collaborated before (keep in mind that we were all remote throughout the entire process), and we were honest with ourselves and the client.
  • Work in parallel–There’s so much work that can be done in parallel.


    From day one, information architects and content strategists can begin organizing information, visual designers can start exploring type, color, and texture, and developers can set up tools, patterns, and components. As some point in the process, a discipline might serve more as consultant for the other disciplines, while other times they’re burning hot creating things. As time goes on, the creating/consulting role shifts, but no one is ever fully out of the picture.

  • Slowly build fidelity–This process reminds me a lot of subtractive sculpture.

    Stone Sculpture

    You start out with a big slab of rock, and slowly chip away to get the rough shape of the form you’re creating. You take another pass at it to get a better sense of the object you’re trying to extract from the stone. You take another pass to start getting a bit more detailed. Eventually, you start honing in on a particular aspect of the form: a face, the arms, or the torso. Slowly but surely you detail each section of the sculpture until you’ve arrived at the final form.

    Only unlike stone sculpture, we have Cmd+Z.

There’s a lot more to be said about this project, and hopefully I’ll get the opportunity to explore them further. In the meantime, check out the site, and look out for more posts from the rest of the team.

Using Content To Define User Experience

In her presentation at Breaking Development in Nashville TN, Steph Hay talked about the importance of narrative in digital experiences. Here’s my notes from her talk on Using Content To Define User Experience.

  • The Sesame Street TV show was based on actual research of how kids learned and continually measured to make sure it was reaching their educational goals. They approached content development by isolating chunks of programming, testing it, and continually refining.
  • The big paradigm shift was learning first then writing second.
  • Content and technology that guides people over time forms a narrative that allows people to act.
  • Use cases in software design tend to be very flow-focused and high level. Requirements docs just focus on the what. Content is the missing piece in everything we’re doing.
  • When content really works, we can get from point A to B more quickly and easily.
  • Use content to explicitly set expectations then meet them regardless of device.
  • Design is only part of the narrative, the other half is the real human people that experience what we are designing.
  • The “you” orientation of content focuses on the user, not on the company. It positions the customer as the other half of the narrative.
  • Features by themselves won’t protect your narrative, you also need relevance.
  • There are two kinds of narratives online: setting expectations (through marketing), and functional requirements (through experience).
  • Write content first. This is the paradigm shift.
  • Many organizations are afraid to write content first because they are used to writing it last. But this results in missing pieces and incomplete experiences.
  • State your goal: what are you trying to accomplish, what are your users trying to accomplish.
  • You can use tools like Google Keyword builder and Google Analytics to find the language people are using to find you. What terms make sense for them? Use these terms to create a conversation.
  • The content is the structure. This is why it makes sense to start there.


Relying Too Much on Screen Size

As people continue to go online using an ever increasing diversity of devices, responsive Web design has helped teams build amazing sites and apps that adapt their designs to smartphones, desktops, and everything in between. But many of these solutions are relying too much on a single factor to make important design decisions: screen size.

What’s Wrong With Screen Size?

It’s not that adapting an interface to different screen sizes is a bad thing. Quite the opposite. It’s so important that key metrics like conversion and engagement usuallyincrease substantially when Web sites adjust themselves to fit comfortably within available screen space. For proof, just look at how mobile conversion rates increase significantly more in responsive redesigns than PC conversions do.

So if adapting to different screen sizes can have that kind of positive impact for a business, what’s the risk? As the kinds of devices people use to get online continue to diversify, relying on screen size alone paints an increasingly incomplete picture of how a Web experience could/should adapt to meet people’s needs. Screen size can also lead to bad decision-making when used as a proxy for determining:

  • If a browser is running on a mobile device or not
  • If Network connections are good (fast) or bad (slow)
  • If a device supports touch, call-making, or other capabilities

None of these can actually be accurately inferred from screen size alone but they are comfortable assumptions that make managing device diversity substantially easier. The harsh truth however, is that output (screen size and resolution) is only one third of the equation -at best. Equally important to determining how to adapt an interface are input capabilities and user posture, which sadly screen size doesn’t tell us anything about.

Let me illustrate with a few specific examples.

Screen Size Limits

On tablets, PCS, and TVs, Microsoft’s Windows 8 platform allows any app, including the Web browser, to be “snapped” to the side of a screen thereby letting people interact with it while using another application in the primary view. As an example, the Windows 8 calendar application can be snapped alongside the weather app when making your daily plans.

Windows 8 Snap Mode

Notice though, that the default view of the calendar application on Windows Phone 8 is quite different than the snapped view of the same app on a tablet, PC, or TV. They are both using the same amount of screen width (in relative pixels), but the mobile interface starts with a daily agenda instead of a small month view by default. The controls are also adjusted to the mobile form factor as you can see in the image below.

Windows Phone Weather App

We can debate about why these differences exist and if they should or not but the bottom line is there’s more than screen size being taken into account in these application designs.

This simple example illustrates the challenge for Web designers. On Windows Phone devices, Internet Explorer uses 320 pixels for its device-width (the width it renders content at). On Windows 8 tablets, PCs, and TVs, snap mode uses the same 320 pixel device-width to lay out Web pages docked alongside other apps.

So with a responsive Web design, people get the same interface on a smartphone that they get in snap mode on a TV screen due to the same device-width (320 pixels). You can see this illustrated in the image below.

Polar on XBox One And Smartphone

But should the interface be the same? A TV is usually viewed from about 10 feet away, while the average smartphone viewing distance is about 12 inches. This has an obvious impact on legibility for things like font and image sizes but it also affects other design elements like contrast. So a user’s posture (in this case viewing distance) should be taken into account when designing for different devices.

The input capabilities of a TV (D-pad) can differ wildly from a those of a mobile device (touch) or in some cases be the same (voice). Designing a simple list interface for d-pads requires a different approach than a creating a similar listing for use with touch gestures. So available input types should also be considered in a multi-device design.

When you take user posture and input capabilities into account when designing, an interface can change in big or small ways. For instance, contrast the design below for Windows 8 snap mode on a TV compared to a mobile version of the same feature.

Polar Adapted to TV and Smartphone

While the screen size (320 pixel device-width) has stayed consistent, the interface has not. Larger fonts, a simplified list view, inverted colors, and a lot more have changed in order to support a different user posture (10 ft away vs. 12 inches), and different input types (d-pad vs. touch). As you can see, screen size doesn’t give us a complete picture of what we need to know to design an appropriate interface.

Before you dismiss this as an isolated use case on Windows 8 devices, note that Android smartphones and tablets also offer the ability to interact with multiple applications side by side and Android-powered TVs won’t be far behind. In fact, we’ve already got Android eyepieces like Google Glass that pose similar challenges.

Google Glass allows you to view applications and Web pages using a display that projects information just above your line of sight. The official specs describe the Glass display as a “25 inch HD screen viewed from 8 feet away.” So right up front, viewing distance matters.

Google Glass Screen Specs

Like most mobile Web browsers, Glass uses a dynamic viewport to resize Web pages for its screen. On Glass the default viewport size is set to 960 pixels and pages are scaled down accordingly. So if someone is viewing the Yahoo! Finance site, it displays like this in the Glass browser (below). Essentially, it is shrunk down to fit.


Yahoo! Finance on Google Glass

The Web browser on Glass also allows pages built responsively to adapt to a more suitable device-width. In this case, 640 pixels. So a Web page designed to work across a wide range of screen sizes would render differently on Glass. Given that 600 pixels is a common device-width for 7 inch tablets, the page you’d see on Glass would look more like the following -adapted for a smaller viewport size.

Yahoo! Mobile on Google Glass

In addition to the Web browser, Google Glass also includes a number of “glassware” applications built with the same Web technologies used to create Web pages. One of these apps provides access to stock price changes -very similar to what you see displayed prominently on the Yahoo! Finance site. However, the presentation of this information is very different. As you can see in the image below it’s been designed as if you are viewing a 25” screen from 8 feet away. This design is much more suited to a wall-sized display than a small tablet screen.

Google Glassware for Finance

This Glassware interface is also designed to make scrolling through information using the touchpad on the side of Google Glass (which comfortably supports sweeping left/right and up/down gestures) fast and easy.

So again user posture and input capabilities inform how to design for a specific device. Screen size alone doesn’t tell us enough.

Supporting Everything

In order for an interface to adapt appropriately to different output, input, and user posture, we need to know what combination of the three we’re are dealing with at any given time. On the Web that’s been notoriously difficult. We can’t tell TVs from smartphones or what devices support touch without relying on some level of user agent detection, which is often looked at dubiously.

Because of this, Web developers and designers have smartly decided to simply embrace all forms of input: touch, mouse, and keyboard for starters. While this approach certainly acknowledges the uncertainty of the Web, I wonder how sustainable it is when voice, 3D gestures, biometrics, device motion, and more are factored in. Can we really support all available input types in a single Web interface?

A similar approach to user posture is increasingly common. That is, an interface can simply ask people if they want a lean-back 10 foot experience, a data dense 2 foot experience, or something more suited for small portable screens. This makes user posture something that is declared by people rather than inferred by device. Once again, this kind of “support everything” thinking embraces the diversity of the Web whole-heartedly. However it puts the burden on each and every user to understand different modes, when they are appropriate, and change things accordingly. (Personally I feel we should be able to provide an optimal experience without requiring people to work for it.)

Ultimately trying to cover all input types and all user postures in a single interface is a daunting challenge. It’s hard enough to cover all the screen sizes and resolutions out there. Couple that with the fact that an interface that tries to be all things to all devices might ultimately not do a good job for any situation. So while I embrace supporting the diversity of the Web as much as possible, I worry there’s a limit to the practicality of this approach long-term as the amount of possible inputs, outputs, and user postures continues to grow.

Don’t Assume Too Much

These examples are intended to convey one important point: don’t assume screen adaptation is a complete answer for multi-device Web design. Responsive Web design has given us a powerful toolset for managing a critical part of the multi-device world. But assuming too much based on screen size can ultimately paint you into a corner.

It’s not that adapting to screen size doesn’t matter, as I pointed out numerous times, it really does. But if you put too much stock in screen size or don’t consider other factors, you may end up with incomplete or frankly inappropriate solutions. How people interact with the Web across screens continues to evolve rapidly and our multi-device design methods need to be robust enough to evolve alongside.

Adobe Explores the Future of Responsive Digital Layout with National Geographic Content

Update (5/21/13): To see the mobile prototype, check out Creating an Installed Application Experience on Mobile With Web Technologies.

National Geographic partnered with Adobe, sharing select content for Adobe’s use to experiment with digital layout. The results mark the beginning of a technical and design collaboration that will look at innovating around layout while responding to some of the real world needs of National Geographic’s designers. By combining a National Geographic feature entitled “Forest Giant” with some of Adobe’s contributions to web standards, Adobe has created a forward-looking vision of how readers will consume web content in the very near future.


Because some of the features the demo uses are still experimental, the article needs to be viewed in Chrome Canary with two runtime flags enabled.

Learn how to enable flags in Canary to view CSS Regions, CSS Exclusions and CSS Custom Filters.

To learn more about enabling runtime flags, see this tutorial.

Once you have Chrome Canary installed and properly configured, go check out the demo. (Note that the entire project is open source and available on GitHub.) Of course, if you’re in a hurry, you can always just watch the video above to get a feel for the experience.

Editor’s Marks

Some of the advantages of modern layout capabilities can be subtle, so we created an “editor’s overlay” mode which highlights the more noteworthy features and explains how they were implemented. To enable editor’s marks, click on the bar at the bottom of the article (or just press the tilde key).


In order to have better control over the flow of the article, we used CSS regions. At its core, regions allows you to separate your content from where and how it gets displayed. Specifically, it allows you to designate which part of your DOM is your content, and which elements your content should flow through. The flow of the content happens automatically, adjusting for things like font size changes, resizing, zooming, etc.

In the “Forest Giant” demo, we use regions to make the content flow throughout the page in interesting ways, even creating shallow columns in one instance. Without regions, the designer would have had to break the content up manually, and would have to make major adjustments to the entire page if the content ever changed. With regions, the content is automatically broken up across various elements as the source text flows through the specified region chain.

Regions are also an excellent tool for responsive design. When you change the size and/or position of your regions in response to changes in screen size, your content automatically reflows through your region chain.

Learn more about CSS Regions.


CSS Exclusions allow text to flow along either the inside or the outside of a shape. Take a look at the drop cap at the beginning of the article. Without exclusions, the text to the right of the “O” would be vertically aligned, creating uneven spacing. By using exclusions — and specifically shape-outside — the text is able to follow the contour of the initial letter creating a much cleaner and far more polished visual effect.

Another example of exclusions is the text at the bottom of the article. Notice how the paragraph follows the shape of the map. This type of high-end layout was not formerly possible with HTML content. Without exclusions, the best way to do this on the web would probably be through the use of images, however you then lose the ability for your text to be resized, indexed, searched, copied, and easily updated.

Learn more about CSS Exclusions.

Balanced Text

The concept of balanced text is fairly subtle, but once you’re aware of it, you’ll find that it makes a huge difference in the way your content is laid out. By default, browsers wrap text one word at a time which means you can easily end up with lines containing only one or two words while the line above it might stretch the entire length of your container. Although this is something we’re pretty accustomed to seeing on the web, it’s not a layout that would ever be permitted in print. When designers have full control over how lines of text are broken up, they will balance the text such that every line is approximately the same length.

We’re using a balanced text polyfill for both the subtitle of the article, and the pull quote between the second and third paragraphs. To see how it works, try resizing your browser horizontally. If you have a wide enough monitor, you should see the entire pull quote on one line. As you decrease the width of your window, you will see that the text always wraps in such a way as to keep the lines close to the same width.

Learn more about Balanced Text.

Custom Filters

Most of us are accustomed to applying filters to images in applications like Photoshop and Instagram. And if you’ve used SVG on the web extensively, you’ve probably also experimented with SVG filters. Now you can apply the same visual effects to any HTML elements using CSS Filters.

The advantages of filters are:

  • They can be applied dynamically which means you don’t have to preprocess your assets.
  • You can apply them to any HTML element (not just images).
  • They can be animated with CSS Animations.

We’re using a custom filter at the bottom of the article to allow users to “peel back” the bottom of the page and expose an interactive infographic (click on the “Explore the President Tree” text to see the filter in action). The effect is a subtle but fun way to create a sense of depth in the content, and is achieved entirely through CSS.

Learn more about CSS Custom Filters.


Because the “Forest Giant” article is about the second largest tree in the world (but probably the biggest in terms of mass), we wanted to convey a sense of size. If you click on the “Click Here to Pan & Zoom” link below the thumbnail of the giant sequoia, you’ll see a huge image of the tree assembled tile-by-tile until you reach the top. Try scrolling around the image and note how small the three scientists appear in relation to the tree they are studying.

This effect is accomplished with WebGL (through a library called three.js). Although WebGL is not a specification or implementation that Adobe is contributing to directly, we’re a big fan, and it was the perfect technology for building a smooth 3D animation.

Learn more about WebGL.


Advances in technology have proven many times that convenience often trumps fidelity. For example, MP3s became popular — even at their initial low bitrates — because it was more important for us to have all of our music available wherever we were than it was to have the best possible audio quality. Similarly, digital books, magazines, and newspapers are replacing their analog counterparts at an increasing rate because convenient and instant access to content frequently supersedes aesthetics.

Now that the internet has helped to make content ubiquitous, we’re starting to see a shift back toward production value. Users want HD video, beautiful and fluid user interfaces, and they increasingly expect content to be presented in interesting and compelling ways. With features like regions, exclusions, balanced text, custom filers, and WebGL, content producers will no longer have to choose between reach and design. Working with National Geographic’s stunning visual content, Adobe has proven that the web of tomorrow will enable both.


Infinite Scrolling: Let’s Get To The Bottom Of This

Infinite scrolling promises a better experience for users. However, the good is often accompanied by the bad and the ugly. Once weunderstand the strengths and weaknesses of infinite scrolling, we can begin to use it to enhance our interfaces.

Human nature demands hierarchy and structures that are easy to navigate. But infinite scrolling sometimes leaves users feeling disoriented as they travel down a page that never ends.

The NeverEnding Scroll

The Good

Long lists are not new, but the way in which we scroll these lists has fundamentally changed since the arrival of mobile interfaces. Due to the narrowness of mobile screens, list items are arranged vertically, requiring frequent scrolling.

Infinite scrolling is highly trending as an interaction behavior on pages and lists. The basic functionality is that, as the user scrolls through content, more content is loaded automatically. With the popularity of social media, massive amounts of data are being consumed; infinite scrolling offers an efficient way to browse that ocean of information, without having to wait for pages to preload. Rather, the user enjoys a truly responsive experience, whatever device they’re using.

Pagination vs. Infinite Scroll
Pagination versus infinite scrolling (Large version)

Websites with lots of user-generated content today are using infinite scrolling to handle content that is being generated every second. By unspoken agreement, users are aware that they won’t get to see everything on these websites, because the content is updated too frequently. With infinite scrolling, social websites are doing their best to expose as much information as possible to the user.

Twitter integrates infinite scrolling effectively. Its feed fits the criteria: a large amount of data (tweets) and a real-time platform. From the perspective of the user, all tweets are equally relevant, meaning that they have the same potential to be interesting or uninteresting; so, users will often scroll through all of the tweets in their feed. Being a real-time platform, Twitter is constantly being updated, even if the user leaves their feed unattended. Infinite scrolling seems to have been created especially for websites like Twitter, which successfully employs the technology.

Infinite scrolling appears to have found its niche on the Web. However, there are also drawbacks that must be considered before assessing its value.

The Bad And The Ugly

With so much data to browse, users must stay focused on the information they are searching for. (Remember about being goal-oriented?) Do users always want a never-ending stream of data? Analytics show that when users search for information on Google, only 6% advance to the second page. So, 94% of users are satisfied with receiving only 10 results, which suggests that users find Google’s ranking of results to be relevant.


Google has implemented infinite scrolling for image search results but has yet to implement it for its general results. Doing so would eliminate the need for users to click to reach the second page. Google will probably maintain pagination because this pattern is quite symbolic for its brand. If it does switch to infinite scrolling, when would users typically stop scrolling? After 20 results? 50? When does an easy browsing experience become more complicated?

Looking for the best search result could take a second or an hour, depending on your research. But when you decide to stop searching in Google’s current format, you know the exact number of search results. You can make an informed decision about where to stop or how many results to peruse because you know where the end is. According to studies conducted in the field of human-computer interaction,reaching an end point provides a sense of control; you know that you have received all relevant results, and you know whether the one you are looking for is there or not. Knowing the number of results available provides a sense of control and helps the user make a more informed decision, rather than be left to scour an infinitely scrolling list.

Pagination: The Click Barrier
Pagination is a barrier of clicks. (Large version)

When items are distributed across Web pages, they are framed and indexed and have a start and end point. The information is presented clearly and orderly. If we select an item from a paginated list and are taken from that page, we know that clicking “Back” will return us to that page (probably to the same scroll position). Our Web search will continue right where it left off.

If you scroll the same list of results with infinite scrolling, you are left without that sense of control because you are scrolling through a list that is conceptually infinite. Let’s say you count yourself among the 94% who stop reading after the first page (i.e. 10 results) of a Google search. When the list scrolls infinitely, there is essentially no end to the first page. Rather than look for the end of the page, which doesn’t exist anyway, you decide to stop scrolling at the 10th item. This poses a problem with infinite scrolling, because the 11th item is directly in sight. With a paginated list, on which you wouldn’t see the 11th result, deciding not to continue browsing is easier. However, when the next results are already there,you’d probably just keep on scrolling and scrolling.

As Dmitry Fadeyev points out:

“People will want to go back to the list of search results to check out the items they’ve just seen, comparing them to what else they’ve discovered somewhere else down the list. Having a paginated interface lets the user keep a mental location of the item. They may not necessarily know the exact page number, but they will remember roughly what it was, and the paginated links will let them get there easier.

Not only does the infinite scroll break this dynamic, it also makes it difficult to move up and down the list, especially when you return to the page at another time and find yourself back at the top, being forced to scroll down the list once again and wait for the results to load. In this way the infinite scroll interface is actually slower than the paginated one.”

— Dmitry Fadeyev, When Infinite Scroll Doesn’t Work

When Infinite Scrolling Fails

The best companies are constantly testing and studying new interactions with their users. Increasing numbers of these studies are showing that infinite scrollingdoes not resonate with users if it does not support their goal on the website.


When you’re looking for that perfect search result and are tempted to continue scrolling into a wasteland of irrelevant results, time is wasted. Chances are that the best result will appear in the first 10 items. Therefore, infinite scrolling merelytempts you to continue reading, wasting time and decreasing productivity in the process.


Even more annoying is that scroll bars do not reflect the actual amount of data available. You’ll scroll down happily assuming you are close to the bottom, which by itself tempts you to scroll that little bit more, only to find that the results have just doubled by the time you get there.


Infinite scrolling overwhelms users with stimuli. Like playing a game that you can never win, no matter how far you scroll, you feel like you’ll never get to the end. The combination of temptation and optimism play a big role in exhausting the user.


Infinite scrolling often causes your position on the page to get lost. “Pogosticking” happens when you click away from an infinitely scrolling list and, when you return by clicking “Back,” are brought to the top of the previous page, instead of to the point where you left off. This happens because the scroll position is lost when you navigate away from an infinitely scrolling page, forcing you to scroll back down each time.


Infinite scrolling leaves you with the feeling that you might be missing out on information. You continue scrolling because the results are right there, but you feel overwhelmed because you’re losing control over the amount of data being shown. There is something nice about defined pages on which the amount of content is quantified, where you can comfortably choose whether to click to view more or to stop. With infinite scrolling, you don’t have control over the amount of data on the page, which becomes overwhelming.


Etsy, an e-commerce marketplace, implemented infinite scrolling, only to find that it led to fewer clicks from its users. Infinite scrolling was unsuccessful because users felt lost in the data and had difficulty sorting between relevant and irrelevant information. While infinite scrolling provided faster and more results, users wereless willing to click on them, defeating its very purpose.

Etsy's Home Page
Etsy’s home page (Large version)


Have you tried reaching the footer of Facebook lately? The footer block exists below the news feed, but because the feed scrolls infinitely, more data gets loaded as soon as you reach the bottom, pushing the footer out of view every time. Footers exist for a reason: they contain content that the user sometimes needs. In Facebook’s case, the user can’t reach it. The links are repeated elsewhere but are harder to find. Infinite scrolling impedes the user by making important information inaccessible.

Facebook auto-loading News Feed and the unreachable footer
Facebook’s auto-loading news feed makes the footer unreachable. (Large version)

Footers serve as a last resort. If users can’t find something or they have questions or want more information or explanation, they often go there. If they don’t find it there, they might leave the website altogether. Companies that implement infinite scrolling should either make the footer accessible by making it sticky or relocate the links to a sidebar.


Pinterest does not have a footer at all, which makes sense given the problem we just saw with Facebook. Through infinite scrolling, Pinterest emphasizes its profusion of data, an endless sea of inspiration taken from all over the Web.

Pinterest Ocean of Pins
Pinterest’s ocean of pins (Large version)

Images are faster and easier to scroll than text, so Pinterest and Google Images succeed with infinite scrolling to an extent. However, billions of images are on the Web, and users would prefer to see only the best of them. There is something to be said for exclusivity, which seems to be lacking in Pinterest’s layout.

Limiting the number of images on Pinterest’s home page, with an “Editor’s picks” or “Most popular” list, might make the website more appealing. How exclusive can a pin be when a ton of other similar pins are next to it?

Pinterest’s tactic of using infinite scrolling for its plethora of data suffers because itoverwhelms users. The collection looks bottomless, but its immensity is somewhat daunting, and browsing it might seem a waste of time. Ultimately, Pinterest is trying to expose users to infinite inspiration, but that actually undermines thehuman need for control. The amount of data becomes intimidating, and users are left with mixed feelings.

When Usability Wins

As mentioned earlier, Twitter integrates infinite scrolling effectively. The user sees an infinitely growing list of tweets and can comfortably click on a tweet to expand it in place, preventing the page from refreshing and, as a result, maintaining their scroll position.

Twitter's torn feed
Twitter’s torn feed (Large version)

On its mobile version, Twitter even adds a “torn paper” marker, indicating to the user where to resume reading. This subtle and simple solution enables the user to scroll up and down the list, while having a recognizable point to return to. Psychologically, that marker reassures the reader by dividing read and unread content. Such markers give the user a sense of control and a better perception of the content’s depth and how far they’ve gotten into it.

Twitter is not the only one. Discourse, an emerging discussion platform, also has infinite scrolling that empowers the user. The company considered the importance of infinite scrolling to its user experience and implemented an intriguing and unique progress indicator. The indicator appears when needed and remains in view (without interfering) while the user reads the content. The indicator numbers the item currently being viewed out of the total number of items. This is a great way to make the user feel in control, even with a lot of data.

Smart progress indicator on Discourse.com
The smart progress indicator on Discourse (Large version)


A hybrid of infinite scrolling and pagination is also a good option in many cases. With this solution, you would show a “load more” button at the end of a preloaded list, which, when clicked, loads another batch of items onto the list. The same behavior that infinite scroll does automatically, this button does on demand. The interface gains some of the advantages of infinite scrolling, without some of its drawbacks.

Because infinite scrolling requires the website to fetch so much content, the hybrid solution is used at times to control the data load. In Facebook’s news feed and Google’s image search, the infinite scrolling is automatic at first but becomes on-demand once a certain number of items have loaded. This maintains the interface while limiting the load on the server.

Hybrid Infinite Pagination on Google Images
Hybrid infinite pagination on Google Images (Large version)

Infinite Pages

Infinite pages take the concept of infinite scrolling to a new level. Websites that employ this concept are “one-pagers.” To remove the barrier of clicking to the next page, the designer turns the entire website into one long scrollable page. Examples are Unfold and Lost World’s Fairs.

On these one-page websites, the sections are spread vertically, one after another. This makes the whole website less comprehensible — hence, less accessible. These websites might not have infinite scrolling, but the user might still have that feeling of a never-ending page.

On infinite pages, the height of each section will vary according to its contents. Although the approach can make for some creative interactions, it can leave users disoriented and unsure where to scroll for the next piece of information. The scroll bar is hidden on many such pages, leaving users feeling lost as they unconsciouslylook for the scroll position to track their progress. Hidden scroll bars deprive users of that chance for rescue. Users shouldn’t be left helpless; the interface should clearly show them how to navigate the page.

Infinite Page
Not knowing where they stand can leave the users disoriented.

UX engineers need to take extra care when designing infinite pages. They must take into account accessibility; tell users where they stand by showing the length of the page and how much they’ve viewed. Solutions could include a fixed menu, a map of the page or a scroll progress bar.

Another trick is the parallax effect, whereby different layers on the page move at different speeds according to the user’s scrolling, creating the illusion of depth (as seen on Andrew McCarthy’s website). While it can help to create beautiful andinnovative experiences, it is sometimes heavily overused, and users can get confused by how much they need to scroll for more content. When the parallax effect is combined with animation, the user can get confused about whether the page is being scrolled by their movement or is moving autonomously. It’s wise to use the technique to enhance content, not as the content itself.

Let’s Get To The Bottom Of This

Infinite scrolling can be an innovative feature that greatly improves an interface by exposing content and making performance more efficient. But it needs to be used correctly.

Avoid the following sinkholes to achieve a strong infinite scrolling experience:

  • Users want immediate access to exclusive data.
    Users don’t want to be left to explore all of a website’s data on their own. When implementing infinite scrolling, identify what data is exclusive to your website and elevate it to the top of the page, and filter less relevant information.
  • Users want to feel in control.
    Infinite scrolling sabotages that feeling of control. Add a smart progress indicator, a fixed menu or a map.
  • Users often look for landmarks when scrolling.
    When scrolling through long lists, users expect to be able to easily distinguish between new and viewed data. Add landmarks along the interface to keep users oriented.
  • Consider conventional pagination or a hybrid solution.
    Good old pagination is always an alternative to infinite scrolling. And if that doesn’t fit the context, then a hybrid solution, using a “load more” button, could greatly enhance the interface.
  • Provide interesting content without an ambiguous interface.
    Having to traverse a never-ending list is logical only if the user leaves feeling that it was worthwhile.
  • Users often expect a footer.
    If footer-type information is functional to the interface, then it should appear at the bottom of the page. A fixed footer is usually the way to go with infinite scrolling.
  • An infinite list is still a list.
    Infinite scrolling still needs to meet common interface standards. Whether users take their eyes off the screen for a moment or click a link and then click “Back,” they expect to return to the exact point where they left off. Whatever your interface, make sure it meets users’ expectations.
  • Effects are nice to have but not a must.
    Many infinitely scrolling interfaces have various effects to show more data (whether by sliding in new content or another method). Be mindful not to focus more on effects than on presenting data in the most effective way possible.


Users are goal-oriented and find satisfaction in reaching the end of their exploration. To be effective, infinite scrolling has to account for this. Nothing is really infinite, not even these infinitely scrolling lists we’ve looked at. Users should always know where they stand, even when the content has not finished loading. They should know what the total amount of data is and be able to easily navigate the list. Infinite scrolling has to be implemented in the best possible way so that users can always find their way.


Sticky Menus Are Quicker To Navigate

Most designers would agree that navigation is one of the most critical components of a website. Despite this, it is not always easy to use or access. Traditionally, users must scroll back to the top of the website to access the navigation menu. I recently wondered whether sticky menus makes websites quicker to navigate, and I conducted a usability study to find the answer. Let’s look at the results of the study, a few implementation techniques and some related challenges.

Sticky Navigation Sign

Sticky Navigation Defined

Sticky, or fixed, navigation is basically a website menu that is locked into place so that it does not disappear when the user scrolls down the page; in other words, it is accessible from anywhere on the website without having to scroll. Although sticky navigation can be applied to any menu, such as the footer or social media buttons, we’ll focus on the main (or primary) navigation of a website. The image below shows the difference between standard and sticky navigation on a mobile device.

Standard Vs Sticky Navigation

Usability Study


For the study, I created two test websites that were nearly identical. The only difference was that one of them had standard navigation and the other had sticky navigation. Forty participants were timed in completing five tasks on the first website. Then they were asked to complete five different tasks on the second website. The order of the tasks was alternated between users to balance out the familiarity factor. The websites were tested on desktop machines, and participants were not told the differences between the websites until the end of their session. Data was not analyzed until the testing was completed. The results of the study yielded two interesting conclusions.


The data from the study indicated that participants were able to find what they were looking for quicker when they didn’t have to scroll back to the top of the page. 22% might not seem like a big number, but it can have a big impact on visitors. According to this data, sticky navigation could cut 36 seconds off of a five-minute visit to a website. Of course, keeping visitors on the page longer is only a benefit if you are enhancing the user experience along with it. Forcing people to dig through a website to find something does not qualify as such.


At the end of each session, users were asked whether they noticed the difference between the two user interfaces. No one was able to identify it. The changes were subtle, and none of the users caught on because they were focused on completing their tasks. Participants were then asked whether one of the websites felt easier to use. Six of the 40 participants had no preference, but of the 34 that did have a preference, 100% of them indicated that the website with the sticky navigation was easier or faster to use. Many comments along this line were made, such as “I don’t know how the websites were different, but I felt like I was spending a lot less time clicking with the first one.” Such comments indicated overwhelming favor for the sticky navigation.

Desktop Software Navigation Menus

Imagine typing a document in Microsoft Word and having to scroll up to the top of the first page every time you wanted to bold a word or widen the margins. Just the thought of that sounds frustrating. Most desktop software provides access to the entire navigation menu no matter what you are doing in the application. The Web browser is no different; we would find it ridiculous to have to scroll to the top of a website to access the address bar of a browser.

Some Good Examples

Facebook and Google+ recently adopted sticky navigation, but they are among the minority. Of the 25 most visited websites in the US, only 16% currently have sticky navigation. Below are some examples of other websites that do an excellent job of pulling this off.

Fizzy Software
This is a perfect example of horizontal sticky navigation at the very top. Everything feels comfortable while you’re using the website.

Fizzy Software Navigation

Web Appers
The navigation here is vertical and on the left, somewhat resembling Google+’s navigation. The only downside here is that if the screen’s height is shorter than 560 pixels, then the bottom portion of the menu could become inaccessible, which was the case when I tested the website on a netbook.

Web Appers Navigation

Here is another great example. Making the navigation slightly transparent, giving a hint of the content beneath it, is a nice touch.

Make Better Apps Navigation

Rodolphe Celestin
This sticky navigation spreads all the way across the top, but when you scroll down the page, the design of the menu changes slightly. Simplifying the design like this can be a good technique, as long as it doesn’t feel inconsistent. Also, the designer has taken an increasingly popular approach by making the entire website just one page; the menu links are anchors that bump you down the page. Some nice transitions and hover effects make this website enjoyable to use.

Rodolphe Celestin Navigation

Ryan Scherf
The navigation on this website is vertical and only icons. The creativity here is impressive.

Ryan Scherf Navigation

Web Designer Wall
The sticky vertical navigation works well on this website because the menu has only four items. This works well enough for blogs that I wonder why others don’t adopt this approach.

Web Designer Wall Navigation

While sticky menus aren’t the most popular form of navigation, more and more examples are popping up all the time.

Getting Started


This might seem like a straightforward way to implement sticky navigation, but avoid this method. iFrames cause more problems than they solve, particularly with cross-browser compatibility, security and search engine optimization. iFrames have their place, but they shouldn’t be a major part of your HTML layout.


CSS is a great way to implement sticky navigation. It also seems to be the most straightforward, most lightweight and quickest to code. The three things to pay attention to are positionmargin-top and z-index. Setting the menu’s position tofixed disables the element from scrolling with the rest of the page. This will likely throw off your margins if your navigation is horizontal, so you’ll want to adjust for that. Finally, use z-index with a horizontal menu to make sure the navigation sits on top of everything; this will make the other content slide underneath the navigation as you scroll. Here is the general idea:

#navigation {
   position: fixed;
   z-index: 10;

#header {
   margin-top: 50px;

You will have to play around with the CSS to make this technique work right for your website. Additional information can be found on the W3C’s website.


Smart Sticky Bar Navigation
The Simple Smart Sticky Navigation Bar is one of many good JavaScript implementations.

If you would prefer a jQuery or JavaScript solution to a CSS one, then you could try out one of the following options:

Many other solutions and scripts are out there. Please include your favorites in the comments below.

What’s The Bad News?

Give Me The Bad News

There are many opinions on this topic, and some would argue that sticky navigation isn’t worth it. Here are some things to be aware of.


Going with sticky navigation could rule out some design choices that your team might not be willing to give up. For example, the most logical place for horizontal sticky navigation would be at the very top of the page, above everything else. While easy to implement, it might not be what your users need.


If not done carefully, sticky navigation can be distracting. Some sticky elements get delayed when bouncing back into position as the user scrolls down the page. Others are so tall or wide that they dominate the layout and impede access to the content. Navigation should be easily accessible but should not compete with the content for attention.


Fixed-position CSS and certain JavaScript implementations lack support in some mobile browsers, which is a cause for concern among some developers. The article “Organizing Mobile” by Luke Wroblewski has some great principles to keep in mind when creating navigation for mobile devices. Responsive design techniques also offer some solutions for adjusting the navigation based on the size of the screen.

Be aware of the level of support offered by each device. Knowing compatibility issues beforehand will save you time in the end. When Can I Use? has some interesting information on support for position: fixed. Brad Frost has also done some of his own testing and analysis, providing some interesting insight in his accompanying video.


Why do we Web designers and developers continually force our users to scroll up and down the page in search of the navigation? This is not a problem in desktop software, and we now have the statistics to show the benefits of sticky menus. Navigation on 84% of the top 25 most visited US websites could be made quicker by implementing sticky navigation.

Of course, it’s not appropriate in every situation, especially when real estate is tight. But do seriously consider sticky navigation, while always accounting for usability and the overall user experience.



Continued Discussion:

Is a website with a Fixed Header good for end-users of a Web2.0 website?


Web Performance 2.0

In March 2012, Guy Podjarny ran a test comparing the performance of hundreds of shiny new responsive websites across four different screen resolutions. The results were very dissapointing. (1)

Two years into the rise of Responsive Web Design, after every imaginable sort of designer and developer had jumped into the train, it took a test to almost rock the theory to its foundations.

Guy proved that almost every known responsive site was overweight.

We’ve made the internet in our image… ObeseJason Grigsby

But, most importantly, every mobile user was receiving the same kilobyte overload as a desktop user.

The community had different reactions to the fact. Some claimed Responsive design wasn’t the ultimate solution, perhaps not mature enough for the challenges web designers face today.

Thankfully, the Web community can always count on a number of people who will grab the bull by the horns and turn the situation around. Modern Web gurus likeBrad FrostLuke Wroblewski or Christian Heilmann saw opportunity where others shouted crisis and managed to turn the problem to the community’s advantage.

If your website is 15MB, it’s not HTML5, it’s stupidChristian Heilmann

Web performance has traditionally been built around (no offence) developer-exclusive jargon.

Terms like GZIPing, uglifying, minifying, DNS Lookup, file-concatenation… This obscure words push designers out of the ecuation.

Smart people in the community, though, have since realized that the problem has a deeper root. It really doesn’t matter if you optimize or compress an ultra-high-res image, if your plan is to hide it from a mobile user and still make him download it.

Good performance is good designBrad Frost (2)

To achieve truly lightweight sites, performance shouldn’t only be a concern. It should be treated as a design feature.

To them, performance is like any other issue. Sites that overcome it are the ones who acknowledged it from the start. And the ones that overlook it are the ones that suffer it in the end.

Performance is about respect. Respect your users and they will come back.Brad Frost

The Why

It’s not only that you want users to have a good experience. If that was the case you could easily swap performance for a more important concern in your agenda.

Page Abandonment

Research shows 57% of users will leave your site if it takes more than 3 seconds to load. (3)

Google, page speed & SEO

Back from the spring of 2010, Google takes speed as a ranking factor. (4)

The impact is not major for average-speed sites, but if the page falls behind a certain threshold, it will be punished by the company’s search algorythm.

This proves speed not only is a concern when talking about User Experience. Be aware of loading speed if your site is to be ranked well among the competition.

Bandwidth considerations

Back in the day, people used to talk about the very abstract concept of ‘Mobile Context’. Google´s famous theory breaks mobile users down to three types (5):

Repetitive Now

People that use their phone to stay up to date with ongoing, repetitive changes (sports scores, Facebook feeds or stock market)

Bored Now

Users that put their phone out while waiting for something to happen.

Urgent Now

Pretty self explanatory

Sounds assumable, right?

Well, the truth is there is no truth about this. There is no 'mobile context'. People will use their phone not only when they are walking in the street, travelling by train or relaxing in their home. They do everything at the same time!

Phones follow people everywhere, so people use them anywhere.

Mobile context is important, but first we need to figure out what the heck it is.Tim Kadlec

Luke Wroblewski shows some really interesting stats: (6)

Where are people using mobile devices?

  • 84% at home
  • 80% during miscellaneous downtime throughout the day
  • 76% waiting in lines of waiting for appointments
  • 69% while shopping
  • 64% at work
  • 62% while watching TV (alt. study claims 84%)
  • 47% during commute in to work

As new situations emerge, as new markets and different habits rise, mobile context will change. We can safely assume that the concept of mobile context will always be on the move, until people stop using mobile phones.

This leads us to keep an eye on bandwidth. There is only one scenario where you can serve users an obese website and get away with it: serve it to their macbook pros, while they are at home in UK or the USA with a full bandwidth.

But the rest of possible situations, which are a great many, have to be covered aswell. These include the seemingly endless stream of devices poured every day into the market, which people use to visit websites.

You don’t get to decide which devices access your site, your users doKaren McGrane

They include the countries which didn’t have that many smartphones a few years ago, but are ruthlessly getting ahead.

If your stuff, if your content, if your information, if your products, if your services are not available on mobile, they don’t exist for these peopleKaren McGrane

But more importantly, they include all the places people will be at when using your site. So you have to watch all bandwidths. It’s not only inhabitants of poor areas of the world clearly don’t have the same data-speed coming their way. People will try to access a site at work, with a 100mb/s connection; at home, with 2 to 30mb/s and also with 3G, and also with 4G, and also with a data plan, etc., etc.

To put it bluntly, Responsive design is not anymore about screen sizes but about different scenarios, so the solutions must be flexible, adaptable and thought out top to bottom.

And How?

Well, glad you asked.

We said before not to look at performance as a bunch of automated tasks run server side that help with an already doomed site. There are ways to undertake this concerns and turn them into a competitive advantage.

What to avoid

Guy Podjarny cites three main reasons for the number of bloated responsive websites we see out there: (1)

Download and Hide

Assets are still downloaded, but hidden.

Download and Shrink

High-res desktop-level images are downloaded, and shrinked to fit the users screen

Excess DOM

There is no way to avoid browsers parsing and processing all areas of the DOM, including the hidden ones

A preemptive approach

There’s a great deal of information out there about why websites keep failing to surpass expectations in performance. But what most people come to say is something like ‘Be responsible from the start’. All techniques I’m going to cover have been around for a while. To me the interesting part comes in how they mix and intertwine, covering each other’s flaws and combining their strenghts. It is now, deep in the mobile explosion that they show how powerful they are.

Progressive Enhancement…

…is all about providing a web experience reduced to the essential and take it from there.

A couple of years ago this theory was taken mostly from a browser point of view. With emerging technologies like HTML5, CSS3, jQuery and so on, the web makers had kind of forgotten about their users. Quite a big percentage of them were getting an incomplete form of their site, relying a bit too much on this shiny new tech.

Now that Webkit engines and Firefox and others have taken over much of the market share, the problem is the enormous quantity of devices with browsers that don’t have the capabilities of the brand new iPhone or Samsung. Again, Progressive Enhancement is the only approach which takes care of these forgotten players first and leave the shine for the ones that can take it.

Mobile First Development

Back in 2009, Luke Wroblewski proposed designing mobile first for three reasons: (7)

  • Mobile is exploding
  • Mobile forces you to focus (allowing you to get rid of the clutter that stems from having too much screen real estate)
  • Mobile extends your capabilities (with technology like GPS, geolocation, multi-touch gestures, accelerometer, cameras…)

Since then, Web design has been rapidly shifting to this approach. Along the way not only designers, also many developers, have pointed out that building mobile first gives you an edge over desktop development, very related to Luke W’s second point. Progressive Enhancement and Mobile First Development have suffered a fusion of sorts. Devs start building for mobile and progressively enhance from there, taking larger screen space as an enhancement over a mobile core foundation.

Jordan Moore makes a good summary of the reasons(8). He argues that, since 'we can't safely bet on connection speed''The 'responsible Web designer' would build for the lowest point of entry - a mobile-first approach, assuming for the slowest connection speed and building up from there to larger breakpoints for faster connections'. In the future, we will be able to rely on solid bandwidth detection, but for now it is a good idea to take it as a concern and try not to take any steps in the wrong direction.

To sum up:

Code the site for the lowest resolution and possibilities that you care about. Make true use of Progressive Enhancement from the start. Build extra functionality, enhanced visuals and interaction when it can be used.

RESS: REsponsive Web design + Server Side components

To many people, Responsive design had kind of an essential short-coming. It relied mainly in screen width detection.

As more and more types of devices emerge, hybrid devices like touch screen laptops and so on, feature detection has become essential for Responsive design. Libraries that provide it, mainly Modernizr, have bloomed and are now used on most projects. They help devs valuate whether the client’s browser supports certain functionality and provide it accordingly. But many times it’s tricky to rely on browsers, because ‘they’ will say they support features when, really, ‘they’ do whatever they want. Support for new features is usually partial.

RESS was born to provide a solution. Like Mobile First, the term was coined by Luke Wroblewski in 2011 (9). It relies on detecting the user’s device type, evaluating it and providing an experience taylored for it. To do this, there are heavy tools out there, like WURFLDeviceAtlas or lighter ones like Browser Gem, that read the user agent string and start from there.

Evaluating the device type has other advantages. It allows devs to serve different templates depending on the user’s device. Say you are building a ver large site, and you want your mobile navigation to be a simplified one, that doesn´t take half as much space as the desktop one. You could either play with content, showing and hiding stuff, moving divs around with JavaScript, or you could have different templates for mobile and desktop screens and have the server decide which one to serve.

This gives Responsive design an edge over Mdot sites. Mdot’s only advantage until RESS came along was providing an experience specific for mobile devices.

The BBC (very smart people, with millions of readers across the globe and a big responsibility toward their users) talk about how RESS and Progressive Enhancement could work as one and only. They call their approach Cut the Mustard! (10). It consists of creating a core experience that will work on every device you can imagine. After that, they evaluate the device on the server and they decide whether or not it ‘Cuts the mustard’. If it does, a progressively enhanced experience is handed out. But again, if it doesn’t, the user can still access the core content.

Conditional Loading

Mobile users want to see our menu hours and delivery number. Desktop users definitely want this 1mb png of someone smiling at saladMat ‘Wilto’ Marquis

Let’s take a couple of points of view into account:

  • Mobile users want THE content, as much as desktop users.

If your content is accessible from a URL, it will be accessed by mobile devices.Brad Frost

  • Mobile forces you to focus. There are some constraints designers have to embrace to serve the same content, like bandwidth and lesser screen size.

Also refered to as ‘Agressive Enhancement’, this development technique allows designers to focus on the core content and progressively enhance it for bigger screens. It provides basic access to certain content that can later be injected on the page when space becomes available.

It might be more accurate to think of conditional loading as a content-first approach. You don’t have the luxury of sidebars or multiple columns to fill up with content that’s just nice to have rather than essentialJeremy Keith

Use excellent tools like MatchMedia, that mimics CSS behaviour evaluating screen size in JavaScript.

Lazy Loading

Image and user heavy sites that need to be optimized for mobile, like Facebook, Twitter or Pinterest, make use of Lazy Loading to provide a better experience. When you first load the page, a number of posts is loaded. When you scroll down, the designer assumes it is because you want to browse through even more content, so it is injected in the page via Ajax. This makes the page load much faster by avoiding DOM excess.

Setting a performance budget

Tim Kadlec argues that setting a maximum page weight and being always aware of it is the ultimate way to keep page load down (11). ‘Set your goals and stick to them’. Steve Souders mentions three options to choose from, if you fall over your budget:

  • Optimize an existing feature or asset
  • Remove an existing feature or asset
  • Don’t add a new feature of asset.

To me this sounds a bit radical, but it makes a point of closely following the overall performance of a site over time and with each new feature.

Let’s get Technical!

There are certain methods to achieve speed, that work in a more technical and less conceptual level.

Image Techniques

Images constitute around 60% of websites. If you are serving mobile users with unknown bandwidth connections desktop-sized images, you are basically dooming your site to poor performance

The trick to overcome this is to serve different versions of images, depending on screen size or type. You would serve a small image to a mobile phone and a high-res one to a desktop. You would serve a double-sized image to a Hi-DPI device.

Responsive Images

Designers and developers all over the world have been fighting to get responsive images into the HTML specification. Mat ‘Wilto’ Marquis is one of the most outspoken. The battle is not yet won, but there are a number of solutions that rely on JavaScript to achieve a desired result. Scott Jehl, also from the Filament Group, wrote a plugin that mimics the markup proposed by the community and works like a charm: PictureFill

Compressive Images

Daan Jobsis, a dutch designer, found a very strange phenomenon when compressing images with Photoshop (12). He proved the following: Take an image, double its size (200%), compress it to 25% or less its original quality, resize it back in the browser(100%). The image will not only be lighter in size but already optimized for HiDPI screens, since its pixel density is already doubled.

The only observed problem is that the browser might have a hard time painting a double-sized image back to its original size (if it has to do it a hundred times, like in image-heavy sites), so a little bit of testing is required to see if this is the optimal solution.

Vectors VS Bitmaps

SVG images are the way to go at the time. They are completely scalable, so they will perform better in any screen. Providing fallback is very easy through Modernizr.

Icon Fonts

Technically they are vector based images, only served as a font. As Chris Coyier puts it, ‘Icon Fonts are Awesome because’:

  • You can easily resize
  • You can easily change the color
  • You can easily shadow their shape
  • They will work in IE6, unlike transparent PNGs
  • You can do everything you can do with images
  • You can do anything you would do with typography

HiDPI images

Dave Bushell wrote recently a very interesting article with some thinking on HiDPI images (12). He argues that, even if today we have the possibility of serving iPhones, iPads and other modern devices with images that will fulfill their screen capabilities, it is still too soon to assume a site is not going to get crippled by doing it.

Does a fast connection and high pixel density mean users even want higher quality? Not likely on mobile data plans.Dave Bushell

The point is to do it but do it sensibly, considering the case before jumping into 4x images.

What’s next

Google recently developed a new image format, WebP. It provides lossless and lossy compression for Web images, resulting in files 3x smaller, compared with PNG.

There are simple, lightweight JavaScript libraries that convert to and from WebP available today. Considering the impact of Google’s latest tools, it’s probably a good idea to start experimenting today in order to handle an image-heavy site .

Asset Loading

Load assets carefully and in order. Controlling this aspect provides a big advantage, by allowing the page to render the basic content and enhance it afterwards.

CSS, Images

Controlled loading through media queries, conditional or lazy loading and responsive / compressive image techniques


Make use of HTML5 functionality, like async or defer. There are also loading helpers like RequireJS that can handle loading and dependencies.

Advertising, Social Widgets or any third party assets

Just inject after load.

Old-school Performance Techniques

They have been around for a while, but are still as relevant today.

Reduce the number of HTTP Requests

To achieve this devs have to think resource by resource, but here are a number of guidelines:

  • Concatenate all CSS files or make use of CSS Preprocessors to compile them into one file.
  • Unify all JS Plugins under the same file and always load them in the footer, unless they really need to block the rendering of the page (if you load Typekit fonts in the footer, you will get the famous FOUT or ‘Flash of Unstyled Text’).
  • If you must use PNG images, use sprites. They unify all images in one and make use of CSS to cut the pieces. There are a number of online solutions to do this.
  • Make use of the data URI scheme where possible, that allows you to include images as inline data, getting rid of some more HTTP requests.

Reduce the number of Bytes

Uglify, minify every Script or CSS file you call from the page. Set your server up to allow GZIP compression and expansion and GZIP every asset.

In Summary

The importance of Web performance has been slightly overlooked since the birth of Responsive design.

Designers and developers have been focusing on how to solve the Responsive puzzle and, along their way, a new multi-bandwidth, multi-device, multi-location Web is starting to come into focus.

To be prepared for tomorrow’s problems, we have to include performance as an essential consideration, as the Desktop-centered Web is disappearing before our eyes. The mobile user is hastier and readier and won’t jump through hoops to get the content, and since more and more sites spring every day, being fast will mean being ahead.


1. Performance Implications of Responsive DesignGuy Podjarny

2. Performance as DesignBrad Frost

3. Website abandonment happens after 3 seconds

4. How Page Load Speed Impacts SEO And User ExperienceSpencer Yao

5. Organizing MobileLuke Wroblewski

6. When & Where Are People Using Mobile Devices?Luke Wroblewski

7. Mobile FirstLuke Wroblewski

8. Responsible Considerations For Responsive Web DesignJordan Moore

9. RESS: Responsive Design + Server Side ComponentsLuke Wroblewski

10. Cutting the mustardBBC´s Responsive News

11. Setting a Performance BudgetTim Kadlec

12. Retina Revolutie Follow UpDaan Jobsis

13. The Raster Image ParadoxDave Bushell

Follow the discussion 


Five Responsive Web Design Pitfalls To Avoid

There are number of nasty traps to avoid when making your site responsive. Brad Frost of R/GA reveals five of the biggest ones and how to sidestep them

Creating great responsive experiences requires a hell of a lot more than media queries. If you think creating squishy layouts is all this responsive thing is about, you’re missing the point. The fact is we need to deliver a solid user experience to a growing number of web-enabled devices, and creating entirely separate device experiences simply isn’t scalable in the long run. Creating adaptive experiences is a smarter way forward, but that doesn’t mean this approach isn’t without its challenges.

Here are some of the pitfalls you want to avoid as you travel down the responsive road:

1. Hiding content

Because responsive sites share a single code base, they have a better chance of achieving content parity, which is great. However, that doesn’t mean that it’s all gumdrops and butterflies. There are still many responsive sites that hide or remove content for smaller screens in order to deal with screen real estate constraints.

Follow this simple guide: don’t penalise users for the device they happen to be browsing with. People are coming to our sites and services with expectations, and it’s our job to make sure they’re able to achieve their goals. Mobile users will do everything desktop users will do, but it must be presented in a usable way. So do all that you can to make sure as many people as possible can access your content and functionality.

It’s also worth noting that content that gets hidden with CSS still gets downloaded, which is terrible for performance and brings us to our next pitfall to avoid…

2. Bloating it up!

OK, so you’re not gutting content for small screens and you’ve made an effort to deliver a full experience regardless of context. All’s well with the world, right? Well no, because now you have a bunch of stuff to load and that takes time. 74% of mobile users will leave after 5 seconds (PDF) of waiting for a page to load, and the unfortunate reality is that only 3% of small screen versions of responsive sites are significantly lighter than their large screen counterparts. That means users bear the burden of a potentially massive download.

normal page on Barack Obama’s responsive site weighs over 4MB. Four. Megabytes. This is unacceptable by any standard, but especially falls apart when you consider users who may be on EDGE, 3G or poor WiFi connection.

Obama Mobitest Performance Results

For a site whose goal it is to reach out to the general population (all with different mobile races, mobile creeds, mobile colours and mobile religions), this causes serious accessibility issues:

Sure, part of this is RIM’s doing, but these are real constraints that we need to be aware of

Sure, part of this is RIM’s doing, but these are real constraints that we need to be aware of

One of the biggest challenges of creating responsive web designs is the balancing act of delivering a full experience while still maintaining a snappy user experience across the board. Cut away the cruft, follow performance best practices, don’t assume a strong connection by default, and look for ways to exploit great techniques like conditional loading to keep initial page sizes down.

3. Ignoring contextual conventions

A phone is not a tablet is not a laptop is not a desktop is not a TV.

Each device provides its own unique form factor, interface conventions, constraints and opportunities. We need to be considerate of all these variables in order to create experiences that feel natural to the user. Now I’m not recommending recreating every platform’s native UI in the browser, but we do need to be mindful of how people hold their devices, what icons they’re used to seeing, and so on and so forth. A good responsive experience reaches outside of the sandbox that is the browser and is sympathetic to the user and the device context.

Responsive web design by definition is not mobile design, so it’s up to us to introduce contextually-considerate elements to our designs. That means handling responsive navigation in a way that makes sense to visitors across contexts. That means designing for touch. That means avoiding forcing mobile users to sift through ridiculously long amounts of disparate content just to find what they’re looking for.

Let’s account for the many differences across these devices, understand that some compromise is inevitable, but put forth a solid effort to be more considerate of context.

4. Serving a one-size-fits-all experience

Mobile is much more than just various small screens, and these emerging contexts unlock entirely new use cases, patterns and possibilities. We shouldn’t sell ourselves short by only creating responsive layouts. For example, we sometimes forget that mobile phones can get user location,initiate phone calls, and much more. Hopefully soon browsers on all these gadgets will have access to even more device APIs, further pushing the boundaries of what’s possible on the web.

We should all we can to make the entire experience respond to what the device is capable of. Addressing constraints first gives us a solid foundation to stand on, then we can utilise progressive enhancement and feature detection to take the experience to the next level.

5. Relying on device dimensions

320px. 480px. 768px. 1024px. The fold. Oh God, the fold.

The fact of the matter is that we don’t control what our visitors’ browser sizes are, nor what dimensions manufacturers decide to make their devices. Believe me, they’re trying every size in the book.

Devices of all shapes and sizes

Why you should never rely on device dimensions

In addition, page height has always been even more of a moving target because of bookmarks bar, browser chrome and the Ask Jeeves toolbar. But now in the mobile web world, a web experience is often not seen through the lens of the browser at all. We visit links through Facebook, Twitter and other apps, each of which has its own custom chrome for containing web views. Of course hierarchy of content still matters and you want to get to the guts of the page as soon as possible, but you can’t get all worked up over the available pixel height, learn to let go.

In his article Fanfare for the Common Breakpoint, Jeremy Keith eloquently states that “it’s not about what happens at the breakpoints, it’s about what happens between the breakpoints.” That means our designs should hold together irrespective of any particular dimension.

Let the design itself sort out where breakpoints should occur. I absolutely lovethis advice from Stephen Hay:

“Start with the small screen first, then expand until it looks like shit. Time to insert a breakpoint!

By letting the content itself determine the breakpoints of our responsive designs, we’re preparing our designs to look great in not just today’s landscape, but tomorrow’s as well.

Do the evolution

We’re at the tip of the iceberg as far as creating adaptive experiences go. While these pitfalls (and many more not covered in this article) exist, they are no reason to shy away from creating adaptive experiences. With more connected devices of all shapes and sizes come onto the scene every day, we as web creators have an opportunity to be there when they arrive. While it’s admittedly a bit daunting, we should accept the challenge and embrace the opportunity to reach people wherever they may be.


“We’re at a tipping point with connected devices,” a recent blog post from Microsoft MSFT +1.69%‘s Internet Explorer team reads. “Every day, 3.6 million mobile devices and tablets are activated worldwide. That’s over five times more than the number of babies born each day!”  Source

Why We Need Responsive Images

The topic of responsive images has been one of the most hotly debated topics amongst web developers for what feels like forever. I think Jason Grigsby was perhaps the first to publicly point out that simply setting a percentage width on images was not enough, you needed to resize these images as well. He showed that if you served appropriately sized images on the original responsive demo site, you could shave 78% off the weight of those images (about 162kB) on small screens.

The discussion has evolved since then with debates over what sort of solution we need (server-side, client-side), new markup (srcset vs picture) and even, in some cases, wondering whether we really needed to worry about it at all.

It’s a messy issue for sure. The current solutions for responsive images do come with some complexity and overhead. If you’re using a client-side solution and don’t want to make more than one request per image, then you end up breaking the preloader. As Steve Souders explained rather well, this can have a very negative impact on the time it takes for those images to actually start appearing to your visitors.

No doubt there are trade-offs. Complexity of solutions, preloader versus file size—these each have to be considered when making the determination of what solution to use. Eventually we’ll have a native solution which will take care of the preloader issue, but browsers sure seem to be dragging their feet on that.

In the meantime, I was curious just how much page weight could be saved with a responsive image solution in place. I know that on the projects I’ve worked on, the savings has often been huge, but I wanted to see how consistent my experience is with the web as a whole.

Experiment time!

Yoav Weiss created a bash script called Sizer-Soze that, with the help of ImageMagick and PhantomJS, determines just how much you could save in file size by serving optimized and resized images. The script is built for one url at a time, so I modified it slightly to let me loop through a list of 471 URLs (the same list used by Guy Podjarny for his analysis of responsive performance). My bash scripting skills are minimal (read: nearly non-existent), but thankfully Yoav is far more skilled there than I and was happy to help out and make the whole thing run much more efficiently.

The script looped through the 471 urls, spitting out the results into a CSV. Each site was tested at widths of 360px, 760px and 1260px. Numbers were collected for total original image size, size of images if they weren’t resized but were optimized, and size of images if they were both optimized and resized to match the size they actually displayed at (so if a 1200px image was displayed at 280px wide, the script resized the image to 280px and compared the two file sizes).

If Sizer-Soze came across an image set to “display:none” it would re-check the dimensions every 500 milliseconds (for a maximum wait of 25 seconds) to see if things had changed. This was done to account for image-based carousels where images may have been hidden initially but then later revealed. If the image became visible during that time, then the dimensions were used to process the file savings normally. If the image was never displayed, the entire weight of the image was counted as wasted.

Even with that tweak, there are few caveats about Sizer-Soze:

  • It does not make a distinction between 3rd party images and images served by the site itself. So some of the weight can be attributed to things like ads.
  • It does not analyze background images. That’s fine because that’s not what we want here anyway, but its worth noting that potentially even more bytes could be saved.
  • It won’t be able to pickup some clever lazy-loading techniques, so again, its possible that some sites would actually be able to save even more than the reported numbers.
  • It doesn’t include data-uri images in the totals as the file name exceeds the length limit for the script.

After looping through, the list shortened to 402 different responsive sites. Some of the original 471 moved to new URLs or apparently went AWOL so Sizer-Soze couldn’t follow along. Others had no images in the source code—either as a result of some sort of lazy-loading mechanism or by design. Still, 402 sites is a pretty good base to look at.

Results: Total Savings

On to the results! First up, the totals.

Viewport SizeSum of Original SizesSum of Optimized SavingsSum of Resized Savings360237.66MB12.86MB171.62MB760244.39MB13.30MB129.34MB1260250.08MB13.70MB104.31MB

It’s not too surprising to see that the original size (what’s being served now) is pretty consistent from screen size to screen size. Guy’s research, and many others, have already demonstrated this pretty well.

What is staggering is just how massive the savings could be if these sites served appropriately sized images. At 360px wide, these 402 sites combine to serve 171.62MB of unnecessary weight to their visitors . That’s a whopping 72.2% of image weight that could be ditched by using a responsive image technique.

It’s not just small screens that would benefit. For 760px and 1260px sized screens, 52.9% and 41.7% of image weight is unnecessary.

Results: Average Savings

Let’s look at the savings in terms of per-site averages.

Viewport SizeAvg. Original SizeAvg. Optimized SavingsAvg. Resized Savings360603.89kB32.68kB436.08kB760622.53kB33.88kB329.47kB1260635.43kB34.81kB265.06kB

Looking at it from the perspective of an individual site, the numbers feel even more impactful. For each screen size, sites on average would shed about 5% of the weight of their images (from 32-34kb) by simply doing some lossless optimization. Considering that this could be automated easily into a build process, or manually done with tools like ImageOptim with little effort—that’s an easy 5% improvement.

Unsurprisingly, the gains are much more significant if those images get resized to an appropriate size as well. At 360px, the average site would drop 436.08kb. Consider that for a second. One optimization (resizing images) dropping that large of a chunk of weight. That takes image weight for a page from 603.89kB to a mere 167.81kB. That’s a huge difference that shouldn’t be dismissed.

While the improvements are slightly smaller for larger screen sizes (as you would expect), using some sort of responsive image technique would still save 320kB for sites displayed at 760px and 265kB for sites displayed at 1260px.


We spend a lot of time talking about responsive images online—debating the approaches, trying out new solutions. Sometimes it can be a little discouraging that we still haven’t gotten it ironed out (I know I feel that way frequently).

But the web needs us to be diligent. It needs us to not settle for seemingly simple solutions that sacrifice performance. It is extremely rare where one optimization lets us knock off such a significant amount of page weight, but here we are staring one such technique right in the face.

72% less image weight.

That’s why we need a responsive image solution.


Multi-Device Web Design: An Evolution

As mobile devices have continued to evolve and spread, so has the process of designing and developing Web sites and services that work across a diverse range of devices. From responsive Web design to future friendly thinking, here’s how I’ve seen things evolve over the past year and a half.

Device Love

If you haven’t been keeping up with all the detailed conversations about multi-device Web design, I hope this overview and set of resources can quickly bring you up to speed. I’m only covering the last 18 months because it has been a very exciting time with lots of new ideas and voices. Prior to these developments, most multi-device Web design problems were solved with device detection and many still are. But the introduction of Responsive Web Design really stirred things up.

Responsive Web Design

Responsive Web Design is a combination of fluid grids and images with media queries to change layout based on the size of a device viewport. It uses feature detection (mostly on the client) to determine available screen capabilities and adapt accordingly. RWD is most useful for layout but some have extended it to interactive elements as well (although this often requires Javascript).

Responsive Web Design allows you to use a single URL structure for a site, thereby removing the need for separate mobile, tablet, desktop, etc. sites.

For a short overview read Ethan Marcotte’s original article. For the full story read Ethan Marcotte’s book. For a deeper dive into the philosophy behind RWD, read over Jeremy Keith’s supporting arguments. To see a lot of responsive layout examples, browse around the mediaqueri.es site.


Responsive Web Design isn’t a silver bullet for mobile Web experiences. Not only does client-side adaptation require a careful approach, but it can also be difficult to optimize source order, media, third-party widgets, URL structure, and application design within a RWD solution.

Jason Grigsby has written up many of the reasons RWD doesn’t instantly provide a mobile solution especially for images. I’ve documented (with concrete) examples why we opted for separate mobile and desktop templates in my last startup -a technique that’s also employed by many Web companies like Facebook, Twitter, Google, etc. In short, separation tends to give greater ability to optimize specifically for mobile.

Mobile First Responsive Design

Mobile First Responsive Design

Mobile First Responsive Design takes Responsive Web Design and flips the process around to address some of the media query challenges outlined above. Instead of starting with a desktop site, you start with the mobile site and then progressively enhance to devices with larger screens.

The Yiibu team was one of the first to apply this approach and wrote about how they did it. Jason Grigsby has put together an overview and analysis of where Mobile First Responsive Design is being applied. Brad Frost has a more high-level write-up of the approach. For a more in-depth technical discussion, check out the thread about mobile-first media queries on the HMTL5 boilerplate project.


Many folks are working through the challenges of designing Web sites for multiple devices. This includes detailed overviews of how to set up Mobile First Responsive Design markup, style sheet, and Javascript solutions.

Ethan Marcotte has shared what it takes for teams of developers and designers to collaborate on a responsive workflow based on lessons learned on the Boston Globe redesign. Scott Jehl outlined what Javascript is doing (PDF) behind the scenes of the Globe redesign (hint: a lot!).

Stephanie Rieger assembled a detailed overview (PDF) of a real-world mobile first responsive design solution for hundreds of devices. Stephan Hay put together a pragmatic overview of designing with media queries.

Media adaptation remains a big challenge for cross-device design. In particular, images, videos, data tables, fonts, and many other “widgets” need special care. Jason Grigsby has written up the situation with images and compiled many approaches for makingimages responsive. A number of solutions have also emerged for handling things likevideos and data tables.

Server Side Components

Combining Mobile First Responsive Design with server side component (not full page) optimization is a way to extend client-side only solutions. With this technique, a single set of page templates define an entire Web site for all devices but key components within that site have device-class specific implementations that are rendered server side. Done right, this technique can deliver the best of both worlds without the challenges that can hamper each.

I’ve put together an overview of how a Responsive Design + Server Side Componentsstructure can work with concrete examples. Bryan Rieger has outlined an extensive set of thoughts on server-side adaption techniques and Lyza Gardner has a complete overview of how all these techniques can work together. After analyzing many client-side solutions to dynamic images, Jason Grigsby outlined why using a server-side solution is probably the most future friendly.

Future Friendly

Future Thinking

If all the considerations above seem like a lot to take in to create a Web site, they are. We are in a period of transition and still figuring things out. So expect to be learning and iterating a lot. That’s both exciting and daunting.

It also prepares you for what’s ahead. We’ve just begun to see the onset of cheap networked devices of every shape and size. The zombie apocalypse of devices is coming. And while we can’t know exactly what the future will bring, we can strive to design and develop in a future-friendly way so we are better prepared for what’s next.


I referenced lots of great multi-device Web design resources above. Here they are in one list. Read them in order and rock the future Web!


Death To The Waterfall [Webdesign]

imageMost developers/designers adapt to the waterfall process, because it’s an industry standard. It’s in every job post, “Must be able to handle 1000’s of projects at once.” Hmm, no thanks.

This process can have adverse effects on the whole organization. Delayed projects effect other projects by tying up valuable resources. Making it very hard to allocate team members because everyone is multi-tasking.

This process does not create teams it creates assembly lines. It divides teams into silos that don’t communicate until it’s time to hand off deliverables. This causes confusion because most of the communication is misinterpreted, or lost between team members.

imageThis process is both duplicative and inefficient. 

I’ve always had a problem with the standard agency waterfall process. It sucks. And to tell you the truth, its not even worth fixing. The problem lies within the structure itself, so patching it won’t help. 

We need a new process.

In order to change our process we must change the way we think. Every team member must contribute to a project’s strategy from day one. Instead of one team that handles multiple projects lets create smaller teams with 100% committed resources to one project. Let’s explore further. 

“Process is often shaped by how teams are organized. Small tactical teams can accomplish more are capable of executing multiple rounds of planning, design, and code quickly.” - Trent Walton

Smaller teams inspire communication and collaboration among its members. They also invoke skill overlap & peer learning as they are expected to perform their jobs as well as any others if needed. When a team member finishes their tasks, they shift to support the other members in any way possible.

A small team should include a project manager, a designer and a developer at the least. The members should dedicate all of their time to one project and set a goal for a specific iteration. An iteration can be 1 to 6 weeks depending on the scope of the project. The point is that all members take part of strategy, planning & execution. 

“Everyone is just as important on a project. Some play larger roles, some only share a single idea, but all voices need to be heard and understood.” - Daniel Mall

We need a new process based on smaller teams that are fluid and always changing, just like the technology we build with. 

We need a responsive process.image


  • Identify team members and establish project roles.
  • Conduct a kickoff meeting with the client, gather requirements & project goals.
  • Gather and audit content.
  • Define the project strategy and scope.
  • Compile communications brief and send to the client.
  • Create a site diagram from content and communications brief.
  • Send site diagram to client for feedback.
  • Revise site diagram based on client feedback.


  • Sketch UX layouts from site diagram and content.
  • Code a responsive HTML Prototype from sketches, site diagram and content.
  • Send the HTML Prototype to the client for feedback.
  • Revise HTML Prototype based on client feedback. Create style guide in Photoshop during feedback phase.
  • Send the style guide to the client for feedback.
  • Revise style guide based on client feedback. Create mock-up in photoshop during feedback phase.
  • Send mock-ups to the client for feedback.
  • Revise mock-ups based on client feedback. Code beta website from html prototype & mock-up during feedback phase.
  • Send the beta website to the client for feedback.


  • Test responsive site across browsers and multiple devices.
  • Establish a maintenance plan & schedule training.
  • Launch website!
  • Conduct a follow up meeting with team members and client to address overall process and ways to improve.
  • Learn from team mistakes and refine process.


  • Testing starts in the prototype phase which allows more time to identify & fix bugs.
  • Design mock-ups based on a live responsive prototype as apposed to a static wire-frame.
  • Prototype code becomes the framework for the final site.
  • Save time by designing in the browser instead of designing static wire-frames.
  • Client gets to preview and make changes in their native browser. Priceless!

Special thanks to Trent WaltonBen CallahanDaniel Mall and Steve Fisher for inspiring me to write this article.

Now lets get out there and build the web!




Video: Retina done right: An easier, better workflow for web designers.  Below, Kyle Foster shares his best practice workflow for efficiently servicing high-resolution images for Retina Displays. Source