実装寄りの情報だけでは不十分 コンテンツだけでなくデザインも運用していきたいと考えたとき、デザインシステムを作ることが不可欠です。属人性を省きつつ、最低限の品質を担保することが可能なデザインシステムですが、作りさえすれば組織で広まるのかというと、そんなことはありません。 Salesforce の Lightning Design System、MailChimp の Design Patterns をはじめ、自社でデザインシステムを取り入れるためのインスピレーションは幾つか見つけることができますが、フロントエンド寄りになりがちです。早く Web サイトやアプリを実装するためのガイドラインなので当然ではあるものの、これだけではデザイナーがデザインシステムへの参加が難しくなる場合があります。多くの要因は「デザイン」と「コード」にある溝と大きく関わっています。 コードが分からないと参加が難しい

The Design for Serverless ETL Pipeline　データ分析基盤のレガシーなデータロードをサーバレスでフルリプレースするまで道のり

以下はChristian BeckさんのThe Path to Design System Maturityを翻訳したものです。日本語として表現が難しいか、文化の差などによって理解し難い一部の内容は意訳するか排除しました。 Carbon、Lightning、Clarity、Polaris、Plasma、Build。これらはスペースXのロケットの名前か、あるいは企業のデザインシステムの名前か？ 今のソフトウェア業界はもうDribbleをみて不安を感じるだけでは済まなくなった。上で並べたデザインシステムを見ていると、それらの半分にも及ばないものさえ作ってないことに恐怖をすら感じる。 しかし一流のプロスポーツ選手やミュージシャンのプレイを見るように、我らのほとんどはそれくらいの能力を持っていないことを認識することも大事だ。だからと言って全てを諦める必要もない。我らはこれらの最高レベルのデザインシ

A brief introduction: I’m Marcin: a former UX manager and now co-founder and CEO at UXPin — the full stack UX design platform. In this series of posts, I’m reporting on UXPin’s journey of creating our own design system. In the first post, I discussed the fundamentals of design systems (the why? the what?). Now, it’s time to get some work done! Here’s the story of how we kicked off the process of b

Your systems pitch got a green light. You’ve started designing, building, and documenting your library. Your first big release approaches fast! Hey, don’t forget your customers. During that formative period, you’ll begin aligning with product teams intending to adopt your system so that you can: Help them adopt based on an established modelDiscuss common system assumptions and misperceptionsPitch

The DSConf was a 2-day conference dedicated to Design Systems. Talks and workshops alike aimed to bring people together to exchange ideas, solutions and inspirations and show how Design Systems (a.k.a. DS) can help build better products more efficiently. The first day was a full immersive day with inspiring talks from 10 great speakers. This post is the first of two parts with some key takeaways f

#4 of 7 of the Documenting Components series: Overview | Intros | Examples | Design | Code | Authoring | Myths I remember that morning. September 2014. McLean, Virginia. I arrive for work around 7:30am. I open Google’s Material Design guidelines for the first time. I remember exactly where I stood, for 90 minutes, soaking it all in. It was so, so good. By the end, I didn’t just know Material bette

Visual examples are the most essential element of effective component doc. How do you best render, arrange, label, and order each one to with effective content (but not embedded guidelines!) to enable quick use and experimentation? There are many questions to answer as you set about composing examples spread widely across a library. What follows are 15 tips of how to best showcase components in yo

#2 of 7 of the series Documenting Components: Overview | Intros | Examples | Design | Code | Authoring | Myths Component Names: “My name is…”Naming a thing well is essential, and sometimes hard. A component’s name (Buttons) appears as the page’s title, a label in site’s navigation (Buttons), and a code identifier of a CSS class (-button) or HTML element name (<Button>). Button is easy. It’s a name

One way we write empowering content is by being aware of our voice and our tone. This section explains the difference between voice and tone, and lays out the elements of each as they apply to Mailchimp. What’s the difference between voice and tone? Think of it this way: You have the same voice all the time, but your tone changes. You might use one tone when you're out to dinner with your closest

UXPin Enterprise UX Industry Report 2017-2018 Share on Twitter Share on Facebook Share on LinkedIn Download full report In the Enterprise UX Industry Report, UXPin offers the first in-depth analysis of the challenges and trends for B2B product teams. How much of a problem does legacy technology pose? How do designer and developer ratios affect collaboration? Are long-term career prospects promisin

FT Product & TechnologyA blog by the Financial Times Product & Technology department.

(Living) style guides and (atomic) patterns libraries are “all the rage,” as my dear old Nana would’ve said. If articles and conference talks are to be believed, making and using them has become incredibly popular. I think there are plenty of ways we can improve how style guides look and make them better at communicating design information to creatives without it getting in the way of information