Hacker News new | past | comments | ask | show | jobs | submit login
Latitude Design System (flexport.com)
70 points by tosh 8 days ago | hide | past | web | favorite | 30 comments

One thing I keep noticing about design systems is that they all look extremely difficult to maintain.

On the development side, we all know that the more difficult/complex a unit testing suite is, the less likely it is to be effectively maintained.

All design systems I see are art directed. You have these very nice visual layouts showing each element of the system, with well crafted type explaining each aspect of it. It isn't a generated document; it's seemingly hand-crafted.

So my immediate thought is: is this versioned? What happens if it's updated? How should the changes at this stage propagate down to the individual teams who consume this design system? Maybe I'm not seeing the whole picture, but I have a hard time believing that these "design systems" are built for long term sustainability.

Design Systems are much like Frameworks you can either formalize and document the process or not but all this type of information has to live somewhere and be communicated.

The hard part here is that now with the rise of alternative tooling like Sketch, Zeplin, Figma and technologies like styled components, SASS, post css etc - there's a pretty broad range of ways to pull all this together so some of the implementation is going to be organization specific.

In general though we've found that developing design systems can greatly increase our throughput on new initiatives without having to reinvent the wheel on a lot of basics. There's some overhead but at least it makes for a transparent way to manage communication of a design.

Of note there's a great site https://designsystemsrepo.com/ that is a repo of a bunch of design systems. Great place to peruse.

When I look at design systems, it definitely seems like a good idea. But then when I take a step back and ask myself "what problem are we trying to solve?" my answer is:

we need to communicate the intent, behavior, and visual attributes of an application to (a) stakeholders for approval, and (b) developers for implementation. This communication is expected to update over time and potentially to several teams, though not all teams at once since they need to update their own designs in response.

When I think about ^THAT problem, I ask myself "is what I'm seeing in a design system the thing that Once And For All solves that problem?", the answer is no. There's something that doesn't feel sustainable to me.

Latitude isn't versioned. Flexport's internal monorepo tracks Latitude's master branch. When we make breaking changes to Latitude, we update all internal call sites too. For example, see https://github.com/flexport/latitude/pull/61 where we replaced our tooltip implementation. This approach has worked well for about 4 years so far.

As for docs, we do generate what we can (as explained by my sibling comment). But some pages (e.g. guidelines) are indeed hand-crafted.

By updating the tool tip Does the new component propagate out to all sites?


If you look at the code in the repo, each component has comments (jsdoc?) which are parsed and rendered as part of the storybook:

https://github.com/flexport/latitude/blob/master/Text.jsx#L6... https://www.flexport.com/design/components/Text

I'm intrigued by the possibility of using one of these design systems in some of my own work, but I'm likewise concerned about what it means for the long-term. Especially given that I'm not really a UI person first and foremost, I worry about an excessive degree of lock-in that will be hard to back out later if needed.

I haven't tried this one yet, but I'm playing around with the IBM Carbon Design System now for an internal side-project thing... depending on how that goes, I might start using that more widely.

On that note, I'd be really curious to hear from anybody who has used Carbon, and is willing to share their thoughts, pro or con.

I haven't used carbon as an engineer, but as someone working on design systems, they're overall pretty impressive.

For a giant menu of options, see here: https://github.com/alexpate/awesome-design-systems

Atlassian, Lightning, Blueprint, and Polaris are some big names that could be worth checking out. And of course there's always bootstrap.

> I'm not really a UI person first and foremost

Using another company's component library can be a really fantastic head start, then. Especially if you've got a smaller application that doesn't require the whole kitchen sink. You can build fast with stuff that works, and if down the line you want replace it with in-house components, you've already got a north star of sorts.

>I worry about an excessive degree of lock-in that will be hard to back out later if needed.

It depends. If you clone the repo and it works for you, you may not necessarily have to keep it updated if you don't want to. I would worry more about being bound to abstractions that are needlessly complex – many of these systems are designed so that small changes to upstream values propagate throughout the system in very deliberate ways, which can make tweaking intermediate values a bit of a landmine. Using a big ass codebase for a couple components means you might have to go spelunking in a big ass codebase.

Righteous! Thanks for the info.

I work on Spectrum, Adobe's design systems team.

>extremely difficult to maintain

Often yes. This corner of the industry is in the wild west days, and we've yet to establish best practices for a lot of things. Most DS teams are writing custom tooling. It helps a lot, but there are growing pains as we figure out which knobs need twisting and how to automate twisting them.

> All design systems I see are art directed.

To a degree. We make a LOT of compromises in the interest of maintainability and using visuals and abstractions that generalize well across platforms. Naming conventions, interaction styles etc are often chosen on the basis of being feasible on many platforms, even though that means foregoing some of the flasher stuff might only be appropriate on, say, iOS. Adobe specifically has a particularly heavy burden here, since we have so many properties spanning platforms from the last 3 decades. We could be a lot more adventurous if we had a smaller device footprint.

Accessibility is another big concern for us. Contrast ratios, text sizes, etc. Lots of the trendy low-contrast design practices don't fly in our system, and that's intentional.

>handcrafted vs generated

In Spectrum's case, the design documentation [1] (guidelines on usage, etc) do have custom content, though it adheres to a template and is inside a CMS that allows both editing by non technical contributors (content strategists, designers) and by script (markdown, etc). We have to strike a balance between optimizing for maintenance (autogen everything) and optimizing for content quality (expressive contribution from people that don't necessarily think of content in terms of automated maintenance).

Much of our "real" content is maintained in much more automated ways. The UI kits, for example, are generated from a JS + SVG lib that consumes our design tokens (variables for properties in the system across themes, platforms, languages, etc).

> is this versioned

Yes. It was an ordeal, but it was important and I'm glad we did it. Components are individually versioned and have a changelog. One of the main things we're versioning is more a snapshot of intent, and less a single specific code asset. Let's say button is version 5.0.0. Other parts of the system, like the CSS and react implementations, are independently versioned and track the design system version. This sounds messier than it is, though it's definitely imperfect.

> what happens if it's updated? How should the changes at this stage propagate down to the individual teams who consume this design system?

we update assets like the guidelines and UI kits on an as-needed basis. Some of this is automated. Some things, like our "don't" examples are created by hand, since definitionally the system doesn't do them. Some changes (bugfixes, implementation refactors, etc) don't require that the design artifacts change.

Our downstream customers (and the team itself) consume our data via a package of design tokens, which are issued as JSON. We update these values in accordance with changes to the guidelines, and those changes propagate to our customers and to our automated tools like the UI kit generator.

> long term sustainability

We're on year 4 or 5 here, and it keeps getting easier as we get better at it. Keeping the design tokens API fairly stable and extending support for previous versions where possible have been big factors in our long term success. While we aim to make update costs as cheap as possible, we also try not to pull the rug out beneath product teams that have slower release cycles and who are bought into previous versions of the system.

Happy to answer other questions.

[1] random docs example: https://spectrum.adobe.com/page/button/

Thanks for the reply! I'd love to ask more questions, but I should be honest and up front about why I made the original comment. I'm currently building a tool for these kinds of use cases, and I've been curious what pain points people are experiencing with current tools on the market. Every one that I've looked at has solved one piece of the puzzle, but I haven't found any that really nailed it IMO.

That's awesome! This space is still really, really ripe for tools. Looking at some of your past comments, it sounds like we're thinking about these problems / pain points in similar ways.

One of the things I observe that's potentially good for smaller players and less exciting to a team like mine is that ~80% of the market is web/react only, and very satisfied with things that are 1) narrowly scoped in terms of platform coverage 2) mostly about "stickers" or pictures of design, even as more advanced players are itching to design with more dynamic, deeply integrated component representations.

I'm curious about your thoughts on what it means to "nail it" with a full-scope / all-inclusive solution to design systems problems. Currently, I think that an ecosystem of smaller, more tightly scoped tools is the likely path forward. Designers will be plumbing together pipelines of modules that fit their specific needs, the same way a react project would today. I did a thread on this you might be interested in [1].

Feel free to ask whatever – anything I can say is fair game, and anything I can't say I wouldn't have said anyway.

[1] https://twitter.com/graphrick/status/1139964218243874816

Awesome, thanks a lot! I'll try not to prod too much, knowing that you work for Adobe.

As it happens, I am working directly in one of those areas you mentioned. I'm trying to create a nicely abstracted language that designers can use to describe components from a platform-agnostic angle. Something more nuanced and sophisticated than "pictures of design", but something that doesn't leak implementation details. A shared language that teams of designers can use to communicate not just with themselves, but also developers.

Is there more benefit to publishing a company’s design system than maybe some recruiting benefit? Is it about giving back to the design community or something IP/trademark related?

Depends on the company.

Some design systems are comprehensive, mature, and general enough that they're suitable for use by hobbyist devs or smaller orgs that want attractive, versatile UI components but don't want to spend effort spinning up something of comparable quality internally. Ant design comes to mind as one I see frequently.

The other benefit is companies that offer extensive third party integrations, like saleforce with their Lightning design system. By making the DS available, they let third parties build plugins that feel like a part of the platform, with high quality tools. This helps negate a lot of common problems with platform plugins that are ugly/unintuitive/broken.

Design system tooling (as opposed to UI component libraries) is more of a traditional open source / giving back dynamic. Theo from Salesforce and Style Dict from Amazon are widely used as part of the infrastructure underlying smaller companies' internal design system efforts, without going so far as to influence specific component implementations or visual styles. It's akin to FB and google opensourcing data infrastructure tooling.


I'm working on a design system at the moment and I have looked at a few for ideas.

Finally, a decent table component! Just what I was looking for my new project.

A nitpick concerning slow animations: there is no place for them in a modern enterprise app.

As you can see in the readme, we haven't made any accommodations for external adoption — the system is very opinionated at the moment (i.e. themes, styles, types).

But we were thinking perhaps we should spend some effort making it easier for others to use <Table /> elsewhere. How close to usable is it for your use case?

It is really fine as it is for me, the custom styles don't really matter for a B2B app I am working on. Just add an InlineEdit mode to a Table, and it will be better than any OSS table component there is today!

One thing about inline-editable components and tables. As a former office drone and a part-time speditioner, I believe that such components must be tabbable, and an ideal editable table should try to mimic the desktop experience. Office workers spend thousands of hours in backoffice apps, watching 0.3s animations and aiming with a cursor, but they never complain because they don't know any better.

Just to demonstrate a different InlineEdit, here is a demo of a lib I made several years ago. It worked great with tables and card views: https://kaivi.github.io/riek/

Also didn't your former colleague write up this post on data tables in 2017? It was trending here yesterday. Looks like a lot was already implemented back then: https://uxdesign.cc/design-better-data-tables-4ecc99d23356

On /design/styles, s/We belive/We believe/. Why the backticks everywhere? It's like somebody s/'/`/g'd the whole page. Also s/prop dependancy/prop dependency/. Not found on /design/components/Anchor. Not found on https://github.com/flexport/design, as DrinkWater has noticed w/ the correct link.

EDIT: my bad, INTERNALS is just a FB thing, I've just never noticed

Something is broken with the web when every company across every industry feels the need to produce its own design system.

Rather this then everyone just using a skinned version of bootstrap.

But honestly this is just design management starting to make a real improvement to how design works across teams and applications.

There seems to be a lot of push back here towards these systems and I'm not sure why. They just capture a ton of design information that already has to exist into a single place and tooling like React pairs great to break re-usable UI elements into common and shared components.

Design Systems are A Good Thing that's improving what has been a pretty broken system.

Are there changes to the web that you think would lift that burden, or make design systems less necessary?

Two major drivers come to mind in terms of DS adoption:

1) Giving teams a common toolkit of resources so that they can design consistent experiences without having to independently implement and maintain the same components.

2) It's really trendy. It's the designer equivalent of moving to serverless, or nosql years ago, etc etc. Small teams do it because it's cool and fun despite not necessarily feeling the enterprise-scale pains that originated some of the practices.

(I would not put flexport in that category. They've got an extremely data-intensive software, and a good component lib helps a lot there)

Sure, the HTML standard needs to go - it was designed for hyperlinked documents, not software.

Components should be provided by browser/OS vendors with a standard look and feel, the same way desktop software has been written for decades. React Native is a glimpse of what HTML of the future will look like.

Flexport is a logistics company. They aren’t in the business of selling software.

What we’re doing right now is like the first GUI desktop apps - lacking consistency because there was no solid platform every designer reinvented the wheel.

Thank god the browser provides the text input component otherwise every designer would have their own take on that too.

What seems broken about that? Do you think it's broken for each company to have a unique design for its website? Or do you think the "design systems" are the wrong way to architect the design of a website? Or something else?

Imagine if every Mac OS app had its own design system, styling and component implementation. That would be a nightmare for users. Yet this is exactly how web apps operate today.

“Websites” is this general term that is hard to define these days. Sure a landing page for a restaurant should have its own design, just as business cards do. But an application like Gmail? Probably not the same thing.

It's much much better than everyone adapting material design (ugh) or the default bootstrap theme.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact