heedfull / tags / design teams

Tagged with “design teams” (1)

  1. Nathan Curtis – Building Scalable Design Systems and Style Guides » UIE Brain Sparks

    Nathan: I think you need to broaden your spotlight, because I don’t think either of those approaches is the best approach. The first one that ends up being a really negative approach is a mandate, coming out with some design system that everybody has to use. It’s massive. It’s sort of monolithic.

    It’s created by, hopefully, a representative subset of people, but to all the other people that didn’t have a voice, they won’t see it as legitimate. And so, mandating, particularly early on, isn’t going to work really well.

    The other thing that I have sensed doesn’t get as much traction is when people build things for themselves and then just open it up for other people to use if they want to, because think about platforms.

    If you’re designing for a Web-based marketing site, and you have all these Web-based products, and you have all these Android and iOS apps, and you might have a bunch of Windows apps that you also sell to your customers that are embedded in things like SQL Studio. All these things that don’t necessarily carry through all of the aspects of the core design language, for example, but could still benefit from aspects of the system.

    All these other people are going to dismiss you. Instead of like, “OK, that’s great. It’s a Web component. I have to use their big monolithic CSS file just so I can get a button. I’m not going to do that. I’m just going to build it myself.”

    The best teams can see beyond themselves and start to look at their design system as, in part, somewhat of an abstraction, and also they try to think about their design system in a more modular way.

    If you look at Google’s material design, I don’t know if this was exactly their intent, but there are separate parts that you can engage with. There’s the spec, there’s the description of how the design system works, and all its key parts of motion, space, color, the fab button, and so on.

    Separate from that, there’s a polymer library to build apps with. Separate from that, there’s a material design lite library to build sites with. Those are two separate things that if you’re building a site that if you want to use material design, suddenly that’s your ticket. But material design as its core is not necessarily a mandated, single toolkit for people to use. It’s a lot bigger than that.

    I think that the other thing that I’ve observed Salesforce writing about some is that they actually break down their design system into all its composed decisions. Essentially, their design system at its core is a bunch of design decisions that you break down into different property value pairs, primary color 1, primary color 2.

    How can you actually think about it in that way so that somebody building on a Window’s platform can suddenly engage with the iconography, the editorial concerns, and some of your design patterns, even though they’re not going to use your header component that goes on top of your website, because it’s wholly inappropriate in that kind of environment.

    If you can break it down into those different pieces, you have a better chance for not just having other people sense the value that you can provide for them, but you take a different mindset of instead of designing just for the product you’re working on, you’re just myopically, with horse-blinders on, you’re thinking a little bit more broadly about what you’re doing and the impacts it might have.

    https://www.uie.com/brainsparks/2015/09/09/nathan-curtis-building-scalable-design-systems-and-style-guides/

    —Huffduffed by heedfull