A legitimate fear in the age of The Internet of All Things is that we’ll all become tethered to our devices. Skills you learned as a young child, such as walking and chewing, will become foreign as we become acclimated to the in-between—phone, glasses, whatever gadget—that exists between us and the world.
Psychologically, this evolution in technology means there is less of a felt barrier between our devices and us. Before, the exacting nature of table-based websites came from the awkwardness and unnaturalness of the devices on which they were rendered. Boxy computers in one size. We craved assimilation. We created the web inheriting this rigidity.
Now, we expect an organic experience from these devices that are essentially extensions of our body. We expect a fluidity from phone to computer, from website to email.
The idea of a fluid web is neither new nor innovative. We as an agency are taking a stance that we should return to this previous ideal—we strive to design with this core tenet in mind. The Fluid Web is a tech-agnostic approach to the web that removes barriers and enables human communication. Fluid design realigns the focus on the user and his or her unique journey instead of the device.
It’s a basic expectation everyone should have, but because of the way our technology evolved, we have managed to start with a fluid web (where content flowed freely), migrate to a web of table cells, and end up back to where we are, hopelessly trying to return to where we began.
The new eroi.com is built with this fluid philosophy in mind—here are some of our insights. The fluidity extends beyond the deliverable (website and email frameworks) into the process we used to create it.
FRAMEWORK MEANS FREEDOM
Designing for a framework presents the unique challenge that you aren’t working with all the actual content, but instead future potential content. Today’s us are designing for tomorrow’s they. The benefit of working in a framework (rather than a template) is that you can adapt and change individual elements in one fell swoop. As needs evolve (which they will), you can meet those needs by adding a module here and there, or restructuring a page.
COLLABORATION NOT CONTROL
After we created our module list, the design team created a style guide and module blueprints, which liberated the development team to start creating modules. Designers have become accustomed to controlling the outcome and end result, which sometimes means a lot of hovering over developers. The lack of comps as scripture meant we had to have conversations with each other about things like intent and possibilities rather than comp versus live. (This very topic was the subject of our Design Week Portland series. Read the recap).
(Although conversations reigned supreme, we still utilized comps in instances where a baseline needed to be set. It was utilized more as a rapid prototyping guide than an absolute.)
TRIED-AND-TRUE OR TEST
Part of creating a new site is ensuring we were accessible to our audience—from both a content and user experience perspective. Sometimes as an industry, we get caught up on things like “will people know to scroll” (see Huge Inc’s article, “Everybody Scrolls”). As a performance-driven agency, we want our designs to be proven.
If we only focus on our designs being proven, we miss out on something very special about design: the potential to try something new. The first time someone swiped on a phone they may have been surprised by that interaction.
Since we’re analytics retentive, we want to track these reactions—what happens? Did the user bounce? Did they stay longer? Informing these design decisions with this context after the fact will allow us to tweak these elements based on this information.