Today, an Apple news and rumors site posted screenshots of Healthbook, which seems to be Apple’s first major software stab at what will likely become a major focus for them. We can consider the software and hardware to come in a few ways:

  • the product angle: this is an important, useful product that can help all sorts of people in myriad ways to live longer, have more energy, feel better, understand what drives their health, feelings, and abilities, etc. Helping the world get healthier is truly important, after all.
  • the “quantified self” movement, a niche trend among a relatively small slice of the population with disproportionate influence in Silicon Valley which seeks to gather more quantifiable data about all aspects of an individual’s life for the purposes of self-optimization.
  • the health and wellness sector, a panoply of industries and media operations which monetize, in various ways, the desire of Western populations in particular to improve their health, manage their fitness, etc. There’s a lot of money aggregated in all these industries; it’s hard to predict which, if any, Apple expects to disrupt, but there are many targets.
  • the “ecosystem” angle: with devices like a smartwatch, a smart ring (see: furbo.org: “Wearing Apple” for more on a possible ring), the Apple TV, vehicles with CarPlay, and so on, Apple continues to enhance the value proposition for iOS users who buy other Apple products. This also leverages their existing strengths; competitors in, say, watches or rings will also need to have iPhone-level CPUs wirelessly communicating with their sensors; unless they’re Samsung, that’s unlikely to be the case.

Taking a closer look at the screenshots reveals what —at present, in pre-release software— Apple thinks it can handle with coming iPhone and associated devices like the presumed watch or ring (which presumably has an enhanced version of the M7 co-processor and other sensors):

This card-based UI recalls Passbook (as does the name Healthbook, although it seems strange to base the names of marquee brand apps on the name “book”), but this array of functions is astonishing. How will they capture all of this information?

  • Emergency and Bloodwork seem likely to feature user-entered information; a screenshot of the Emergency card indicates as much, so it’s safe to assume that not all cards are associated with sensor data or automatic reporting; I assume this applies to Weight and Nutrition at least as well
  • There’s no current Apple-branded solution for persistently reporting Heart Rate automatically, even though there are ways to measure it periodically and 3rd party solutions
  • I have no idea how HydrationBlood Pressure, Blood Sugar, Sleep, Respiratory Rate, or Oxygen Saturation could work; rumors suggest that some of these are measured by novel sensors Apple is investigating, but this is all novel. It’s worth noting that the leaked icon suggests confidence that Blood Pressure, Activity (calculated based on M7/8 data and possibly more; see Moves, an Activity Tracker for iPhone and Android for an example of how this works), and Heart Rate will be measured at launch:

Whether a smartwatch or a ring or cool electrodes in Dalmatian, Space Gray, or Gold will send this data, what seems notable from a mobile design perspective is that hardware is enabling innovation again in a structural way, not merely by permitting software to run more quickly, render more, or hold more in memory but by taking software into new domains.

Thus, for a designer Healthbook is interesting in the way that Reporter for iPhone is interesting: this is early software design work in a frontier area, one likely to be developed very quickly as competitors and imitators flood the market and consumers awaken to the possibility of “software eating the world” and “the internet of everything” and so on. I’ll call this area “data services” in this essay.

Since 2000, there have been lots of areas of intensely innovative activity in our industry. Some of them, like work on scaled computing —I include BigTable, MapReduce, data center designs, etc. in this— were driven by engineering but had significant consumer effects (enabling software like Google Maps to be developed and enhanced at reasonable cost, for example). Others, like web design in the mid-2000s’ Web 2.0 era, are too diverse to cover briefly here.

An obvious era is that of touchscreen and mobile computing, inaugurated in 2007 when the iPhone launched; this era entailed, among other things:

  • a re-invention of the general-purpose PC with total commitment to ease of learning / use for neophytes;
  • an expanded notion of who should be able to use computational devices; no tolerance for “expert cultures”
  • discarding anything that cannot be made simple: filesystems, simultaneity of app processes (with exceptions), wizards, configurations, user profiles, macros, scripting, etc. etc.
  • the reorientation of UIs towards the new inputs of touchscreen computing, with a corresponding simplicity

Since this mostly meant, in practice, “making new iPhone and iPad apps” and “designing UIs,” there’s lots of momentum in software design behind visual innovation. Indeed, much of iOS 7’s ostensibly radical revision comes down to stylistic variance, content-first principles, and app chrome that looks less like chrome or hides when it’s not being used.

In other words: for several years, the “exciting” part of software design has been UI design. And UI design has brought enormous benefits because for decades, UIs were the pain point for computation. While there’s still work to be done, I think the decreasing yields of UI revision indicate that we’ve largely solved the touchscreen UI problems of our moment; you won’t help many folks by making an “easier to use” camera, an “easier to use” social network, an “easier to use” note-taking app. It’s all getting “easy enough,” you might say.

But Healthbook, Reporter, the aptly-named Automatic driving assistant, and the like show the more challenging type of design work that remains: building “data services” that automatically interact with our environments, automatically compute data, and automatically present their findings in useful ways.

One way to think about this is in a sequence of plausibly “exciting” consumer apps: in 2008, an app which allowed you to note what you ate, take photos of it, and use estimates or input its caloric content would have been a useful development. In 2011, a consumer might not be excited unless the app guessed the food and calorie count from the photo; they might have also expected some recommendations based on what they ate.

In 2015, a consumer will not want to have to open an app and trigger an entry at every meal; she will not want to photograph her food or worry about the accuracy of the estimate. As sensors get closer to the body, disperse through our appliances (as with Nest), and envelop the home and commercial environments (like iBeacons), she’ll expect a system of quality to passively, automatically, and perpetually record what she eats, notify her if she needs to alter her normal behavior at opportune moments, and otherwise stay out of her way.

The designer’s goal approaches absence much more in this instance than in Jony Ive’s notion of “deference to content”; for data services to be all they can be, they must truly reduce the cognitive involvement —to say nothing of “burden”— of the user.

The future isn’t better-looking or even easier-to-use apps; it’s centralizing in an app the minimal management work required of users of data services which will monitor their health, note their tastes and behaviors for useful suggestions at the right moments, record the parts of their lives they want recorded without turning them into photographers or diarists.

If Healthbook is any indication, then, the future isn’t on your phone; it’s in the interaction of your phone, various sensors and devices in your home, car, office, and city, and on your body, and servers / systems that machine learn and analyze your data for you. Pervasive and invisible, this area of opportunity will not reward those who simply have great UI ideas or excellent taste; while app interface design obviously remains crucial, the innovation and value to come won’t render in a PSD, but it will be all the more transformative as a result.

Mills Baker