My friends Jesse James Garrett and Peter Merholz recently wrapped up the first season (my phrase) of their podcast Finding Our Way. The show is about “navigating the opportunities and challenges of design leadership,” and it takes form as an ongoing conversation between the co-hosts. (And occasional guests, including yours truly.)
Peter and Jesse are rendering a tremendous service to the design community by having these conversations in public. They’re experienced practitioners reflecting on what they’ve learned both in their own journeys to design leadership and through advising other design leaders. If you haven’t heard Finding Our Way, I encourage you to listen.
Episode 25 (“The Reckoning”) is especially worth your attention. In it, Peter and Jesse reflect on emerging themes in their conversation. An exchange early in that episode resonated strongly with me. Peter observed that “the crafts of (design) leadership are communication and information architecture.” He elaborated:
People in some parts of Latin America are prone to an unusual illness called susto. It’s triggered by a traumatic incident, such as a fall or a big scare. Victims believe that the experience causes their souls to detach from their bodies, resulting in physical and psychological distress. Those afflicted become listless, have trouble sleeping and eating, develop fevers and diarrhea, etc. In extreme cases, they may even die. The condition is serious enough to merit inclusion in the DSM.
Susto is an example of a culture-bound syndrome. Even though we all share the same biology, most of us can’t get it; it only afflicts people from particular cultures. There seems to be something about these people’s understanding of themselves and their relationship to the universe that leads them to react to trauma in a particular way. This understanding is what we call a mental model. The model of people prone to susto includes the body-soul dichotomy, for example. This dichotomy seems central to the condition.
You and I also have models of how reality works. For example, we believe the earth orbits the sun. We think of politics as ranging from left to right. We distinguish people by various characteristics, such as race, age, gender, education, cultural background, religious affiliation, nationality, etc. We exchange resources and services by using currency, which is increasingly intangible. We take all of this stuff for granted.
Sometime during my school years, I learned how to write an outline. We’d been tasked with writing an essay. Our teacher showed us that we could either write from start to finish or think about what we wanted to write first. By considering the main points first, and what sequence they should be in, our essays would be more coherent and compelling.
It was hard. Putting words down as they came to us seemed easier; this outline business slowed us down. I resisted at first. With time, as we were assigned longer writing projects, the benefits of outlining became clearer. Writing an outline allowed us to see we were missing important points or had them in the wrong sequence. Outlining also helped us face the fact there were things about our subjects we didn’t yet understand; we had to do more research.
I re-learned the lesson of outlining during my final year of university when I took an elective oil painting studio course. I’d dabbled with different painting media throughout my life, and had always thought of oils as “grown-up” paints. I was excited to learn how to do it.
Specifically, I wanted to put in writing an example I’ve used when talking about this stuff: the location of the “Sync to Furthest Page Read” button/link in the Kindle user interface. Bottom line: this is an important feature if you use Kindle in several devices concurrently. However, the way you access it depends on what platform you’re using. That can be frustrating. If you haven’t done so already, please read that post.
What I didn’t cover there is why this sort of inconsistency creeps into product families. (I’m focusing The Architecture of Information on examples, and not on speculating about how they’ve come about.) That said, writing yesterday’s post made me revisit my interview with Christian Crumlish. In that conversation, I asked Christian about the sources for this type of inconsistency, and even brought up the same Kindle example. This was part of his reply:
Yesterday I launched a new website, The Architecture of Information. I describe it as a collection of “intriguing information structures from the web and beyond.” In other words, the site showcases examples of information architectures spotted in the wild.
While the site is new, much of its content isn’t. I’ve posted examples of good/bad/intriguing information architecture on my personal blog over the past three years, using the tag TAOI (the architecture of information.) I’ve copied those posts to the new website, where they can have a life of their own.
Why am I doing this? There are lots of sites that feature examples of user interface design, but few (none?) that focus on information architecture. People are drawn to snazzy screenshots and clever animations. Good navigation systems and clear conceptual models aren’t as obvious or immediately appealing.
Yet good IA is essential. As I’ve said so many times before, the structural layer of websites/apps/digital things changes more slowly than look-and-feel. Information structures have a critical influence on the effectiveness of digital products over time. So, we need to pay more heed to what’s happening beneath the surface of these things.
I hope The Architecture of Information helps shed some light. If you have ideas for interesting information structures you’d like me to feature, please get in touch. And also check out the new site — I’d love your feedback.
The part of the streaming shell game that I’ve never been able to fully understand — and that has somehow gotten worse with each passing year and each new service debut — is just how bad the user experience is on all of them.
The article lists several aspects of today’s streaming services that offer a subpar experience to viewers. Among them, it includes bad information architecture:
With the exception of Disney+, which has several clearly delineated brands and genres that are easy to explore(*), the streamers seem to go out of their way to encourage endless browsing, as if time spent on the service is valuable to them even if you never get around to actually watching anything. Browsing is difficult, direct searching is somehow worse, and the whole thing seems to have been made by one of those men Alfred tried to warn Bruce Wayne about, who just want to watch the world burn.
(*) And even they’re not perfect — all the Marvel movies are arrayed pretty randomly, which makes it more difficult to attempt to, say, rewatch the MCU in order.
I’m a customer of several of these services, and have experienced all of the issues listed in the article. I get the impression these systems have been designed “screen-first”: lots of investment on the front end and little on the underlying UX architecture.
Problems such as searching and browsing large catalogs have been solved in other domains. Why are streaming services so hard to use in 2020? I suspect the answer is a mix of business models that aren’t aligned with customer needs/wants and a lack of awareness of IA best practices. The latter is relatively easy to fix.
As a way of experiencing video content, streaming is better than the old broadcast model. But all of these services could be so much better with some mindful IA and conceptual modeling. Do you know someone who works in one of these companies, or work there yourself? If so, I’d love to talk — please get in touch.
As you can see, these aren’t cosmetic tweaks, but significant changes to Gmail’s structure. Where previously the app aspired to be a great email client, now its stated goal is to be “your new home for work.” This goal reflects three fundamental premises:
Much of what many of us do for “work” consists of coordinating with and informing each other
Most of these communications happen over digital channels (especially now that many of us are working “remotely”)
Email is no longer the only (or even primary) channel for these communications
Visually, these two screenshots look quite different. But they express the same conceptual models: a file/folder metaphor (and object-container relationship), windows that set aside portions of the display, a menu across the top of the screen (with the same menu items, even), etc. These structural constructs have endured for decades.
However, their presentation has changed as technologies and public tastes evolved. The original Macintosh featured a 512 x 314 pixel black-and-white display, which imposed many constraints on the system’s visual style. As computer displays became more capable, designers had more leeway with the presentation layer. This is the system in the early 2000s:
Again, very different visually — but the underlying structure is recognizable. A user from 1984 would have little trouble learning the newer version three decades later.
As I’ve mentioned before, digital products don’t change uniformly; they manifest pace layers. Changing visuals is cheap; changing the underlying structures is expensive. Users accept visual changes more readily than structural changes. As a result, designers and stakeholders must take greater care when changing the structure of digital products.
A few weeks ago, I saw a meme that resonated with me. It had the format of a survey question, and it went something like this:
Who initiated your company’s digital transformation?
Cue nervous laughter: all-too-real. Our response to the pandemic has wrought major changes. For one thing, everyone who can do so is now working from home. Businesses are scrambling to figure out how to best serve their customers in this new reality. There’s also a palpable sense that many of these changes will persist after the immediate crisis passes. As a result, many companies are looking for new ways to provide value over digital channels.
Most recognize that there are two aspects to digital initiatives. On the one hand, there are technical considerations: selecting and configuring infrastructure, developing applications on that infrastructure, and so on. We can think of these as the “how” of the initiative: How will we serve these customers? Should we host systems on our premises, in the cloud, or some kind of hybrid solution? Should we develop solutions internally, or should we buy an off-the-shelf product? Etc. These types of questions have traditionally been the domain of IT teams.