Thinking in bits (redux)

A key to any organization’s survival of the ongoing digital reformation will be their ability to break free from the deeply ingrained thinking in terms of atoms and start thinking in bits.

I first came across the idea of thinking in bits in Nicholas Negroponte‘s 1995 book Being digital. In the book, Negroponte talks about the limitations, the cost, of moving information around as atoms – paper books, CDs, DVDs, snail mail, you get the idea – and how information would soon be converted from atoms to bits. The immediately obvious implication is that it now becomes essentially free to move and share information as bits.

The less obvious, but much more important, implication is that bits change the way you can think about the information. How you can manipulate and repurpose the information. How you can do things that were impossible with the information locked up in atoms. The obvious applications have come to fruition. Email instead of snail mail. Music downloads instead of CDs, and now streaming instead of downloads. The same with video.

And yet…

And yet, the way this digitized information, these bits, is handled is still in many ways tied to the way atoms were handled. The medium has changed, but the process remains the same. Some of this, such as in the music and movie industries, is purely for commercial reasons. They are shipping in bits, but they are not thinking in bits.

Even from a creative perspective, as opposed to the commercial, this thinking in atoms prevents many from seeing new possibilities for providing engaging and individual experiences to their customers. For example, consider how labels distribute music, how they release the same tracks in the same order on both CD and on services like iTunes or Google Play. This is thinking in atoms at its finest (worst?).

Imagine if they were thinking in bits instead. They could offer an “album” that includes songs from the setlist the band played in your town, or edit the songs at the disc-breaks on multi-disc albums so they didn’t fade out / fade in. For individual song downloads from live recordings they could edit the track so you didn’t catch the introduction to the next song at the end of the song you’re listening too.

The same is true, albeit for different reasons, inside many organizations. Yes, nearly everything is in bits, stored on shared drives, in Sharepoint or email, on an enterprise social network or whatever system your organization uses to “manage” content.

And yet….

And yet most of these bits are locked up in mere digital representations of atoms. Again, working in bits but not thinking in bits.

Of course, 20+ years after Being Digital things have changed quite a bit. Many companies have leveraged thinking in bits to their advantage. Tax preparation software companies come to mind: the process of collecting the necessary information is designed to meet the needs of the person entering the information while the output of the information is in the format (atom-based) necessary for submission to the appropriate agencies. (Sadly, my guess is that those agencies still have atom-based processes to actually handle the information.)

And technology has evolved radically. Blockchain comes to mind. But even there, in a highly thinking in bits based process of transactions, most people’s attention is drawn to the most atom-based aspect of the blockchain – it’s use as a currency.

Digital transformation is not, as some people think, something you do. It is, rather, something that is happening, something that is happening to you. Whether you want it to or not. Thinking in bits is your key to not just surviving the transformation, but to leading the way.

A brief case for inclusionary accessibility in design

I was at a local big-box store the other day picking up some hardware for a home improvement project and had the need to visit the men’s room. It is a large store and so has a relatively spacious men’s room, with the sinks just inside the entry followed by a row of four urinals. As I walked in I was struck by the fact that the four urinals appeared to be exactly the same, except for one detail. If you can see the featured image of this post, I’m sure you know what I’m talking about.

I couldn’t help wondering, “Why didn’t they just install them all that low to the ground?”

Of course, that was a somewhat rhetorical question to myself because I can easily visualize how the design process went.

Based on the size of the store, the building codes require us to have four urinals. Let’s go ahead and put them along this wall here and install them at the standard height. Oh, except for one that needs to be lower because, well, you know, the “rules”. Left or right side? Doesn’t matter, as long as we have a short one.

And as a result only one of the urinals was installed lower to the ground, because that was all that was required.

It would be easy enough to say that “accessibility” was not considered in the design process for this men’s room, or that it wasn’t sufficiently considered. I would argue, however, that this design is very much based on a consideration of accessibility. It’s just that the accessibility considered was exclusionary and not inclusionary.

Here’s what I mean.

Back when modern urinals were first designed to be more than an open depression or slit in the ground that men stood around to, well, you know, the only people who would ever use them would most likely be adult men. There was little or no effort made to make it possible for those with physical handicaps to even get into the building, much less any thought given to how they might use the restroom. So the urinals were designed to be exclusively accessible to adult men who could stand up in front of the urinal. (To be clear, this is just an assumption, my impression based on my understanding of history in general.)

Fast forward to today when we know better and make more effort, at least on paper, to make access to spaces and facilities more inclusively accessible. The exclusionary approach is so ingrained in the culture and in design that making something accessible for the “other” is seen as something separate, something that needs to be done because someone somewhere said it had to be done.

An inclusively accessible design for this men’s room would have, in my mind anyway, had four urinals closer to the ground than the old standard (it should become an old standard, anyway). To take it even further, the design and construction standard (and building codes, to be sure) should be changed to reflect this inclusive design approach.

If one of the urinals is going to be lower to the ground than the “usual”, why not just make them all lower to the ground? In this way you are meeting the needs of all (or at least more) with one simple change.

To be sure, inclusionary accessibility is more difficult in some situations than in others. The urinal example above is relatively straightforward compared, for example, to the challenges software and website developers have. Unlike the physical example of the urinal, which can easily accommodate all users with a single configuration, software developers have to understand and contend with often competing and contrary needs.

A basic example is the user interface of a web site in a web browser. Just take a moment and consider how you use the web browser on your laptop. Now, close your eyes and think about how you would use the web browser on your laptop if you couldn’t see it.

For the person who can see the screen, visual cues are typically sufficient and they would likely not want to hear a description of the screen or the layout read to them as they navigate the page. But for the person who can’t see the screen, the actual visual design of the site is unimportant and, for all intents and purposes, of no value. They need another way with which to navigate and to consume the content.

Which gets us back, once again, to the prevalence of exclusionary accessibility in design.

Blind people aren’t going to use a web browser, how would they see it? So we’ll just design it based on people being able to see what they are doing.

I am encouraged by some recent examples of incorporating accessibility in digital design. WordPress, for example, requires that “all new and updated WordPress code must conform with the WCAG 2.0 guidelines at level AA”. The upcoming St. Louis Service Design and UX Conference has accessibility as a focus; I hope that the speakers will at least touch on this idea of inclusionary design. And I am especially encouraged by the growing (slowly growing, but growing) awareness and use of human-centered design principles.

But none of this matters if “accessibility” continues to be seen as something separate from the main design, an add-on for the “others” that can’t use the “real” version.

We need to become inclusionary not just in our design work, but in how we see the world as a whole.



You should always follow the rules (except when you shouldn’t)


Note: This post references concepts explained in the Cynefin framework

The typical organizational decision making process treats most operational issues as if they are Ordered, a complicated (or obvious) problem that needs to be solved. Based on your understanding of the situation you develop several courses of action, based on rules or “good practices” that have worked to some degree in the past, and implement a course of action with the belief that you can accurately predict the outcome of implementing the course of action based on past experiences. This assumes, in general, either a relatively static (non-adaptive) situation or a situation that develops in a predictable manner.

Many situations we face today, however, fall increasingly in the complex domain. In this case, you respond to the situation without any separate and discreet analysis or planning. If your actions don’t achieve the desired results, you take what you’ve learned (sense) and respond again. You don’t know what you are going to need to do until the situation presents itself, and you don’t know if it will work until after you’ve tried.

To dip into a pop culture reference, an episode of the TV show “The Last Ship” presented a scenario in which both obvious, complicated, and complex challenges presented themselves, all as part of the same situation. This is a very condensed description tailored to fit this conversation.

The ship is hunting – and being hunted by – an enemy submarine.

The Captain is on the bridge and his staff is providing him the information he needs to decide the appropriate course of action. A well defined task, with years of training and experience, he knows exactly what he needs to do, and his staff know exactly how to respond to the Captain’s orders to achieve the desired result. Obvious.

The ship’s sonar was damaged in a previous action. The Chief Engineer have a sensor that they can adapt to act as a sonar-like device to acquire the target, but have many technical, operational, and other practical considerations they must consider to make this happen. They know the constraints they have and what they need to do to make it work. The Chief coordinates each person’s actions to bring their experience to bear to plan and achieve the predicted results based on past experience. Complicated.

A land team comes across an unexpected gun emplacement threatening the ship. They don’t know exactly how many enemy personnel are manning / guarding the guns, nor do they know the terrain beyond the cover and concealment from which they will begin their assault. When asked the plan, the team leader responds simply with, “Win.” Each member of the team then executes the plan, responding as they learn more about the number of enemy personnel, the lay of the land, etc. Complex.

Organizations tend to look at all problems as if they are obvious or complicated, that we can simply apply a known rule or process and get the predicted / desired outcome. Which is great for when the problem you face is actually obvious or complicated. Too often, though, organizations prematurely try to reduce a complex problem to the point that they are obvious so that we can standardize and automate as much as possible.

When you try to solve a complex problem as if it were obvious, you are just begging for trouble.

image credit: Dave Snowden, retrieved from Wikipedia on 10 July 2017 

Dear PMs, It’s time to Rethink Agile at Enterprise Startups

Eisenhower knew that any plan crafted before battle would be obsolete at first contact with the enemy. In his work, Kavazovic wants to be this realistic too. “Translating this into tech: no long-term plan or product vision survives contact with the user in the product-design sense. That’s why agile methodology is specifically designed to create user experiences that work,” he says. “It’s absolutely suboptimal to design a particular product all the way down to years’ worth of features, make that the blueprint, and build it out.” Inevitably, sticking to a rigid long-term plan without a mechanism to iterate on user feedback would result in features users don’t want, costly re-dos and potentially total product failure.

Source – Dear PMs, It’s time to Rethink Agile at Enterprise Startups

Division in the Autism Community – what next for us?

“It’s very hard for members of the three groups to find common ground.  People tend to see autism through the lens of personal experience.  An autistic college student who has trouble with organization and social skills is likely to view autism very differently from a parent whose child is non verbal, cognitively disabled, and self injurious. ”

Source – Division in the Autism Community – what next for us?