Jun
21

The Future of the Web

Source: A List Apart

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.

It began somewhat innocuously off-Twitter, with a very reasonable X-Men-themed post by Brian Kardell (one of the authors of the Extensible Web Manifesto). Brian suggests that the way forward is by opening up (via JavaScript) some low-level features that have traditionally been welded shut in the browser. This gives web developers and designers—authors, in the parlance of web standards—the ability to prototype future native browser features (for example, by creating custom elements).

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.

And, in fact, everything seemed well on the World Wide Web until this string of tweets by Alex Russell, and then this other string of tweets. At which point everyone on the web sort of went bananas.

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.

But why is it even touchy? Doesn’t it just sound kind of great?

Oh wait JavaScript

Whenever you talk about JavaScript as anything other than an optional interaction layer, folks seem to gather into two big groups.

On the Extensible Web side, we can see the people who think JavaScript is the way forward for the web. And there’s some historical precedent for that. When Brendan Eich created JavaScript, he was aware that he was putting it all together in a hurry, and that he would get things wrong. He wanted JavaScript to be the escape hatch by which others could improve his work (and fix what he got wrong). Taken one step further, JavaScript gives us the ability to extend the web beyond where it currently is. And that, really, is what the Extensible Web Manifesto folks are looking to do.

The web needs to compete with native apps, they assert. And until we get what we need natively in the browser, we can fake it with JavaScript. Much of this approach is encapsulated in the idea of progressive web apps (offline access, tab access, file system access, a spot on the home screen)—giving the web, as Alex Russell puts it, a fair fight.

On the other side of things, in the progressive enhancement camp, we get folks that are worried these approaches will leave some users in the dust. This is epitomized by the “what about users with no JavaScript” argument. This polarizing question—though not the entire issue by far—gets at the heart of the disagreement.

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.


Read the full article

Jun
17

This week’s sponsor: Bitbucket

Source: A List Apart

BITBUCKET: Over 450,000 teams and 3 million developers love Bitbucket – it’s built for teams! Try it free.


Read the full article

Jun
17

Help One of Our Own: Carolyn Wood

Source: A List Apart

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:

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.

 


Read the full article

Jun
15

Algorithms as the New Material of Design

Source: UXMatters

Algorithms drive the stock market, write articles—but not this one—approve loans, and even drive cars. Algorithms are shaping your experience every day. Your Facebook feed, your Spotify playlists, your Amazon recommendations, and more are creating a personalized window into a world that is driven by algorithms. Algorithms and machine learning help Google Maps determine the best route for you. When you ask Siri or Cortana a question, algorithms help shape what you ask and the information you receive as a response.

As experience designers, we rely more on algorithms with every iteration of a Web site or application. As design becomes less about screens and more about augmenting humans with extended capabilities, new ideas, and even, potentially, more emotional awareness, we need algorithms. If we think of experience designers as the creators of the interface between people and technology, it makes sense that we should become more savvy about algorithms. READMORE

Algorithms as the New Material of Design

Jun
15

Understanding Us: A New Frontier for User Experience

Source: UXMatters

It’s a good time to be a seasoned UX professional. Software, the epicenter of User Experience practice, continues to expand into every nook and cranny of business. Salaries for senior UX people are competitive with those of our business colleagues, and most of the roles within the galaxy of User Experience are intellectually challenging and—in the right organization—are generally rewarding and contribute to a fine quality of life.

However, this comfortable state of affairs is going to change more quickly than we realize. Already, training programs such as General Assembly and Treehouse are flooding the job market with newly minted practitioners of User Experience. This influx of low-priced, albeit inexperienced, talent that is eager to take an entry-level position and get their career started, slows and even reverses wage growth for senior talent, while making jobs increasingly harder to come by. READMORE

Understanding Us: A New Frontier for User Experience

Jun
15

Expand Your Influence: 6 Communication Techniques Designers Can Use to Earn Trust

Source: UXMatters

While more companies than ever before have a desire to be more customer centric, many UX professionals still struggle in trying to gain a high degree of influence over their organization’s overall strategy and direction. At the end of the day, instead of leveraging their design-thinking, user-research, and empathy skills to guide the highest levels of decision making, many design teams still find themselves focused on creating UI designs under the direction of others. When I attend professional meetups and discussions on design management, much of the discussion often centers around tactics for establishing User Experience as the go-to resource for strategic direction. A common sentiment: “We need to be invited to meetings earlier in the process, so we can apply our way of thinking.”

In their UXmatters article “In Search of Strategic Relevance for UX Teams,” Jim Nieters and Laurie Pattison do an excellent job of describing several organizational tactics that serve to elevate the stature of design groups. One of the most important practices they point to is establishing a level of trust with key sponsors and stakeholders. It’s best to have executive sponsorship to advocate for design, prioritize investment in design, and defend a customer-centric design approach during planning and resourcing initiatives. Sounds great, right? The challenge is that you can’t simply find these sponsors and champions in your organization. You have to earn them. READMORE

Expand Your Influence: 6 Communication Techniques Designers Can Use to Earn Trust

Jun
15

A No-Compromises User Interface Rarely Gets Built

Source: UXMatters

Some argue that a UI designer should simply be able to design without having to worry about whether there are technical or business limitations that a design solution should accommodate. The argument, so it goes, is that this is the only way it’s possible to innovate.

Purely from a design sensibility, I am not unsympathetic to this notion. Nevertheless, I do see this purist mentality actually hurting designers’ ability to deliver, especially in the enterprise world. Simply put, when we design without giving any thought to how we’ll actually make something real, we may indeed innovate. However, an innovative concept does not automatically translate into an actual product or application. READMORE

A No-Compromises User Interface Rarely Gets Built

Jun
15

Lean UX for Wearables: An Interview with Greg Nudelman, Part 1

Source: UXMatters

Wearables are becoming increasingly pervasive devices with a growing array of apps available—yet, somehow, the user experience on many of these devices is lacking. What is the best way to design for this new class of devices? In this interview, I’ll have a conversation with Greg Nudelman—a mobile and tablet experience strategist and a leader in the emerging wearables design arena—about a better approach to design for wearables. Greg is a Fortune-500 advisor, author, speaker, CEO of Design Caffeine, Inc., and has also authored four UX books:

  1. The $1 Prototype: A Modern Approach to Mobile UX Design and Rapid Innovation—See my review for more information about this approach.
  2. Android Design Patterns: Interaction Design Solutions for Developers
  3. Smashing Mobile Book, with co-authors
  4. Designing Search: UX Strategies for eCommerce Success, a UXmatters book, with Contributing Editor Pabini Gabriel-Petit

READMORE

Lean UX for Wearables: An Interview with Greg Nudelman, Part 1

Jun
15

Promoting a Design System Across Your Products

Source: A List Apart

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.

Diagram showing an account hub

“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.

Diagram showing an interconnected enterprise ecosystem: marketing, account setup, account hub, plus iOS apps

“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
  • Homepage
  • Products
  • Support
  • About
  • Careers
  • 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.
Screenshot showing a detailed product inventory

A detailed product inventory.

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!”

Diagram showing a typical web marketing sitemap overlaid with a product section team’s choices on spreading a system beyond its own section

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.

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.

A series of screenshots of the Marriott.com project showing how disparate design artifacts across products were stitched together into an interactive 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.


Read the full article

Jun
07

This week’s sponsor: FULLSTORY

Source: A List Apart

FullStory, a pixel-perfect session playback tool that captures everything about your customer experience with one easy-to-install script.


Read the full article

Older posts «