Speaking Product

Just about everyone in the product and design world has had experiences where they've had to work on product ideas with people whose communication styles and ways of approaching ideation didn't quite align. For lack of a better phrase, these people don't speak product, and product ideation with them winds up being a frustrating experience.

This post is about defining roughly what speaking product means, and what you can do with people who don't. It's inspired by experiences I've had over the years of working with all different types of people on product concepts - from journalists to therapists, doctors, engineers, educators, and more.

What "Speaking Product" Means

I've noticed two patterns for people who don't speak product - they're either too abstract or too concrete.

To speak product is really to be able to understand and navigate the balance between the abstract and the concrete when discussing new concepts, knowing when to zoom in and when to zoom out, and finding the right level of detail for the problem at hand.

Ideation goes fastest at 10k-30k elevation. Too close to ground and things come crashing to a halt, stuck navigating the small hills and valleys of details. Too high up and you run out of oxygen or get sucked into space.

People who are too Abstract

Some people can only speak in abstract terms when discussing product. These are often CEOs or leaders who are too disconnected from specifics and too unskilled in product or design to make meaningful progress in product discussions. These people can see connections between disparate things, some of which may make sense if properly thought out, others of which make absolutely no sense. They tend to think their ideas are much more concrete than they are, and latch onto the emotion of 'this is going to be great' without sufficient detail for that to be an informed conclusion.

The way to work with these people is to get them to agree on examples and use cases and general goals. You may also need to tell them that the idea was theirs as you go about defining the product, especially if there's a power dynamic.

People who are too Concrete

Some people can only speak in concrete, linear terms when discussing product. These are often subject matter experts, engineers, etc. They are diligent people who want to provide the right answer, but who lack the imagination or abstract reasoning abilities to make meaningful progress in product discussions. These people need product ideas to be explained to them in torturous detail, describing a very tightly defined circumstance in which the product is used, or walking through each step of what the product may do. They tend to latch on to disproving the premise of the imagined product with (often irrelevant) edge cases and details, rather than seeing the general thrust of what the ideated product is trying to do and whether it makes sense.

The way to work with these people is to keep reinforcing the general goal and purpose of the product, to keep them focused on the bigger picture. When necessary, get feedback only in specific circumstances to reality check your ideas, but otherwise keep these people away from ideation sessions.

Learning to speak product

In some circumstances for expediency's sake it may be best to just avoid working with those people on product, but I remain open to the idea that finding the right balance of abstract and concrete thinking is a skill that must be learned. Something I've learned is to be patient in people's journeys to learning how to speak product. Several times people who I didn't think would be able to adapt have been able to, with sufficient exposure, become productive members of ideation session.

The Beauty of MacOS System Preferences

Summarizing a tweetstorm from 10/8/2019

MacOS System Preferences is one of Apple's best and least appreciated designs. Prefs are a difficult design challenge, because doing them well means making a lot of hard choices about what you let users configure, and what you don't.

OS Preferences encompass all the ways users are going to use the OS. They're a collection of meaningful use/edge cases that make sense to support, each of which may expose many possible options, and each of which is likely to have 10-100k users who absolutely rely on it.

Designing system preferences is an exploration on the frontier of simplicity and flexibility. Too simple and it's rigid and leaves people behind, too configurable and the user is overwhelmed. It requires really deeply understanding users & use cases to find the right balance.

Much like how you should judge a society based on how it treats it's least well off, I think you can judge an OS by how it treats it's least desirable user experience: that of messing with the bowels of the OS to get it to do the thing you want it to do.

MacOS System Preferences, born in the golden age of OSX (10.4+) prior to iPhone, have all sorts of touches that go above and beyond to make this experience really compelling. In no particular order, here's a few:

In search, there's a custom UI that not only highlights options in the UI as you type in keywords that match, when you press enter it also blinks the option selected and bring you to it. This teaches you how to get back.

In each preference pane, there are only a few options presented at any one time, making it easier to digest. The options are also in a hierarchy with the most important ones as larger, sometimes custom, widgets. This energy saver pane is super economical with options & text.

Image

You can also rely on preference panes to provide great, specific visuals that leave little room for misinterpretation. This trackpad pane is way beyond just setting an option, it's teaching you how to use the very system you're on.

Finally, how the preferences are visually grouped together is just wonderful. Each line of 8 icons is a set of preferences that conceptually relate. This makes skimming super easy, since your eyes are drawn to skim across each line rather than see a jumble of icons.

Image

Fast forward to today, and MacOS Catalina has just updated System Preferences. It's new visual grouping to slowly bring it in line with iOS. Now there's two bundles of 16 preferences, each spanning two lines, but unfortunately with a bit less conceptual relationship.

Image

I'm honestly a bit disappointed in the change since the visual grouping I feel really worked well. But as often is the case, optimizing happens at different levels - MacOS is part of a broader Apple ecosystem, where iOS dominates and MacOS must stay consistent.

Regardless, I think the best way to appreciate System Preferences is to compare it to Settings / Control Panel on Windows which has never struck the right balance of simplicity, specificity, graphics, and grouping in information architecture and seems to change with each version.

Image

In Settings, rather than do one thing, each top level option contains within multiple options, effectively setting up a 3-level hierarchy. This has the knock-on effect of forcing the user to parse a lot of text, and makes the icons (distant) secondary rather than primary cues.

Additionally, as consistent as the basic UI elements are, they're also exceptionally bland and provide few visual cues or opportunities for direct manipulation that might help users figure out what they're doing. You may as well be filing your taxes in this UI.

Finally, Windows 10's settings are only skin deep, as many older options lay beneath in an entirely different UI. Ironically, this older UI isn't nearly as antiseptic as the new design.

In Windows, you can tell there just isn't the same attention to detail. Settings are an afterthought, they're the crappy plywood on the back of the chest of drawers. Meanwhile, System Preferences shows Steve Jobs' ethos of crafting the whole thing to a high standard front to back.

Minecraft Earth should be the first AR Killer App

Summarizing a tweetstorm from 5/17/2019

I'm legit excited about Minecraft Earth and I think it is a killer app for consumer augmented reality (AR) hardware. It feels like it's going to be the first mainstream AR lens that has a chance at serious staying power, as it has great mindshare, is creative and social, and gives power to community (vs hardcoded pokestops). Microsoft has also been a great steward for the Minecraft brand and isn't likely to make amateur mistakes on it.

Unfortunately, Microsoft's HoloLens strategy is not aligned with Minecraft Earth right now. It's about pushing tech to max field of view + resolution which adds serious bulk and expense, and it's aimed primarily at the corporate and developer communities.

Consumer AR hardware is in a weird spot, as I think Google has the right hardware approach (Google Glass size/cost) with the wrong software (nothing of note), and Microsoft has the right software approach (Minecraft) with the wrong hardware approach (HoloLens size/cost). This is symptomatic of there not being a mainstream killer app yet for AR.

The situation is understandable. When building hardware sans killer app, you kind of get stuck with serving many (hypothetical) masters, as you imagine many use cases that in reality are years away from being addressable. This is sort of the HoloLens situation - bulky hardware attempting "general AR".

Meanwhile, with a killer app you gain exceptional focus - you only need to do the minimum to enable that app. For example, the original Apple Watch killer app was notifications (and maybe heartrate). That's about it, it was otherwise super slow and pointless. But that was enough.

In AR/VR, "immersion" is the default goal sans a killer app, and field of view (FOV) is what delivers that. But big FOV = big hardware. With a killer app like Minecraft though, people will want anything that delivers the AR experience, even if the hardware specs aren't cutting edge.

With the launch of Minecraft Earth, there's now an opportunity to create a small $199 purpose-built, no-input headset with postage stamp FOV and Minecraft. I think this should be Microsoft's next move.

Minecraft Earth is something that would get kids to wear a cheap headset around on the daily just to be connected to what their peers are doing. The network effects on this are strong as physical space gets built out and community forms around it. We've seen a hint of this from Pokemon Go, which is just a game and completely lacks the creation that makes social networks so compelling.

For kids without the means to get the headset, they can still use their smartphones to access Minecraft Earth. This means the addressable market remains large enough to benefit from network effects, something that new hardware rarely has (this is a variant of the "cold start" problem, often seen with new video game consoles).

No tweetstorm about AR is complete without mentioning input. A $199 device in 2019-20 would purely be discovery-oriented, letting you see what's happening in world without pulling out a smartphone. Basically notifications for place-based content (see the parallels to Apple Watch?)

But, just like Apple Watch with notifications, an always-on cheap AR headset is great for discovering content in Minecraft Earth - much better than the smartphone that's in your pocket. And just like Apple Watch's tethering to iPhone, when you come across content in Minecraft Earth that you want to interact with or create, you just pull out your smartphone!

Over time, input tasks will at least partially move over to the AR headset. As I mentioned in my last AR tweetstorm, gaze tracking with standardized input patterns is the long term solution. But with Minecraft Earth as a killer app, a read-only version 1 is probably good enough. Here's to hoping Microsoft sees this as an opportunity.

Dark Mode for Coda

At some point I'm going to post my thoughts on Coda, but lets just say that I quite enjoy it as a tool to make projects with a lot of interconnections and sections manageable in a way that Google Docs, markdown editors, and other tools just cannot.

Continuing my interest in all things dark mode, one annoyance right now is that Coda doesn't seem to support themes, and presents only the standard white background layout. This is pretty jarring when authoring content at night, but because Coda is web-based, this is just a style edit away from a fix. Using the open source extension Stylebot, I've made a set of changes to Coda that darkens most of the basic UI.

Check out the Github Gist here.

Before & after

Lightswitch - adding dark mode compatibility to a website

One of my goals developing this blog was to design it to work with both light and dark color schemes. Having different background colors is very helpful for readability and eyestrain both during the day and night, and follows the ongoing trend of computers adapting to and blending into to their surroundings.

Dark mode was the major user-facing feature in September's release of MacOS Mojave and has been well received, which means other platforms (including iOS) will surely follow. It was only a matter of time before this was brought to the web, and indeed that happened with last week's release of Safari Technology Preview 68, which lets websites specify different styles based on whether the OS is in light mode or dark mode (technically, the prefers-color-scheme media query).

However, there is one issue with just letting OS mode determine a website's color scheme - user preference. Because OS mode doesn't change based on day/night, users are going to set their OS mode once and probably leave just it that way, regardless of time of day. Those users may not always want a website to be light or dark based on their OS, and may wish to override the default.

Lightswitch.js active on this website

My solution is a bit javascript I call Lightswitch that automatically detects the user's OS mode, and also allows the user to override that mode with a button you put on your site. On this blog, the button is the half circle icon in the top right corner, but you may attach the override functionality anywhere on your site -- such as this link. You can also bind it to a keypress, such as L. Try it out.

Here's the code:

/*******************************************************************************
LIGHTSWITCH: A DARK MODE SWITCHER WITH USER OVERRIDE
By Nick Punt 10/26/2018
How to use:
  *  Create two color schemes in CSS under the classes 'light' and 'dark'
  *  Add the class 'light' or 'dark' to your body as your default color scheme
  *  Add button to page with id 'lightswitch', which lets users change/override
  *  Use the class 'flipswitch' for any style changes you want on lightswitch
Logic:
  1. When user hits page for first time, color scheme is based on OS/browser
     (if supported), otherwise it defaults to the body class you added
  2. When user clicks lightswitch to override colors, their preference is stored
  3. When user alters their OS light/dark mode, switch to dark if dark mode,
     and light if light mode
     
Note:
The 'prefers-color-scheme' css support is currently only available in Safari 
Technology Preview 68+. 
*******************************************************************************/

// New prefers-color-scheme media query to detect OS light/dark mode setting
var prefers_light = window.matchMedia('(prefers-color-scheme: light)')
var prefers_dark = window.matchMedia('(prefers-color-scheme: dark)')

// Change to dark and rotate the switch icon
function darkmode() {
  document.body.classList.replace('light', 'dark');
  document.getElementById("nav-light").classList.add("flipswitch");
}

// Change to light and rotate the switch icon
function lightmode() {
  document.body.classList.replace('dark', 'light');
  document.getElementById("nav-light").classList.remove("flipswitch");
}

// Initialization triggers light/dark mode based on prior preference, then OS setting
if(localStorage.getItem("mode")=="dark") {
  darkmode();
} else if(localStorage.getItem("mode")=="light") {
  lightmode();
} else if(prefers_light.matches) {
  lightmode();
} else if(prefers_dark.matches) {
  darkmode();
}

// Fires when user clicks light/dark mode switch in top right
function handleThemeUpdate() {
  if (document.body.classList.contains('light')) {
    darkmode();
    localStorage.setItem("mode", "dark");
  } else {
    lightmode();
    localStorage.setItem("mode", "light");
  }
}

// Runs when OS changes light/dark mode. Changes only if you were on default
// color state (light on light mode, dark on dark mode).
function OSColorChange() {
  if (prefers_light.matches) {
    lightmode();
    localStorage.setItem("mode", "light");
  } else if (prefers_dark.matches) {
    darkmode();
    localStorage.setItem("mode", "dark");
  }
}

// Listeners for when you change OS setting for light/dark mode
prefers_light.addListener(OSColorChange)
prefers_dark.addListener(OSColorChange)

Download on Github

Setting content to light or dark based on the OS mode is a first step to having our computers be truly responsive to our surroundings, but it's not the final word. Ideally, websites and documents would set a color scheme based on environmental factors like time of day and lighting in the room. Javascript isn't the right way to solve these problems though - it's the OS' job to factor these in to provide a consistent experience from UI to apps to content. The best we can do in the meantime is to set up our content with light and dark variants and allow users to set override preferences on this content.