Subscribe: Functioning Form: Interface Design
Added By: Feedage Forager Feedage Grade A rated
Language: English
content  design  don  load  make  mobile  notes talk  people  pwas  site  sites  system  time  web sites  web  work 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Functioning Form: Interface Design

LukeW | Digital Product Design + Strategy

Expert articles about user experience, mobile, Web applications, usability, interaction design and visual design.

Published: Tue, 03 Apr 2018 00:00:00 +0000

Last Build Date: Tue, 03 Apr 2018 00:00:00 +0000

Copyright: LukeW Ideation + Design

An Event Apart: The Way of the Web

Tue, 03 Apr 2018 00:00:00 +0000

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

Tue, 03 Apr 2018 00:00:00 +0000

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

Tue, 03 Apr 2018 00:00:00 +0000

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 sou[...]

An Event Apart: Content Performance Quotient

Mon, 02 Apr 2018 00:00:00 +0000

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

Mon, 02 Apr 2018 00:00:00 +0000

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 [...]

Changing Time Spent

Thu, 01 Feb 2018 00:00:00 +0000

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

Thu, 18 Jan 2018 00:00:00 +0000

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's Visual Hierarchy

Wed, 17 Jan 2018 00:00:00 +0000

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 (one of my examples) showed over the years.


Over the past 17 years,'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, 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.

An Event Apart: Prototyping The Scientific Method of Business

Tue, 12 Dec 2017 00:00:00 +0000

In his Prototyping: The Scientific Method of Business presentation at An Event Apart in Denver, Daniel Burka described how to use different forms of prototyping to create value for businesses based on his work with Google Ventures. Here's my notes from his talk:

  • When you ask CEOs, heads of product, etc. "what keeps you up at night?" you hear very different answers than what companies perceive as design issues. This is a big concern: how can designers work on key issues within a company instead of on the side on non-critical design tasks.
  • Design done right can be the scientific method for business. People within a company have lots of ideas and often talk past each other. Designers can take these ideas, give them shape as prototypes, and allow the company to learn from them.
  • The best thing you can learn as a designer is how to be wrong faster. Instead of building just one idea (that a group aligns on), test a number of ideas quickly especially the crazier ones.
  • Use design to recreate the benefits of a lab so you can be effective faster. Lightweight techniques can be built up to create a more robust process.

Basement Lab

  • You don't need anyone other than yourself to make something appear real really quickly. Take the inkling of an idea and turn it into a rough prototype as quickly as possible. If a picture is worth a thousand words, a prototype is worth a thousand meetings.
  • As a designer, you can make someone’s idea look very very real in a very short amount of time.
  • A prototype is the start of a conversation. They should "feel" like the real thing but be bad enough that you're willing to throw them away.

Highschool Lab

  • The next level of using design is testing business hypotheses on realistic customers. This is the secret weapon for companies as it helps them set direction and “see around corners.”
  • Measure twice before you decide to build something. Talk to your target users, run them through a prototype (like the one made in basement lab) to get an accurate measurement.

Industrial Grade Lab

  • Gather the right team: the prototype gets made by a group and then tested with actual customers.
  • For this, you can run design sprints to make progress. The first step in a design sprint is to gather a team (designers, customer service reps, engineers, product leaders, and more). Test hypothesis that are high risk and high reward.
  • Create time pressure: condense a sprint to one week and schedule customer interviews for Friday to keep things moving.
  • Recruit the right people so your feedback comes from your target audience. A short screener form will help you ensure the right people come to your tests.
  • Focus the sprint on the big risk issues.
  • Sketch out ideas individually. Don't do group brainstorms: they don't allow you articulate ideas in depth and get often dominated by the loudest voice. Don't do group voting, let people evaluate concepts on their own through weighted voting. CEOs and heads of product also get super votes to mirror the real organization.
  • Run quick, credible research: when testing with actual customers, look for patterns of behavior. You need 3-4 instances.
  • It is ok to fail when doing design sprints. You learn what not to build and save money as a result.

An Event Apart: The Case for Progressive Web Apps

Tue, 12 Dec 2017 00:00:00 +0000

In his The Case for Progressive Web Apps presentation at An Event Apart in Denver, Jason Grigsby walked through the benefits of building Progressive Web Apps for your Web experiences and how to go about it. Here's my notes from his talk: Progressive Web Apps (PWAs) are getting a lot of attention but we're still really early in their development. So what matters today and why? A PWA is a set of technologies designed to make faster, more capable Web sites. They load fast, are available online, are secure, can be accessed from your home screen, have push notifications, and more. Companies using PWAs include Flipkart, Twitter (75% increase in tweets, 65% decrease in bounce rates), and many more. Are PWAs any different than well-built Web sites? Not really, but the term helps get people excited and build toward best practices on the Web. Web browsers are providing incentives for building PWAs by prompting users to add PWAs to their home screen. These "add to home screen" banners convert 5-6x better than native app install banners. In Android, PWAs show up in the doc, settings and other places. Microsoft is putting PWAs within their app store. Search results may also start highlighting PWAs. Why Progressive Web Apps? Not every customer will have your native app installed. A better Web experience will help you reach people who don't. Getting people to install and keep using native apps is difficult. App stores can also change their policies and interfaces which could negatively impact your native app. You should encrypt your Web sites. Web browsers won't give you access to new features like http2, and location detection if you don't. You should make your Web site fast. PWAs can have a big impact on performance and loading times. Your Web site would benefit from offline support. Service Workers are a technology that enables you to cache assets on your device to load PWAs quickly and to decide what should be available offline. Push notifications can help you increase engagement. You can send notifications via a Web browser using PWAs. You can make a text file that creates a manifest file for your site. That's the last step to create a PWA. It takes just 30 minutes so why not? Early returns on PWAS are great: increases in conversion, mobile traffic, and faster performance. PWA stats keeps tracks of these increases. But iOS doesn't support PWAs. No, PWAs work fine on iOS. They just progressively make use of technologies as they are available. Organizations using PWAs are already seeing iOS increases. PWAs are often trojan horses for performance. They help enforce fast experiences. How to Build PWAs? Early on Web sites attempted to copy native app conventions but now are developing their own look and feel. So what should we use for PWAs? Native app styles or Web styles? How much does your design match the platform? You can set up PWAs to use different system fonts for iOS and Android, should you? For now, we should define our own design and be consistent across different OSs. What impact does going "chrome-less" have on our PWAs? You loose back buttons, menu controls, system controls. Browsers provide us with a lot of useful features and adding them back is difficult. So in most cases, you should avoid going full screen. Should you app shell or not? The shell is the chrome around your content and can be loaded from the cache instantly. This makes the first loading experience feel a lot faster. What part of your site should be a PWA? In some cases it is obvious, like subdomains at Yahoo! In other cases, it is not so clear. You may want to make "tear away" parts of your site to exist as a PWAs. Really great PWAs will get some of these details right. For instance, cache for performance and offline fallback? Cache recently viewed content for offline use?[...]

Video: Mobile in The Future

Thu, 16 Nov 2017 00:00:00 +0000

Last week at Google's Conversions event in Dublin, I walked through the past ten years of mobile design and what the future could/should look like including an extensive Q&A session. Videos from both these sessions (totaling 3 hours) can now be viewed online.

In the first session (90min), I take a look at what we've learned over the past ten years of designing for the largest, most connected form of mass media on our planet. Have all the mock-ups, meetings, emails, and more we've created in the last decade moved us beyond desktop computing interfaces and ideas? If not, can we find inspiration to go further from looking at what's happening in natural user interfaces and hardware design?

class="videoplayer" src="" frameborder="0" allowfullscreen>

The second ninety minutes are dedicated to Q&A on common mobile design and development issues, what's next in tech, and more.

class="videoplayer" src="" frameborder="0" allowfullscreen>

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

Conversions: Faster mSites = More Revenue

Thu, 09 Nov 2017 00:00:00 +0000

In her Faster mSites = More Revenue presentation at Google Conversions 2017 in Dublin Ireland, Eimear McCurry talked through the importance of mobile performance and a number of techniques to improve mobile loading times. Here's my notes from her talk:

  • The average time it takes for a US mobile retail Web site to load is 7 seconds but 46% of people say what they dislike the most about the Web on mobile is waiting for pages to load.
  • More than half of most site's new users are coming from mobile devices so to deliver a great first impression, we need to improve mobile performance.
  • Desktop conversion is about 2.5%. At 2.4 second loading times, conversion rates on mobile peek at about 2%, as load times increase it drops. Slowing down load time to 3.3 seconds results in the conversion rate dropping to 1.5%. At 4.2 seconds the conversion rate drops below 1%. By 6 seconds, the rate plateaus.
  • As load times go up, more users will abandon your site. Going from 1s to 3s increases the probability of bouncing by 32%. Going from 1s to 5s increases the probability by 90%.
  • Page rank (in search) and Ad rank (for ads) both use loading time as factor in ranking.
  • Your target for latency is one second but 1-2 seconds to load a mobile site is a good time. 3-6 seconds is average but try to improve it.

Improving Mobile Performance

  • AMP (Accelerated mobile pages) is a framework for developing mobile Web pages that optimizes for speed. It stores objects in the cache instead of needing to go back to the server to collect them.
  • Example: Greenweez improved mobile conversion rates 80% and increased mobile page speed 5x when moving to AMP.
  • Prioritize loading information in the portion of the webpage that is visible without scrolling.
  • Optimize your images: on average the majority of load size of web pages is images. Reduce the number of images on your site, make compression part of your workflow, use lazy loading, and avoid downloading images you are hiding or shrinking.
  • Enable GZIP to compress the size your the files you send. Minify your code to remove extraneous characters/file size. Refactor your code if you need to.
  • Reduce requests to your server to fewer than 50 because each request can be another round trip on the mobile network with a 600ms delay each time.
  • Reduce redirects: if you can get rid of them, do. In most cases redirects make it hard to hit load times under 3 seconds and aren't needed.

Conversions: Living a Testing Culture

Thu, 09 Nov 2017 00:00:00 +0000

In his Living a Testing Culture presentation at Google Conversions 2017 in Dublin Ireland, Max van der Heijden talked about the A/B testing culture at and lessons he learned working within it. Here's my notes from his talk:

  • books 1.5 million room nights per day. That's a lot of opportunity to learn and optimize. More than 40% of all sales happen on mobile
  • A/B tests everything. If something cannot be A/B tested, won't do it. There's more than 1,000 A/B tests running at any time.
  • Teams are made for testing a hypothesis. They're assembled based on what resources they need to vet a hypothesis. They are autonomous, small, multi-disciplinary (designers, developers, product owners, copyrighters, etc.) and have 100% access to as much data as possible.
  •'s experiment tool allows everyone to see all current experiments to avoid overlaps and conflicts between testing.
  • Predicting customer behavior is hard. Teams at adapt often. As a result, teams often dissolve, spin up, and shift around.
  • Failure is OK. Most of your learnings come from tests that don't work. 9/10 tests at fail.
  • Everyone needs to to live the testing culture. Ideas can come from anywhere and go all of them go through the same testing process. Everyone is part of this.
  • Data only tells you what is happening. User research tells you why. These two efforts work together to define what experiments to run next and then test them.
  • What worked before might not work now. Always challenge your assumptions.
  • Make sure you can trust your data and tools. has a horizontal team dedicated to improving its experiment tool on a regular basis.
  • You can innovate through small steps.
  • Delighting customers doesn't necessarily mean more profit. Short term gains may not align with long term value. You'll need to find a balance.
  • Go where the customers(tests) take you.

Conversions: The Psychology behind Evidence-Based Growth

Thu, 09 Nov 2017 00:00:00 +0000

In his The Psychology behind Evidence-Based Growth presentation at Google Conversions 2017 in Dublin Ireland, Bart Schutz shared how to think about applying psychology principles to influence customer behaviors. Here's my notes from his talk:

  • What truly drives and influences homo sapiens?
  • People are never one thing, we have two systems in each of us. System two is your consciousness, the self. System one is automatic and controls your intuition and your unconscious actions. System two has memory, can think logically, and make predictions of future outcomes. System one can't.
  • Our system two brain tries to automate as much as possible, so it can focus more energy on new situations. As a result, we often give automated answers, without thinking about them.
  • Accept that you don't know why people do what they do. Your brain only understands things consciously so a lot of time is spent talking. Instead, use that time to run experiments.
  • Make it fast and cheap to run experiments. This is step one. To convince others, rethink experimentation as regret instead of gain. Consider what what you would have lost if you would not have run the experiments. Loses are powerful motivators.
  • Once you are running a lot of experiments, adding more is no longer as valuable. You need to increase the value of each experiment you run. This is where you can apply more psychological insights.
  • Different experiments work to influence human behavior depending on which systems are in "control".
  • When people are only system two driven: they are in conscious control and know what they want. This is goal-directed behavior. In these cases influencing behavior is all about ability and motivation. Make things very easy and keep people moving toward their goal.
  • With complex decisions, people are often better off using system one since they can't consider all the options at once. In influence behavior in these cases we distract you with information overload, to make your unconscious behavior take over and make choices for you. Like in the case of picking a hotel room from thousands of variants.
  • Only system one driven: when people are distracted and not goal orientated, make use of heuristics and habits to influence behavior.
  • When people are not goal driven but you want them to think rationally, you should apply triggers and forced choices.
  • Behavior is difficult to influence not because we differ because of personal factors like nature and nurture. That's what most people think but these have much less impact than situational factors like context, emotions, and environment.
  • Get the data right, start experimenting, and get your skills up. Only then does it make sense to add psychology to drive new insights.

Conversions: Checkout for Winners

Thu, 09 Nov 2017 00:00:00 +0000

In his Checkout for Winners presentation at Google Conversions 2017 in Dublin Ireland, Andrey Lipattsev talked through two new APIs for improving sign-in/sign-up and checkout on the Web. Here's my notes from his talk:

  • The Web is better than ever before. You can build fast, rich, app-like experiences but many companies opt to route people to native experiences instead of optimizing the Web experiences. That needs ot change.
  • On mobile, 54% of people quit checkout if they are asked to sign-up. 92% will give up if they don't remember a password or user name.
  • Google has been working on two Web APIs for seamless sign-up/sign-in and payments on the Web.
  • One tap sign-up is a streamlined conversion experience that works across all browsers to instantly sign people in for personalization and passwordless account security.
  • One tap sign-in helps websites with short session duration and provides cross device access as well.
  • Example: 10x more sign-ups/accounts created on Wego (a travel site) since implementing One tap sign-up
  • AliExpress had a 41% higher sign-in rate, 85% fewer sign-in failures, and 11% better conversion rate when they added One tap.
  • The Guardian gained 44% more cross-platform signed-in users with One tap.
  • We still buy things online by filling in Web forms. This introduces a lot of friction at a critical point.
  • The PaymentRequest API is a standard that enables you to collect payment information with minimal effort. This is not a payment processor. It is simply an API to collect payment information with two taps.
  • The PaymentRequest API works across Web browsers (Chrome, Edge, Samsung and soon FireFox) and platforms, including AMP pages (built in support).
  • Early partners include support for Square, Samsung Pay, and AliPay. Support for PayPal is in the works.
  • 2-5minutes is the average for checkout times on the Web. The PaymentRequest API reduces this effort to 30seconds.
  • Up to 80% of checkouts only include one item.