More Lessons From An Event Apart

December 11, 2015

lara-hogan-onstage_1_696_378Last time on the Peepshow, I wrote about writing.

I also wrote about designing with performance in mind, designing for a unified user experience and using design systems to create more fluid design processes that result in user-centered interfaces. This time around I’ll dig deeper into how we reach those performance goals, how to implement a design system and then touch on some more idealistic concepts like designing for crisis and using empathy in product development….

Day 2 of An Event Apart had a drastically different tone from Day 1. While Day 1 introduced concepts and philosophies and broad strokes of draft technical options and their browser support, Day 2 became increasingly technical and applicable to day-to-day work.

Performance was clearly an important topic throughout the event and the first speaker, Lara Hogan (pictured above), provided a laundry list of methods for optimizing websites for all networks. I won’t bore you with all of the details, but essentially the paradigm boils down to minimizing network requests and minimizing file size. This means two things:

  • Combining scripts/frameworks, or including less of them.
  • Combining images, optimizing images, or including less of them.

In terms of optimizing images, there’s no clear file type that’s superior. It all comes down to the image itself and its application. GIFs have always been the bread and butter of the web, but these days PNGs can often save precious kilobytes for files with very few colors. If the image has many colors and a great deal of contrast, JPGs are the way to go. Custom fonts are often a huge payload, and so calling them in on desktop-only can create a better user experience on mobile. Regardless of where you decide to save on performance there are two ways to test it:

  • Real User Monitoring: Actually recording a real human interacting and measuring it. This is a useful first step for usability.
  • Synthetic Monitoring: Recording a scripted interaction and measuring it. This is a useful second step for determining performance in other geographies and environments you wouldn’t be able to emulate yourself.

Both methods can be time consuming, but if network performance is crucial to the quality of the end product, this step is invaluable. This discussion of performance was followed by an in-depth look at the current state of responsive images.

A responsive image is one that not only resizes to fit within the boundaries of the screen, but also fits within the context of interface. This issue of context results in two different use cases for responsive images:

  • Art direction: An image may need to be cropped differently depending on the size of the screen
  • Resolution switching: With the advent of multiple display densities and devices that can be rotated, images may need to resize or be cropped.

This currently requires an increase in the amount of markup on the page, which means more work for the designers and developers, but a better experience for the user. Hopefully the next few years will feature some standards that ease this burden.

all credit to Brad Frost on this. go buy his book!

One methodology that can assist with both performance and determining use cases for responsive images is Brad Frosts’ patented “Atomic Design”. He boils down the concept of design systems into an easy to understand format that can be explained to clients and account folks alike, and when implemented it can facilitate a more agile development process. Instead of presenting static design mockups of each “page” of the site, we need to maneuver towards presenting mockups of different components of the interface. This would mean designing a button and an input field separately and presenting them that way. Once they are approved, the designer would demonstrate what they look like together as a component – such as a search bar – and then as a complete system in relation to other components. How does the search bar look in the header? Or will it appear in the sidebar? Either way, we know what it should look like and the designer won’t need to produce entirely new static mockups for approval.

Let’s broaden our perspective a bit and discuss why these things are important. The most emotional speaker of the weekend gives us a fantastic reason to consider performance, responsiveness, and agile design: users in crisis. Designing for crisis can be more of an exercise in content strategy but quickly becomes an issue of intelligent design and performance conscious development. Eric Meyer provided the heart-wrenching scenario of a loved one being sent to a hospital far away in the middle of the night and not having even the basic capacity to navigate a website. A user in this “crisis driven” state shouldn’t be presented with marketing jargon, high-resolution images or a list of services the hospital provides. They should, logically, be provided with instructions for how to reach their loved one. In hindsight this is a no-brainer, but when the decision makers and stakeholders all have unique agendas for what content needs to be presented, they often forget the end user. The solution is to determine various user personas. Meyer offers a few key takeaways on this topic:

  • Add a “crisis driven persona” to your list of potential users.
  • Don’t refer to them as an “edge case” as their situation is likely the most imperative to your core services.
  • Consider the impact of a bad experience for this user.

The idea is that if you effectively cater to this user, they won’t even notice the design and you’ve effectively helped them in ways that can change lives. Powerful stuff!

Continuing in the vein of empathy and user-centered design, we were told about unique software company who required all employees – to varying degrees – to work on customer support. They claimed that if everyone from interns to executives understood the methods of their users, various pain-points and how the software works, it would result in more efficient and effective product releases. It allowed them to prioritize features and bug catches. And most importantly, users felt involved in the products’ evolution, which obviously meant retention and in turn increases in adoption.

The final speaker of the day put a bow on all of these various disparate methods and philosophies and summed them up with one word: Resilience. Jeremy Keith explained the beauty of fault tolerant languages that are widely supported vs the draconian languages that can be attributed to both the most frustrating and most amazing applications on the web. This observation leads to a logical conclusion and 3 easy steps that act as a paradigm:

  1. Identify the core functionality/objective of your application.
  2. Ensure that functionality is available with the most widely supported/simple languages.
  3. Then, feel free to enhance for more advanced users.

Your user interface and feature list should be resilient above all else. If the core of your application is functional in the most extreme cases, you can consider the project a success. The rest: just bells and whistles.