Subscribe: Functioning Form: Interface Design
Added By: Feedage Forager Feedage Grade A rated
Language: English
app  conversions  design  google  load  make  mobile  notes talk  people  pwas  seconds  sign  site  time  web  years 
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: Thu, 01 Feb 2018 00:00:00 +0000

Last Build Date: Thu, 01 Feb 2018 00:00:00 +0000

Copyright: LukeW Ideation + Design

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? AMP to PWA paths. If you are using Google's accelerated mobile pages, you may want a path from AMP pages to a more full-featured PWA. [...]

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.

Conversions: Optimizing Mobile Landing Pages

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

In his Driving mobile success by optimizing landing pages presentation at Google Conversions 2017 in Dublin Ireland, Martin Wagner talked about the journey he went through optimizing the site for performance over the past two years. Here's my notes from his talk:

  • Most people believe good pagespeed score results in a good loading time and if you improve the score once, that's enough. The reality is quite different.
  • When the site moved to a responsive Web site, pagespeed scores initially went up (that's good) but load times went down. After fixing a few issues, however, the average page load was improved over the old desktop site.
  • On the separate mobile site, however, performance problems with third party libraries and images were an issue. Mobile was the last platform that was moved to the responsive Web site.
  • After launch, the responsive mobile Web experience page download doubled because more functionality was added so page load savings had to be found elsewhere. One quick win was Javascript and CSS refactoring that to reduced 130kb in one day.
  • Performance budgets were very helpful to define a load time on a specific network in order to set the right size targets for the site's components.
  • DOM elements (fly-outs and product sliders) that weren't needed on mobile were removed until until they were needed. This resulted in 800 and 900 less DOM elements. This improved loading performance by a full second on mobile. Image lazy loading techniques like this are quite useful but saving asset sizes affects only the first hit.
  • By enabling compression, making use of browser cache, optimizing images, and prioritizing visible content pagespeed scores increased.
  • Prioritizing visible content (the first area of your website the customer sees without scrolling) with inline CSS and JS took the longest to implement but made a big impact.
  • In previous version of Web site, the page started to render at 4 seconds. With prioritizing above the fold content, content loads at 2 seconds and completes .5 seconds earlier. This resulted in a 4% conversion increase for mobile visitors.
  • A process for managing images can help resize and optimize them automatically. This takes a long time manually.
  • Performance improvements are an ongoing process. You can't just increase your page speed score and assume you are done. Keep tracking/watching your efforts. google provides a useful API for this.
  • Likely you have a lot of low-hanging fruit, start with those first.

Igniter: Why Startups Suck at Marketing

Sun, 29 Oct 2017 00:00:00 +0000

At the Igniter Annual Conference in Mountain View, Rand Fishkin shared eight common mistakes startups make with their marketing/growth hacking and how to avoid them. Here's my notes from his talk: Why Startups Suck at Marketing Most startups fail because they couldn’t find the right customers at an affordable price. But what specific mistakes do they make with marketing that could be avoided? Terrible Name Problems with names: no one can say your name (hard to pronounce), you don’t own domains or social handles, your name is used by other companies (esp. in your domain), etc. Make your names easy to spell, say & remember, has no existing associations that could confuse, avoids trademark infringement, what the company does has no problematic overlaps, the .com and social media accounts are owned by you, has few or no Google search results, biases toward brand able. Overvaluing First Exposure Typical startup myths: make a great product, get some press, get customers. But where people do to learn is from online lists, talking to others, using existing solutions, etc. If you only play at first exposure and/or decision time, it won’t work well. Step 1: get known and trusted by your audience. Step 2: grow a presence across the channels they use to find solutions for what your product does. Step 3: be visible throughout their discovery, consideration, and decision processes. Chasing Growth Hacks Don’t fight the “law of shitty clickthrough rates”. Chasing growth hacks usually leads to death before success. A lot of exploitable short-term growth hacks start out working ok, then cease performing. Great marketers focus on flywheels: systems that scale with decreasing friction. Most flywheels start out working poorly, but keep iterating and you’ll learn how to close the gaps. Different types of flywheels: content, press & media, UGC/community. Almost every flywheel finds points of conflict or friction. That’s where it is useful to apply a growth hack. Hacks are useful when applied to a sound marketing strategy. As such, find a balance between long-term investments and short-term hacks. The formula for marketing that will work for years to come: strategic roadmap + scalable flywheel + long-term investments + hacks to remove friction (in the flywheel). Saving Marketing Until Launch Seek out marketing channels & tactics at the intersection of: areas of personal passion & interest, areas where you can provide unique value to your audience, and areas the reach your potential customers and their influencers. Think about what marketing channels fits this criteria: blogs, forums, social media, video channels, events, etc. Invest in 2-3 tactics long before you launch a product. So when you do, there’s a pre-existing community that wants to support & amplify you. Relying on Paid Ads Unknown brands with poor click-throughs (because they are new) have to pay more for ads to be effective. Ad networks want good click-throughs so their users get good experiences. First earn brand exposure with your target audience, get organic traffic first, then advertise to those who know and like you. Not Prioritizing an Easy-to-Reach Audience Easier to harder to reach audiences: are people you know, know of you, are connected to you on email, social media, your website, have heard of your company, are reachable via ad targeting. Have a strategy to increase the size of your easier to reach audience, target them first, and not aim 100% of his tactics at hard to reach groups. Pro tip: having a lot of target customers in your personal network makes everything about starting up easier. Failing at Funnels Most sites & marketers are focused on optimizing conversations but startups o[...]

Chrome Summit: New Bar for Web Experiences

Mon, 23 Oct 2017 00:00:00 +0000

At the Chrome Dev Summit in San Francisco, Thao Tran and Chris Wilson discussed the user experience benefits made possible by new Web technologies with a number of case studies. Here's my notes from their talk: The new bar for web experiences New modern Web technologies provide an unparalleled opportunity to raise the user experience bar for Web sites/apps. It's not enough to just provide a useful service, you also have to deliver a great experience. This is what people expect now online. The Web is great for reach, but now it needs to get better at delivering richness. Progressive Web Apps (PWAs) are really just a higher bar for user experiences. They are not really a new type of app but a way to drive significant UX improvements on the Web. Pillars of PWAs Fast, Integrated, Reliable, and Engaging. Fast User expect fast loading, instant applications. After 3 seconds of waiting for a Web page to load on the desktop, 53% of people will abandon the site. The average mobile Web page takes an average of 19 seconds to load on 3G. 60% of worldwide mobile connections are still on 2G networks. is the biggest food ordering service in China. They serve 260 million users, 1.3 million restaurants, and 99% of their orders happen on mobile. Their Progressive Web App was designed to work especially well in flaky network conditions. They get skeleton screens up in 400ms and fully interactive in 2seconds. Fast loading pages is the key goal of AMP pages. After 2 years, there are over 4 billion AMP pages on over 25 million domains. has built interactive AMP pages for their product search and browse. They are seeing an 8% increase in conversion and 36% increase in revenue. used AMP to achieve first meaningful paint in under 3 seconds using a single responsive code base. Integrated Experiences built on the Web should feel just as responsive and natural as those built on other platforms. People expect apps to launch from home screen, have access to hardware, preserve identity, play media, etc. Jio media used the Media API (in their PWA) to integrate media controls and enable offline listening. They are seeing 10% longer average session times then on their native apps. Mercado Libre uses Web push notifications to allow buyers to get replies from sellers. Their prompt dialog has a 41% opt-in rate for their Web Push notifications. PetLove uses the one-tap sign-in API to get 2x more users to go to checkout signed in. They got 2.8x increase in conversions; 2.7x increase in time spent; and a 8x smaller size site then their native app. Starbucks PWA uses auto-sign and provides an offline payment barcode (20% pay with bar code in store) using Service Workers. A typical Web checkout experience in 7-8 steps on mobile. Swim Outlet's took 2min+ to finish. They implemented Payment Request and saw 80% reduction in checkout times. Web sites typically don't get access to powerful APIs without asking for permission. As a result, people end up seeing a lot of permission dialogs. In Chrome for Android, 90% of the time people dismiss or ignore permission dialogs. After 3 times, Chrome blocks this permission request for a week. Starting in Chrome 63, these requests will be modal and force people to decide. Which should reduce the number of dialogs people see. Without context, sites get 40% less permission grants then those that explain why they are asking. Reliable People expect their apps to work with a network connection or not. Unfortunately mobile sites are often in an online/offline state due to network issues. Uber used a Progressive Web App for global access especially on low end devices. It is 50kb (for the core a[...]

What Would Augment Reality? (1-10)

Mon, 07 Aug 2017 00:00:00 +0000

As the technology industry buzzes about Augmented Reality (AR) applications and hardware, I thought it would be worthwhile to apply Scott Jenson's value > pain theorem to AR gear. That is, "what value would exceed the pain of charging and wearing augmented reality headsets each day?" Are there enough compelling use cases to make AR a daily necessity? To try and answer this question, I drafted a series of illustrations on "what would augment reality?". For each illustration I assumed audio input control and gaze path/eye-tracking for object identification. Due to these assumptions, I specifically tried to apply a principle of maximum information yet minimum obstruction (MIMO) to the user interface design. My high-level goal, however, was to literally "augment" reality. That is, to give people abilities they wouldn't otherwise have through the inclusion of digital information and actions in the physical world. Here's my first ten attempts. So does the value of these use cases outweigh the pain of wearing and charging an Augmented Reality headset each day? ...[...]

Video: Mobile in The Future

Thu, 27 Apr 2017 00:00:00 +0000

For the past five years, I've presented an overview of the mobile design topics, insights, and solutions I've been focused on at Google's Conversions event in Dublin. This year's video recording on what's changed in mobile design over the past ten years and where we could/should go next is now live.

While the complete video runs almost three hours, in the first ninety minutes I walk through how we've learned to optimize key flows on mobile over the past ten years and how we can continue to improve with inspiration from natural user interfaces and hardware design. 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>

All Annual Sessions:

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