Internet News

Video: Mobile Planet

LukeW - Mon, 05/28/2018 - 2:00pm

For the past six years, I've presented a walkthrough of the latest mobile data and design insights and solutions I've been exploring at Google's Conversions event in Dublin. This year's video recording is now live.

This year's presentation is a data-informed big picture view of our mobile planet, how to design products for it, and why covering on-boarding, performance, touch gestures, and more.

All Annual Sessions:

Big thanks to the Conversions@Google team for making these sessions available to all.

Google Conversions: Highlights

LukeW - Mon, 05/14/2018 - 2:00pm

Across several presentations at Google Conversions in Dublin, several speakers shared insights and best practices for conversion rate optimization. Here's a few highlights:

Confirmation Bias - Michael Aagaard
  • In the 18th century, tobacco smoke was considered very good for your heart and lungs. In particular tobacco enemas were quite popular so much that they were placed along the banks of the river Thames to help drowning victims. This is an example of confirmation bias at work.
  • Confirmation biases is our tendency to accept evidence we agree with at face value and dismiss information we don't agree with unless the evidence is overwhelming. Confirmation biases limits our ability to seek out and uncover the truth.
  • Torturing data: if you torture any data long enough it will confess to anything. High levels of correlation between things don't imply causation. We have to be careful to not see what we want in data.
  • Stopping A/B tests when they show the impact we want is an example of confirmation bias. Instead, let them run for an appropriate amount of time. Over time, tests are likely to show much less effects.
  • How to overcome confirmation bias: accept the fact that you could be wrong, seek out a different perspective. Find people who talk to customers/users. They have a bias toward end users.
  • Don't test your ideas, do detective work to find out what customers need and how they talk about it. Then your A/B test is simply the final test at the end to see if you did your detective work well.
CRO - Lina Hansson
  • Celebrate the discovery of weak spots. Don't take it as failure but instead be happy when you find something that can be improved.
  • The biggest missed opportunity in conversion rate optimization is usability testing. Move away from opinions and instead use user testing to identify issues.
  • A common pain point across retail sites is find-ability: both search and browse. When we move to mobile, many sites remove their top categories list in order to fit on smaller screens. This creates discoverability issues. One of the first things retail sites should test is adding categories visibly on their home page.
  • Value propositions for companies are usually cut for mobile. Instead of removing them, redesign them to make them work on mobile.
  • People can be classified into four behavior types. Methodical people read completely and analyze before making decisions. Humanistic people react strongly to the opinions of others. Competitive people move quickly and expect things to work. Spontaneous people are emotional and fast-paced. You can design experiences that are appropriate for each of these behavior types.
  • The companies that solve checkout on mobile are the ones that will win.
Meaningful Data - Simo Ahava
  • It's quite simple to get a service like Google Analytics set up but how do we use these tools to really understand what we're doing. How can data become meaningful?
  • Tactics (tool expertise) without a strategy (business expertise) are just party tricks and a strategy without tactics is just talk. What brings the two together is agility.
  • Tools must be customized for your organization's needs. We are not trying to optimize metrics but our businesses. Default metrics and reports need to be adjusted to work with your specific needs.
Landing Pages - Anna Potanin
  • Designers want to do their best and create unique interfaces but making things for the Web often requires understanding and using conventions. Only apply a unique visual design after you have followed best practices.
  • 3 things all retail sites should have on their landing and home pages: call to action, value propositions, and visuals.
  • The more prominent you make your search bar, the more searches you get. Why do you want to do this? Conversion rates are usually much higher for people who search

An Event Apart: The Way of the Web

LukeW - 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

LukeW - 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

LukeW - 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

LukeW - 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

LukeW - 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.

Wed, 12/31/1969 - 2:00pm
Syndicate content
©2003 - Present Akamai Design & Development.