Speaking Product

Just about every product creator 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. This is because there's a certain literacy necessary for product ideation. Let's call it speaking product. A few people are naturals at it even if they've never engaged in ideation, but most are not.

This post is about defining roughly what speaking product means, and what you can do with people who lack this literacy. 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

Comfort - First and foremost, speaking product operates on a kind of Goldilock's principle: good discussions exist in a relatively narrow band between the abstract and concrete. Its like flying; ideation goes fastest at 10k-30k elevation. Go lower and you crash into the small hills and valleys of details. Go higher and you run out of oxygen or get sucked into space. You have to be comfortable operating in this weird in-between space, and it's not a place that many people are accustomed to working in, because it's typically not the band where individual contributors do detail work nor where managers direct and manage.

Calibration - Next, to speak product is to be able to navigate the abstract-concrete balance, knowing when to zoom in and when to zoom out, and finding the band to work in for the specific point at hand. Ideas only come to life when the big picture and the details come into alignment, which means moving up and down in this band a lot. When the discussion moves, you need to be flexible enough to follow and calibrate your contributions. If you're in the wrong band, you wind up talking past each other or getting frustrated at not seeing the bigger point or the important detail of a particular contribution.

Connections - Finally, speaking product is about being able to easily tap into your particular perspective and subject matter expertise and draw relevant examples and ideas out that others can connect with. Even if you have the right perspectives in the room, things can go wrong if what concepts you're connecting to are not unique, understandable, or useful. Many an ideation session has gone to waste from irrelevant contributions or those that require excessive explanation for minor progress.

Dealing with abstract types

Some people default to speaking in very abstract terms when discussing product. These are often CEOs or managers who are too disconnected from specifics and unfamiliar with product or design to make meaningful contributions in product discussions. Sometimes they're just sitting in, other times they want to run the show.

What to look out for:

  • Connections made between things which aren't meaningfully related and require many follow-on questions to understand.
  • Downplaying the complexity of ideas, or a mismatch between their perception of how concrete their ideas are versus how others perceive them to be.
  • Frequently latching onto the emotion of 'this is going to be great' without sufficient detail for that to be an informed conclusion.

How to work together successfully:

  • Get them to agree on examples and use cases that ideas can be tested against.
  • Ask them to think about objectives and general goals for the emerging ideas.
  • Link things back to their abstract statements when moments of forward progress occur in session. Especially important if there's a power dynamic.

Dealing with concrete types

Some people default to speaking in very 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 don't engage enough in the types of abstract reasoning that progresses product discussions.

What to look out for:

  • Having to explain product ideas 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 for them to 'see' it.
  • A tendency 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.
  • A tendency to brain dump information in long complicated answers whose facts stray from the point of the exercise when asked simple questions.

How to work together successfully:

  • Keep reinforcing the general goal and purpose of the product, to keep them focused on the bigger picture.
  • Steer they away from particular solutions and just ask general questions like whether something is possible, or complicated, or risky, and maybe questions like roughly how hard it might be.
  • Only bring them into tightly defined sessions that are more about reality checking ideas until you think they can engage in more open-ended ideation.

Learning to speak product

As a short-term strategy, product and design teams often quickly learn who to ideate with and who to avoid based on this literacy of speaking product.

As a long-term strategy though, its far more effective to try to develop this literacy across different parts of an organization. That's because almost every org has people in it that know the right answer or have the right perspective that are the key to unlocking problems that product and design people are working on.

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 very useful contributors to ideation sessions.

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.

Empathy is our path forward

In design, 'extreme users' are users that face problems to a much greater degree than the average user. Slight inconveniences that most users don't even notice become showstoppers for extreme users. By empathizing with their unique needs, you can find new ways of thinking about a problem and be guided to new solutions. You'd be surprised, but many great inventions, from the typewriter to the telephone to email, are in part or in whole the result of accommodating and pursuing solutions for these users, changing their lives as a result.

Along with my lifelong interest in the design of physical and digital interfaces, I've been fortunate enough to have a speech pathologist for a mom who has inspired my interest in special needs users and those with sensory or mobility limitations. In the past few years, my interest in the subject has turned personal, as I've been recovering from an injury that at times makes using the keyboard & mouse a challenge.

This personal interest has gotten me to start experimenting with eye tracking and alternatives to the typical keyboard-on-desk workstation recently. Eye tracking is just a few years away from mainstream adoption, with early versions already helps a great many people with serious mobility issues. As it goes mainstream, it's impact will trickle down to everyone, and change everything we know about interacting with a computer. I'll probably be writing more about this in the coming year, but if you haven't heard about it before, this is a space to watch. The upcoming iPhone *may* even have it built in, and Microsoft just announced Windows 10 will support native eye tracking this fall.

But there's a next step beyond eye tracking, one that no ordinary person would dare go. The brain-computer interface shown in this study is that next step - a rare glimpse into the future that we will one day live in, when we have the ability to link our brains and quite literally communicate telepathically(!). The stuff of science fiction is here today, if we just find and help the people in situations extreme enough to need it. There's something beautiful about the future being driven by human empathy, isn't there?