You are here

thinktime

Not enough 'if' or not enough 'then'?

Seth Godin - Sat 25th Jun 2016 18:06
All change involves an if/then promise. "If you want a delicious dinner, then try this new restaurant." "If you want to be seen as a hunk, drive this Ferrari." "If you want to avoid being dead, have this surgery." If...        Seth Godin
Categories: thinktime

The problem with complaining about the system

Seth Godin - Fri 24th Jun 2016 18:06
...is that the system can't hear you. Only people can. And the problem is that people in the system are too often swayed to believe that they have no power over the system, that they are merely victims of it,...        Seth Godin
Categories: thinktime

Taking notes vs. taking belief

Seth Godin - Thu 23rd Jun 2016 18:06
Is there anything easier than listening to a lecture or reading a book and taking notes? And is there anything more difficult than setting aside our preconceptions and the resistance and acting 'as if', being open to belief, at least...        Seth Godin
Categories: thinktime

Bigger for?

Seth Godin - Wed 22nd Jun 2016 18:06
Is bigger better for the investor or is it better for the customer? At a huge hotel in Nashville (more than 1,000 rooms), there's always a long line at the check in desk, the gym is full at 5 in...        Seth Godin
Categories: thinktime

The Future of the Web

a list apart - Wed 22nd Jun 2016 00:06

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.

Categories: thinktime

"So busy doing my job, I can't get any work done"

Seth Godin - Tue 21st Jun 2016 18:06
Your job is an historical artifact. It's a list of tasks, procedures, alliances, responsibilities, to-dos, meetings (mostly meetings) that were layered in, one at a time, day after day, for years. And your job is a great place to hide....        Seth Godin
Categories: thinktime

You can't ask customers want they want

Seth Godin - Mon 20th Jun 2016 18:06
... not if your goal is to find a breakthrough. Because your customers have trouble imagining a breakthrough. You ought to know what their problems are, what they believe, what stories they tell themselves. But it rarely pays to ask...        Seth Godin
Categories: thinktime

The saying/doing gap

Seth Godin - Sun 19th Jun 2016 19:06
At first, it seems as though the things you declare, espouse and promise matter a lot. And they do. For a while. But in the end, we will judge you on what you do. When the gap between what you...        Seth Godin
Categories: thinktime

"The way we do things"

Seth Godin - Sat 18th Jun 2016 18:06
There are two pitfalls you can encounter in dealing with focus and process: In moments of weakness, you take on a project or client that's outside your focus zone. After all, you need the work. In moments of blindness, you...        Seth Godin
Categories: thinktime

Help One of Our Own: Carolyn Wood

a list apart - Sat 18th Jun 2016 02:06

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.

 

Categories: thinktime

Stretching without support

Seth Godin - Fri 17th Jun 2016 18:06
One of the fundamental equations of our self-narrative is: If I only had more support, I could accomplish even more. Part of this is true. With more education, a stronger foundation, better cultural expectations, each of us is likely to...        Seth Godin
Categories: thinktime

This week's sponsor: Bitbucket

a list apart - Fri 17th Jun 2016 00:06

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

Categories: thinktime

The ruby slippers problem

Seth Godin - Thu 16th Jun 2016 18:06
Most of what we're chasing is that which we've had all along. In our culture, the getting is ever more important than the having. There's nothing wrong with getting, of course, as long as the process is in sync with...        Seth Godin
Categories: thinktime

It's not a race

Seth Godin - Wed 15th Jun 2016 19:06
Some things are races, but not many. A race is a competition in which the point is to win. You're not supposed to enjoy the ride, learn anything or make your community better. You're supposed to win. At the end...        Seth Godin
Categories: thinktime

Promoting a Design System Across Your Products

a list apart - Wed 15th Jun 2016 00:06

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

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.

Categories: thinktime

"Things have gotten a little quiet..."

Seth Godin - Tue 14th Jun 2016 18:06
In the old economy, social connection was done to us. "There's nothing to do around here." "I'm bored." "Nothing's happening in this place." You could whine about the fact that your college didn't have enough activities, or that the bar...        Seth Godin
Categories: thinktime

Raising the average

Seth Godin - Mon 13th Jun 2016 18:06
Great organizations are filled with people who are eagerly seeking to recruit people better than they are. Not just employees, but vendors, coaches and even competitors. Most organizations seek to hire, "people like us." The rationale is that someone too...        Seth Godin
Categories: thinktime

Shields up

Seth Godin - Sun 12th Jun 2016 19:06
Do not tell your friends about your nascent idea, your notion, the area you hope to explore next. Do not seek reassurance from them. Do not become vulnerable about your tiny new sprout of an inkling. It will be extinguished...        Seth Godin
Categories: thinktime

"But where's the money?"

Seth Godin - Sat 11th Jun 2016 19:06
A colleague was talking to the CEO of a fast-growing small business about a partnership opportunity. The CEO said, "well, this is something we believe in, something we want to have happen," and then he continued, "in fact, it's something...        Seth Godin
Categories: thinktime

The marketing we deserve

Seth Godin - Fri 10th Jun 2016 19:06
We say we want sustainable packaging... but end up buying the one in fancy packaging instead. We say we want handmade, local goods... but end up buying the cheap one, because it's 'just as good.' We say we want the...        Seth Godin
Categories: thinktime

Pages

Subscribe to kattekrab aggregator - thinktime