LukeW

Syndicate content LukeW | Digital Product Design + Strategy
Expert articles about user experience, mobile, Web applications, usability, interaction design and visual design.
Updated: 1 day 24 min ago

An Event Apart: The Way of the Web

Mon, 04/02/2018 - 2:00pm

In his The Way of the Web presentation at An Event Apart in Seattle, Jeremy Keith discussed building for the Web today and how to manage the rate of change of technologies and tools for Web development. Here's my notes from his talk:

  • Science fiction is not about predicting the future, it is about looking at the concerns we have today and projecting them forward. Novels are empathy machines. You can really get into what the characters were feeling/experiencing and thereby share their concerns.
  • While science fiction books get some things right about the future, they also have blind spots. For instance, people went to phone booths instead of carrying mobile phones. In the present we have a future that was almost beyond what was predicted in seminal works of science fiction.
  • With where technology is today and what is possible, are we in a utopia or a dystopia? Are we excited or afraid of technology's possibilities. What makes the difference? Why are we excited about some technologies and apprehensive about others?
  • Working on the Web can be overwhelming as we have to endure constant changes in technology and processes. When that rate of change is especially steep, things get worse.
  • Stewart Brand's pace layers outline the rate of change of everything from people to buildings. Fashion changes quickly, culture changes slowly, and that's good. We get apprehensive when things that should move slow start changing too quickly. Example: quick changes in government are usually revolutions.
  • The materials of the Web (HTML, CSS, and Javascript) move slow and are more stable, they are lower pace layers. The tools of the Web move much faster and are more subject to change.
  • If a technology helps the developer but not the end user, there's a balance that needs to be understood. Is the trade-off of developer convenience worth a large download for users?
  • We can map Web technologies to pace layers. The bottom layer is the Internet (TCP/IP). This hasn't changed in decades and you don't want it to change. HTTP is the protocol layer above this and is changes very slowly, which is appropriate. URLs are the layer above, which change often but probably shouldn't. HTML and CSS are changing much more quickly but still not as fast as Javascript.
  • Every week there is a new Javascript library, which is where the Web feels apprehensive. Ideas get vetted out in Javascript and when they stabilize, they move down to HTML and CSS. It's ok that Javascript changes quickly -it needs to in order to work out new ideas.
  • You can choose to build single page Web sites in Javascript only. Going directly to URLs and HTTP. However this sets up a works great or doesn't work model. The power of the Web is that we have different levels of "working", a continuum. Everybody gets something with these in-between levels of experience.
  • The rule of least power: "choose the language of least power to accomplish something" It's not as powerful, but much more stable. Instead of doing everything in Javascript, see what can be done in HTML and CSS first.
  • The Web favors ubiquity over consistency. You can get to the content but it may not look the same to everyone. Start with the simplest element (like a select) and gradually apply styling/code to layer on additional enhancements.
  • This mode of building for the Web isn't just for simple sites. Even "complex" sites can be broken down into simpler elements. There's actually a continuum between simple and complex.
  • Progressive Web apps are Web sites that add HTTPS, a Web app manifest, and a service worker. This layering of technology allows sites to not only run securely but also offline.
  • People want browser features to be supported everywhere before they start using them, but that's not how it works. You can start using these elements now even if they only have partial support and get the benefits where they're available.

An Event Apart: Performance as User Experience

Mon, 04/02/2018 - 2:00pm

In his Performance as User Experience presentation at An Event Apart in Seattle, Aaron Gustafson shared a number of ways to optimize Web page performance. Here's my notes from his talk:

  • Our jobs as designers is to reduce friction for our users. Poor performance causes friction and can negatively impact key metrics like conversion and revenue.
  • How do Web pages load: when you enter an address in a URL bar, a DNS look-up replies with an IP address, then there's a TCP handshake followed by the actual request for files/data, once there's a response the browser can actually do something.
  • Once the browser gets a response, it can assemble the document object, the render tree, layout, paint, and finally load. CSS and Javascript can delay this process and sometimes cause it to run again.
Steps for better performance
  • Use native features whenever possible. They are effectively free. Semantic elements not only reduce bytes but also contain attributes that provide a lot of functionality like placeholder, autocomplete, autocorrect, type, etc. System fonts can help reduce the need for custom font downloads. Font stacks can cover fallback issues.
  • Only include assets you actually need. Every tool has a cost, make sure you are really using enough of each tool to justify that cost. Chances are the tool you are trying to use is already on a CDN and you can use resource hints to speed up the download process. But downloading isn't everything as Javascript frameworks also take time to execute, which is slower than native JS processing.
  • Optimize everything. Task runners like Grunt and Gulp can help automate optimizations of Javascript, CSS and HTML. Minify and pre-compress all your files.
  • Think about when you load assets. If you have Javascript files divided into modules, you can defer functions you won't need until the after the DOM is loaded. The async attribute also allows you to load files when it makes the most sense. Just make sure you don't hit any race conditions if some of your Javascript files have dependencies on others.
  • Why so many different files? Under HTTP1, each resources was requested sequentially. Now with HTTP2, you set a single connection and then stream in resources as needed.
  • Consider how you load assets. Start simple by loading just your default (often mobile) CSS file. You can add a media query as a threshold for loading more advanced CSS in browsers than can render it. Conditional comments (which only work in IE8 and below) can either load or hide elements from older browsers. Similar techniques can be used to conditionally load images and animations (via SVG support).
  • Only load assets when they add value. Not every article needs an image, think twice before you include it. Images are 53% of the average web page and very expensive size-wise. If you need an image, use the right format. GIFs ae good for solid colors, JPGs for photographs, PNGs are JPG alternatives with alpha transparency, WebPs are note well supported but optimized in many ways.
  • Images can be optimized by removing color, blurring parts of images, resizing, compressing, and using appropriate formats. We can use the picture element to add WebP images in browsers that support them. Remember to put your smallest files first, because the first one that works is what gets used.
  • Every choice we make affects our users’ experiences. Let’s spend our time to save it for our users.

An Event Apart: Navigating Team Friction

Mon, 04/02/2018 - 2:00pm

In her Navigating Team Friction presentation at An Event Apart in Seattle, Lara Hogan discussed what causes teams at work to have issues and how to address them. Here's my notes from her talk:

  • Teams of people are amazing. Its a privilege to work together with people to make things.
  • Bruce Tuckman found a series of stages that groups of people go through: forming (comes together in a new state), storming (some friction emerges), norming (clarity begins to emerge), performing (effective state). This is a cycle that repeats itself regularly.
  • Storming is a natural part of team dynamics but it does create friction. You need to be able to move past the friction in order to focus on what actually matters.
  • It can take a while for managers to identify and resolve points of friction. So what can team members do to address the issue earlier on?
Core Needs
  • Everyone transforms into different versions of themselves sometimes. The rationale part of our brains isn't always in control. Instead, we may be reacting to fear and/or threats that put us into fight or flight mode. These reactions come from more than use physical safety and shelter needs.
  • Modern humans have several core needs. First, people need to belong to a group or community. Second, people need to make improvements and/or progress (for team, company, or personally). Third, people need to be able to make choices about their work -they need flexibility, and decision-making capabilities. Fourth, people need access to equal resources, information, and fairness. Fifth, people require some amount of predictability in their work days. Lastly, people need to feel their work matters -they need recognition and visibility for work.
  • The BICEPS model (the needs above) gives you a way to assess what could be causing team friction.
  • As an example, moving desks are a great example of why people react emotionally to seemingly sound rationale decisions. They impact belonging, choice, predictability, etc. but do so differently for different people. To address these issues, try to identify the core need being effected.
  • To find which core needs are being impacted, look at the types of resistance you are seeing. Doubt: asking lots of questions/debating the issue. Avoid: not showing up. Fight: people create arguments against the issue. Bond: go to friends & peers to find support. Escape-route: changing roles, leaving company to avoid the threat.
Communication Style
  • When you spot some signals, ask open questions (which are different than yes/no questions). This helps you understand which core needs are being threatened on the team. Then you can figure out how to address the issue.
  • Reflect on the dynamics of the room, what are they thinking and/or worried about? Be aware of your medium: what words, body language are you using?
  • When you make an ask of someone, consider if they can act on what you are saying. Don't tear things down, try to elevate the conversation by being transparent.
  • Assume everyone has the best intentions at work and try to empathize with what other people may be going through.
  • Listen to learn: stay genuinely curious. Operate under the assumption that you don't know the whole story. Be excited to have your mind changed, it helps you learn and grow.
  • Humans aren't great at feedback but we can get better. Good feedback is specific and actionable. This kind of feedback helps us improve and grow.
  • Structure your feedback as: observation of a behavior (just the facts)+ impact of that behavior (share how you feel) + question or request. Write it out first to make sure it's communicating what you want.
  • It's ok to cause some friction, that's a natural part of working together. But know how you can move past it.
Prevention
  • Retrospectives allow people to know their feelings have been heard. Name friction points in these meetings to acknowledge what didn't work.
  • Team charters and docs can helps align people's work against a common vision and clear responsibilities.
  • The absence of trust is the source of most team dysfunctions. How do you get these issues surfaced within a team? Determine if you agree or disagree with decisions and whether or not you can commit to a decision.
  • If/when you need to go to HR or leadership, state what's been tried and what you think could help now. Be prepared that they may take a different action after weighing the situation.

An Event Apart: Content Performance Quotient

Sun, 04/01/2018 - 2:00pm

In his Beyond Engagement: the Content Performance Quotient presentation at An Event Apart in Seattle, Jeffrey Zeldman introduced a new metric for tracking how well Web sites are performing. Here's my notes from his talk:

  • The number one stakeholder request for Web sites is engagement: we need people using our services more. But is it the right metric for all these situations?
  • For some apps, engagement is clearly the right thing to measure. For others, more time spent might be a sign of frustration.
  • Most of the Web sites we work on are like customer service desks where we want to give people what they need and get them on their way.
  • Content Performance Quotient (Design CPQ) is a metric of how quickly we can get the right content to solve the customer's problem. The shortest distance between problem & solution. This tracks your value to the customer by measuring the speed of usefulness.
  • Pretty garbage: when a Web site looks good but doesn't help anyone. Garbage in a delightfully responsive grid is still garbage.
  • Slash your architecture and shrink your content. Ask: "why do we need this?" Compare all your content to the goals you've established. Design should be intentional. Have purpose-driven design and purpose-driven content.
  • We can't always have meetings where everybody wins. We need to argue for the customer and that means not everyone in our meetings will get what they want. Purpose needs to drive our collaborations not individual agendas, which usually leak into our Web site designs.
  • It’s easy to give every stakeholder what they want. Don't take the easy way out. It’s harder to do the right thing. Harder for us, but better for the customer & bottom line.
  • Understanding the customer journey allows us to put the right content in the right place. Start with the most important interaction and build out from there. Focus on key interactions and build out form there.
  • Customers come to our sites with a purpose. Anything that gets in the way of that is a distraction. Constantly iterate on content to remove the cruft and surface what's needed.
  • When you want people to go deeper and engage, to slow down... scannability, which is good for transactions, can be bad for thoughtful content. Instead slow people down with bigger type, better typographic hierarchy, more whitespace.
  • Which sites should be slow? If the site is delivering content for the good of the general public, the presentation should enable slow, careful reading. If it’s designed to promote our business or help a customer get an answer to her question, it must be designed for speed of relevancy.

An Event Apart: Scenario-Driven Design Systems

Sun, 04/01/2018 - 2:00pm

In her Scenario-Driven Design Systems presentation at An Event Apart in Seattle, Yesenia Perez-Cruz shared lessons learned building design systems for multiple brands/Web sites and how specific user-scenarios are key to making flexible solutions. Here's my notes from her talk:

  • Design systems have helped many organizations build better, more cohesive experiences faster. but what's really behind a design system? is it a set of components? a common language? or something more?
  • A good design system feels cohesive, unified, and connected. It achieves something.
  • Bad design systems fail when there's too much focus on elements and not enough focus on how common components work together to create an experience.
  • We need to start our design systems with user-scenarios, not with individual components.
Starting with Elements
  • Vox wanted a design systema nd common platform for their 8 brands and 350+ Web sites. They made a lot of assumptions in the beginning that didn't work. Primarily: a set of flexible, brand-agnostic modules with a theming system would give them the most range. Essentially, legos.
  • This approach was too focused on layout and the end result was that each of the sites felt too similar. Critical content and focus differences were missing. The end result did not not allow Vox to tell better stories faster, as it only defined common modules not ways to solve common user problems.
  • Vox learned they needed to start with something specific in order to develop a flexible system. You can’t start with individual components because successful design patterns don’t exist in a vacuum.
Starting with Purpose
  • The next iteration of Vox's design system started with people and content. What goals did the audience have? What range of content and tone needed to be supported? What was the editorial workflow of the people making content?
  • This requires user-scenarios driving design not hypothetical situations. We need to ground our design systems in tasks people and companies actually have not trying to account for "what if" ideas.
  • Instead of starting with an inventory of UI components, start with an inventory of core workflows/tasks, and then identify common patterns in these workflows. All patterns should solve a specific problem.
  • Identify core workflows and the patterns that need to support these workflows. Understand the role each pattern plays in a user’s journey. Define how the patterns work together to create a cohesive experience.
  • Thinking and organizing a design system in terms of workflows, makes it easier for teams to know which patterns to apply when faced with a user problem.
  • At Vox, a scenario-based design system allowed the team to turn 18 distinct templates into a unified structure. They identified common audience goals but supported variants driven by differences in content.
Supporting Variants
  • Variants can help components address specific user-scenarios by highlighting specific content that matters to audience goals. These content-specific components can be re-used across themes/brands.
  • Scenario-driven variations can help brands feel unique/deliberate vs. becoming too generic/unspecific.
  • Naming elements very specifically helps people agree on their function. This ensures each element supports the right level of customization & functionality.
  • How do we theme a design system? Brands need to support distinct visual designs that support the unique audience and content within a site.
  • When varying fonts across brands, you need a flexible type scale to ensure legibility across different font faces. Similarly, color variables can be used to manage different colors schemes across brands.
  • When should you support variations in your design system? Only add a layout if there’s a content need. Does it add value? Is it available to more than 3 brands? Is it a must-have for 1 brand?
  • When are variations in your design system a bad thing? Visual variation on components that serve the same function across brands and/or don’t do much to strengthen brand voice.
Finding a Balance
  • There's a constant push/pull between appropriate levels of consistency and customization. Finding the right middle ground is a constant process of iteration.
  • Successful design patterns don't exist in a vacuum. Instead of focusing on individual components, look at the ecosystem: the people, content, and complete design. Successful design systems solve specific problems and start with people & content.

Changing Time Spent

Wed, 01/31/2018 - 2:00pm

Following a few conversations on the future of TV and desktops/laptops, I decided to look into how people's screen time has changed. To do so I compiled data from a few different sources going back several years on adults (18+) in the United States.

While the rise of time spent on mobile is dramatic, the effect is mostly additive. That is, it created more screen time in the United States than it took from other media like TV and radio.

Looking at another data source, in this case Nielsen's Total Audience Report over the past four years, seems to tell the same story.

That said, it does appear activities like listening to radio and video viewing are gradually transitioning to mobile devices over time (with the vast majority on smartphones).

Which makes sense when you consider adults in the US are spending about 3 hours a day on their mobile devices.

The Increasing Size of Smartphones

Wed, 01/17/2018 - 2:00pm

Two years ago, I pulled together a look at the most common mobile device form factors and how people were using them (portrait, landscape, etc.). At that time, 67% of mobile devices had 4"-5.5"screens. Since then things have changed significantly.

Over the course of just three years, active smartphones with 5.5" to 6" screens grew from 7.5% to 43% according to Scientia Mobile's panel of mobile Web browsing activity.

And in 2017, 5-7" smartphones became the majority of native mobile app use in Flurry's sampling. That's some "big" changes as larger screen sizes not only impact design but time spent on devices as well:

  1. Designing for Large Screen Smartphones
  2. As Mobile Screen Size Increases... So Does Activity

Apple.com's Visual Hierarchy

Tue, 01/16/2018 - 2:00pm

Recently, I dusted off my full day workshop on visual communication for a room full of product managers. While discussing the role of visual hierarchy in screen layouts, I was struck by how many people were impressed at the consistency Apple.com (one of my examples) showed over the years.

Over the past 17 years, Apple.com's visual style had changed through the application of new fonts, colors, and textures but its underlying layout (or its visual organization) had not.

Looking even further back, Apple.com has retained the same layout structure (primary promotion, 4 secondary promotions, global navigation, and footer navigation) for over twenty years. I guess if your visual hierarchy ain't broke... don't fix it.

©2003 - Present Akamai Design & Development.