Recently the web—via Twitter—erupted in short-form statements that soon made it clear that buttons had been pushed, sides taken, and feelings felt. How many feels? All the feels. Some rash words may have been said.
But that’s Twitter for you.
If you’ve been following all the talk about web components and the shadow DOM of late, this will sound familiar. The idea is to make standards-making a more rapid, iterative, bottom-up process; if authors have the tools to prototype their own solutions or features (poly- and prolly-fills), then the best of these solutions will ultimately rise to the top and make their way into the native browser environments.
This sounds empowering, collaborative—very much in the spirit of the web.
Doomsday scenarios were proclaimed; shadowy plots implied; curt, sweeping ideological statements made. In short, it was the kind of shit-show you might expect from a touchy, nuanced subject being introduced on Twitter.
For the Extensible Web folks, it feels like we’re holding the whole web back for a tiny minority of users. For the Progressive Enhancement folks, it’s akin to throwing out accessibility—cruelly denying access to a subset of (quite possibly disadvantaged) users.
During all this hubbub, Jeremy Keith, one of the most prominent torchbearers for progressive enhancement, reminded us that nothing is absolute. He suggests that—as always—the answer is “it depends.” Now this should be pretty obvious to anyone who’s spent a few minutes in the real world doing just about anything. And yet, at the drop of a tweet, we all seem to forget it.
So if we can all take a breath and rein in our feelings for a second, how might we better frame this whole concept of moving the web forward? Because from where I’m sitting, we’re all actually on the same side.History and repetition
To better understand the bigger picture about the future of the web, it’s useful (as usual) to look back at its past. Since the very beginning of the web, there have been disagreements about how best to proceed. Marc Andreessen and Tim Berners-Lee famously disagreed about the IMG tag. Tim didn’t get his way, Marc implemented IMG in Mosaic as he saw fit, and we all know how things spun out from there. It wasn’t perfect, but a choice had to be made and it did the job. History suggests that IMG did its job fairly well.
A pattern of hacking our way to the better solution becomes evident when you follow the trajectory of the web’s development.
In the 1990’s, webmasters and designers wanted layout like they were used to in print. They wanted columns, dammit. David Siegel formalized the whole tables-and-spacer-GIFs approach in his wildly popular book Creating Killer Web Sites. And thus, the web was flooded with both design innovation and loads of un-semantic markup. Which we now know is bad. But those were the tools that were available, and they allowed us to express our needs at the time. Life, as they say…finds a way.
And when CSS layout came along, guess what it used as a model for the kinds of layout techniques we needed? That’s right: tables.
While we’re at it, how about Flash? As with tables, I’m imagining resounding “boos” from the audience. “Boo, Flash!” But if Flash was so terrible, why did we end up with a web full of Flash sites? I’ll tell you why: video, audio, animation, and cross-browser consistency.
In 1999? Damn straight I want a Flash site. Once authors got their hands on a tool that let them do all those incredible things, they brought the world of web design into a new era of innovation and experimentation.
But again with the lack of semantics, linkability, and interoperability. And while we were at it, with the tossing out of an open, copyright-free platform. Whoops.
It wasn’t long, though, before the native web had to sit up and take notice. Largely because of what authors expressed through Flash, we ended up with things like HTML5, Ajax, SVGs, and CSS3 animations. We knew the outcomes we wanted, and the web just needed to evolve to give us a better solution than Flash.
In short: to get where we need to go, we have to do it wrong first.Making it up as we go along
We authors express our needs with the tools available to help model what we really need at that moment. Best practices and healthy debate are a part of that. But please, don’t let the sort of emotions we attach to politics and religion stop you from moving forward, however messily. Talk about it? Yes. But at a certain point we all need to shut our traps and go build some stuff. Build it the way you think it should be built. And if it’s good—really good—everyone will see your point.
If I said to you, “I want you to become a really great developer—but you’re not allowed to be a bad developer first,” you’d say I was crazy. So why would we say the same thing about building the web?
We need to try building things. Probably, at first, bad things. But the lessons learned while building those “bad” projects point the way to the better version that comes next. Together we can shuffle toward a better way, taking steps forward, back, and sometimes sideways. But history tells us that we do get there.
The web is a mess. It is, like its creators, imperfect. It’s the most human of mediums. And that messiness, that fluidly shifting imperfection, is why it’s survived this long. It makes it adaptable to our quickly-shifting times.
As we try to extend the web, we may move backward at the same time. And that’s OK. That imperfect sort of progress is how the web ever got anywhere at all. And it’s how it will get where we’re headed next.Context is everything
One thing that needs to be considered when we’re experimenting (and building things that will likely be kind of bad) is who the audience is for that thing. Will everyone be able to use it? Not if it’s, say, a tool confined to a corporate intranet. Do we then need to worry about sub-3G network users? No, probably not. What about if we’re building on the open web but we’re building a product that is expressly for transferring or manipulating HD video files? Do we need to worry about slow networks then? The file sizes inherent in the product pretty much exclude slow networks already, so maybe that condition can go out the window there, too.
Context, as usual, is everything. There needs to be realistic assessment of the risk of exclusion against the potential gains of trying new technologies and approaches. We’re already doing this, anyway. Show me a perfectly progressively enhanced, perfectly accessible, perfectly performant project and I’ll show you a company that never ships. We do our best within the constraints we have. We weigh potential risks and benefits. And then we build stuff and assess how well it went; we learn and improve.
When a new approach we’re trying might have aspects that are harmful to some users, it’s good to raise a red flag. So when we see issues with one another’s approaches, let’s talk about how we can fix those problems without throwing out the progress that’s been made. Let’s see how we can bring greater experiences to the web without leaving users in the dust.
If we can continue to work together and consciously balance these dual impulses—pushing the boundaries of the web while keeping it open and accessible to everyone—we’ll know we’re on the right track, even if it’s sometimes a circuitous or befuddling one. Even if sometimes it’s kind of bad. Because that’s the only way I know to get to good.
One of the nicest people we’ve ever known and worked with is in a desperate fight to survive. Many of you remember her—she is a gifted, passionate, and tireless worker who has never sought the spotlight and has never asked anything for herself.
Carolyn Wood spent three brilliant years at A List Apart, creating the position of acquisitions editor and bringing in articles that most of us in the web industry consider essential reading—not to mention more than 100 others that are equally vital to what we do today. Writers loved her. Since 1999, she has also worked on great web projects like DigitalWeb, The Manual, and Codex: The Journal of Typography.
Think about it. What would the web look like if she hadn’t been a force behind articles like these:
- Responsive Web Design by Ethan Marcotte
- More Meaningful Typography by Tim Brown
- Orbital Content by Cameron Koczon
- CSS Floats 101 by Noah Stokes
- Designing Web Registration Processes for Kids by Debra Levin Gelman
- Design Criticism and the Creative Process by Cassie McDaniel
- A Simpler Page by Craig Mod
Three years ago, Carolyn was confined to a wheelchair. Then it got worse. From the YouCaring page:
This April, after a week-long illness, she developed acute injuries to the tendons in her feet and the nerves in her right hand and arm. She couldn’t get out of her wheelchair, even to go to the bathroom. At the hospital, they discovered Carolyn had acute kidney failure. After a month in a hospital and a care facility she has bounced back from the kidney failure, but she cannot take painkillers to help her hands and feet.
Carolyn cannot stand or walk or dress herself or take a shower. She is dependent on a lift, manned by two people, to transfer her. Without it she cannot leave her bed.
She’s now warehoused in a home that does not provide therapy—and her insurance does not cover the cost. Her bills are skyrocketing. (She even pays rent on her bed for $200 a month!)
Perhaps worst of all—yes, this gets worse—is that her husband has leukemia. He’s dealing with his own intense pain and fatigue and side effects from twice-monthly infusions. They are each other’s only support, and have been living apart since April. They have no income other than his disability, and are burning through their life savings.
This is absolutely a crisis situation. We’re pulling the community together to help Carolyn—doing anything we possibly can. Her bills are truly staggering. She has no way to cover basic life expenses, much less raise the huge sums required to get the physical and occupational therapy she needs to be independent again.
Please help by donating anything you can, and by sharing Carolyn’s support page with anyone in your network who is compassionate and will listen.
The scene: day one of a consulting gig with a new client to build a design and code library for a web app. As luck would have it, the client invited me to sit in on a summit of 25 design leaders from across their enterprise planning across platforms and lines of business. The company had just exploded from 30 to over 100 designers. Hundreds more were coming. Divergent product design was everywhere. They dug in to align efforts.
From a corner, I listened quietly. I was the new guy, minding my own business, comfortable with my well-defined task and soaking up strategy. Then, after lunch, the VP of Digital Design pulled me into an empty conference room.
“Can you refresh me on your scope?” she asked. So I drew an account hub on the whiteboard.
“See, the thing is…” she responded, standing up and taking my pen. “We’re redesigning our web marketing homepage now.” She added a circle. “We’re also reinventing online account setup.” Another circle, then arrows connecting the three areas. “We’ve just launched some iOS apps, and more—plus Android—are coming.” She added more circles, arrows, more circles.
“I want it all cohesive. Everything.” She drew a circle around the entire ecosystem. “Our design system should cover all of this. You can do that, right?”
A long pause, then a deep breath. Our design system—the parts focused on, the people involved, the products reached—had just grown way more complicated.
Our industry is getting really good at surfacing reusable parts in a living style guide: visual language like color and typography, components like buttons and forms, sophisticated layouts, editorial voice and tone, and so on. We’ve also awoken to the challenges of balancing the centralized and federated influence of the people involved. But there’s a third consideration: identifying and prioritizing the market of products our enterprise creates that our system will reach.
As a systems team, we need to ask: what products will use our system and how will we involve them?Produce a product inventory
While some enterprises may have an authoritative and up-to-date master list of products, I’ve yet to work with one. There’s usually no more than a loose appreciation of a constantly evolving product portfolio.Start with a simple product list
A simple list is easy enough. Any whiteboard or text file will do. Produce the list quickly by freelisting as many products as you can think of with teammates involved in starting the system. List actual products (“Investor Relations” and “Careers”), not types of products (such as “Corporate Subsites”).Some simple product lists Large Corporate Web Site Small Product Company Large Enterprise 5–15 products 10–25 products 20–100 products
- Web marketing site
- Web support site
- Web corporate site
- Community site 1
- Community site 2
- Web app basic
- Web app premium
- Web app 3
- Web app 4
- Windows flagship client
- Windows app 2
- Web home
- Web product pages
- Web product search
- Web checkout
- Web support
- Web rewards program
- iOS apps (10+)
- Android apps (10+)
- Web account mgmt (5+)
- Web apps (10+)
Note that because every enterprise is unique, the longer the lists get, the more specific they become.For broader portfolios, gather more details
If your portfolio is more extensive, you’ll need more deliberate planning and coordination of teams spanning an organization. This calls for a more structured, detailed inventory. It’s spreadsheet time, with products as rows and columns for the following:
- Name, such as Gmail
- Type / platform: web site, web app, iOS, Android, kiosk, etc.
- Product owner, if that person even exists
- Description (optional)
- People (optional), like a product manager, lead designer or developer, or others involved in the product
- Other metadata (optional): line of business, last redesigned, upcoming redesign, tech platform, etc.
Creating such an inventory can feel draining for a designer. Some modern digital organizations struggle to fill out an inventory like this. I’m talking deer-in-headlights kind of struggling. Completely locked up. Can’t do it. But consider life without it: if you don’t know the possible players, you may set yourself up for failure, or at least a slower road to success. Therefore, take the time to understand the landscape, because the next step is choosing the right products to work with.Prioritize products into tiers
A system effort is never equally influenced by every product it serves. Instead, the system must know which products matter—and which don’t—and then varyingly engage each in the effort. You can quickly gather input on product priorities from your systems team and/or leaders using techniques like cumulative voting.
Your objective is to classify products into tiers, such as Flagship (the few, essential core products), Secondary (additional influential products), and The Rest to orient strategy and clarify objectives.1—Organize around flagships
Flagship products are the limited number of core products that a system team deeply and regularly engages with. These products reflect a business’ core essence and values, and their adoption of a system signals the system’s legitimacy.
Getting flagship products to participate is essential, but challenging. Each usually has a lot of individual power and operates autonomously. Getting flagships to share and realize a cohesive objective requires effort.Choose flagships that’ll commit to you, too
When naming flagships, you must believe they’ll play nice and deliver using the system. Expect to work to align flagships: they can be established, complicated, and well aware of their flagship status. Nevertheless, if all flagships deliver using the system, the system is an unassailable standard. If any avoid or obstruct the system, the system lacks legitimacy.
Takeaway: obtain firm commitments, such as “We will ship with the system by such and such a date” or “Our product MVP must use this design system.” A looser “Yes, we’ll probably adopt what we can” lacks specificity and fidelity.Latch onto a milestone, or make your own
Flagship commitment can surface as a part of a massive redesign, corporate rebranding, or executive decree. Those are easy events to organize around. Without one, you’ll need to work harder bottom-up to align product managers individually.
Takeaway: establish a reasonable adoption milestone you can broadcast, after which all flagships have shipped with the system.Choose wisely (between three and five)
For a system to succeed, flagships must ship with it. So choose just enough. One flagship makes the system’s goals indistinguishable from its own self-interest. Two products don’t offer enough variety of voices and contexts to matter. Forming a foundation with six or more “equally influential voices” can become chaotic.
Takeaway: three flagships is the magic minimum, offering sufficient range and incorporating an influential and sometimes decisive third perspective. Allowing for four or five flagships is feasible but will test a group’s ability to work together fluidly.A system for many must be designed by many
Enterprises place top talent on flagship products. It would be naive to think that your best and brightest will absorb a system that they don’t influence or create themselves. It’s a team game, and getting all-stars working well together is part of your challenge.
Takeaway: integrate flagship designers from the beginning, as you design the system, to inject the right blend of individual styles and shared beliefs.2—Blend in a secondary set
More products—a secondary set— are also important to a system’s success. Such products may not be flagships because they are between major releases (making adoption difficult), not under active development, or even just slightly less valuable.Include secondary products in reference designs
Early systems efforts can explore concept mockups—also known as reference designs—to assess a new visual language across many products. Reference designs reveal an emerging direction and serve as “before and after” roadshow material.
Takeaway: include secondary products in early design concepts to acknowledge the value of those products, align the system with their needs, and invite their teams to adopt the system early.Welcome participation (but moderate contribution)
Systems benefit from an inclusive environment, so bias behaviors toward welcoming input. Encourage divergent ideas, but know that it’s simply not practical to give everyone a voice in everything. Jon Wiley, an early core contributor to Google’s Material Design, shared some wisdom with me during a conversation: “The more a secondary product’s designer participated and injected value, the more latitude they got to interpret and extend the system for their context.”
Takeaway: be open to—but carefully moderate—the involvement of designers on secondary products.3—Serve the rest at a greater distance
The bigger the enterprise, the longer and more heterogeneous the long tail of other products that could ultimately adopt the system. A system’s success is all about how you define and message it. For example, adopting the core visual style might be expected, but perhaps rigorous navigational integration and ironclad component consistency aren’t goals.
Documentation may be your primary—or only—channel to communicate how to use the system. Beyond that, your budding system team may not have the time for face-to-face meetings or lengthy discussions.
Takeaway: early on, limit focus on and engagement with remaining products. As a system matures, gradually invest in lightweight support activities like getting-started sessions, audits, and triaging office-hour clinics.Adjust approach depending on context
Every product portfolio is different, and thus so is every design system. Let’s consider the themes and dynamics from some archetypal contexts we face repeatedly in our work.Example 1: large corporate website, made of “properties”
You know: the homepage-as-gateway-to-products hegemon (owned by Marketing) integrated with Training, Services, and About Us content (owned by less powerful fiefdoms) straddling a vast ocean of transactional features like Support/Account Management and Communities. All of these “properties” have drifted apart, and some trigger—the decision to go responsive, a rebranding, or an annoyed-enough-to-care executive—dictates that it’s “time to unify!”Typical web marketing sitemap, overlaid with a product section team’s choices on spreading a system beyond its own section. The get? Support
System influence usually radiates from Marketing and Brand through to selling Products. But Support is where customers spend most of their time: billing, admin, downloading, troubleshooting. Support’s features are complicated, with intricate UI and longer release cycles across multiple platforms. It may be the most difficult section to integrate , but it’s essential.
Takeaway: if your gets—in this case Home, Products, and Support—deliver, you win. Everyone else will either follow or look bad. That’s your flagship set.Minimize homepage distraction
Achieving cohesive design is about suffusing an entire experience with it. Yet a homepage is often the part of a site that is most exposed to, and justifiably distinct from, otherwise reusable componentry. It has tons of cooks, unique and often complex parts, and changes frequently. Such qualities— indecisiveness, complexity, and instability—corrode systems efforts.
Takeaway: don’t fall prey to the homepage distraction. Focus on stable fundamentals that you can confidently spread.Exploit navigational change to integrate a system hook
As branding or navigation changes, so does a header. It appears everywhere, and changes to it can be propagated centrally. Get those properties—particularly those lacking full-time design support—to sync with a shared navigation service, and use that hook to open access to the greater goodies your system has to offer.
Takeaway: exploit the connection! Adopters may not embrace all your parts, but since you are injecting your code into their environment, they could.Example 2: a modest product portfolio
A smaller company’s strategic shifts can be chaotic, lending themselves to an unstable environment in which to apply a system. Nevertheless, a smaller community of designers—often a community of practice dispersed across a portfolio—can provide an opportunity to be more cohesive.Radiate influence from web apps
Many small companies assemble portfolios of websites, web apps, and their iOS, Android, and Windows counterparts. Websites and native apps share little beyond visual style and editorial tone. However, web apps provide a pivot: they can share a far deeper overlap of components and tooling with websites, and their experiences often mirror what’s found on native apps.
Takeaway: look for important products whose interests overlap many other products, and radiate influence from there.Diagram of product relationships within a portfolio, with web apps relating to both web sites and native apps. Demo value across the whole journey
A small company’s flagship products should be the backbone of a customer’s journey, from reach and acquisition through service and loyalty. Design activities that express the system’s value from the broader user journey tend to reveal gaps, identify clunky handoffs, and trigger real discussions around cohesiveness.
Takeaway: evoke system aspirations by creating before/after concepts and demoing cohesiveness across the journey, such as with a stitched prototype.For Marriott.com, disparate design artifacts across products (left) were stitched together into an interactive, interconnected prototype (right). Bridge collaboration beyond digital
Because of their areas of focus, “non-digital” designers (working on products like trade-show booths, print, TV, and retail) tend to be less savvy than their digital counterparts when it comes to interaction. Nonetheless, you’ll share the essence of your visual language with them, such as making sure the system’s primary button doesn’t run afoul of the brand’s blue, and yet provides sufficient contrast for accessibility.
Takeaway: encourage non-digital designers to do digital things. Be patient and inclusive, even if their concerns sometimes drift away from what you care about most.Example 3: a massive multiplatform enterprise
For an enterprise as huge as Google, prioritizing apps was essential to Material Design’s success. The Verge’s “Redesigning Google: How Larry Page Engineered a Beautiful Revolution” suggests strong prioritization, with Search, Maps, Gmail, and later Android central to the emerging system. Not as much in the conversation, perhaps early on? Docs, Drive, Books, Finance. Definitely not SantaTracker.Broaden representation across platforms & businesses
With coverage across a far broader swath of products, ensure flagship product selection spans a few platforms and lines of business. If you want it to apply everywhere, then the system—how it’s designed, developed, and maintained—will benefit from diverse influences.
Takeaway: Strive for diverse system contribution and participation in a manner consistent with the products it serves.Mix doers & delegators
Massive enterprise systems trigger influence from many visionaries. Yet you can’t rely on senior directors to produce meticulous, thoughtful concepts. Such leaders already direct and manage work across many products. Save them from themselves! Work with them to identify design talent with pockets of time. Even better, ask them to lend a doer they recommend for a month- or weeklong burst.
Takeaway: defer to creative leaders on strategy, but redirect their instincts from doing everything to identifying and providing talent.Right the fundamentals before digging deep
I confess that in the past, I’ve brought a too-lofty ambition to bear on quickly building huge libraries for organizations of many, many designers. Months later, I wondered why our team was still refining the “big three” (color, typography, and iconography) or the “big five” (the big three, plus buttons and forms). Um, what? Given the system’s broad reach, I had to adjust my expectations to be satisfied with what was still a very consequential shift toward cohesiveness.
Takeaway: balance ambition for depth with spreading fundamentals wide across a large enterprise, so that everyone shares a core visual language.The long game
Approach a design system as you would a marathon, not a sprint. You’re laying the groundwork for an extensive effort. By understanding your organization through its product portfolio, you’ll strengthen a cornerstone—the design system—that will help you achieve a stronger and more cohesive experience.