design system ops関連のメモ

But who will bridge the gap between the design systems team (often part of the UX team) and the engineering team?

I call these enablers Design Systems Ops.

デザイナーのチームとエンジニアのチームの間のギャップを埋めるのがdesign system ops

In most companies, the delivery process from the concept to the user is so disjointed that the products feel nothing like what the designers first intended.

ユーザーに届くまでのプロセスで本来のデザイナーの意図したものは消え失せていきがち

A good design system helps make design decisions much faster (e.g. “what color should a call-to-action be”). Designers can then spend more time on user flows, and exploring multiple concepts in the same amount of time.

よいデザインシステムはデザインの意思決定を迅速にして、より多くの時間をユーザーフローなどに注力できる

A good design system also helps engineering teams refer to a single source of truth at the implementation phase. This is good for consistency, as all call-to-actions, for example, will look the same across screens.

よいデザインシステムは信頼できる唯一の情報源として実装フェーズでも助けになる

For a design system to show sustainable value at scale and at all phases of the delivery process, it needs proper planning, user research, and methods (and lots of love!).

持続的なデザインシステムには適切な計画や手法が必要

Design System Opsは、デザインシステムとその構成要素を運用し、標準化するための方法

チームの非効率な作業を減らし、ワークフローを最適化し、デザインシステムを普及させ、システムの拡張を簡単にすることができる

Design System Ops は、デザインと開発のギャップを埋めながら、ユーザーと製品に貢献するために、ワークフローの非効率性を削減しなければいけません。よって、新しいリリースがオリジナルのデザインの忠実度、機能性、使いやすさを反映するように、ツールとプロセスを導入することを目標としています。

総合的なテーマは、「エンジニアがより早くリリースを出せるように、いかにして意思決定を減らすか 」です。

Design System Opsは、ツールを導入することではなく、非効率な部分を発見して修正することです。

Adoption is the largest issue. A dedicated team's minimal ownership is the system's documentation and its methodologies. None of those functions have any value to your company if the design system is not used. If it is a little bit used, you are still dedicating personnel to documentation with very little observable implementation and methodologies that are not delivering.

採用されている度合いが最重要課題。使われていなければ価値がない。

Which brings us to scale: a design system's promise is only fulfilled when it reaches critical mass.

クリティカルマスに達したときに価値が出てくる。

So don't start your design system by entrusting everything to a dedicated team. They can burn themselves out trying to build everything then implement in the products (which is its own can of interfering worms). Or they might burn themselves building documentation and tools nobody actually uses or wants.

専門のチームに全てを任せるのはだめ。誰も使わないドキュメントやツールを作り続けるリスクがある。

Ensure the customers of the design system are on board, that they are listened to and know that their needs are the driving force behind the project. Ensure they know the dedicated team still requires their contribution and engagement.

プロジェクトの原動力としてデザインシステムのユーザーの意見に耳を傾ける。

システムをどれほど厳密または柔軟にするのか、システムの拡張性をどのように維持するのか、組織内の多様な部門すべての役に立つにはどうすればよいのか、といった課題の間には緊張関係があります。

At their core, design systems are contracts between designers, engineers and content writers.

デザインシステムの根幹はデザイナー、エンジニア、コンテンツライター間の契約というか制約

The further the design system's consumers are from the reasons behind the constraints, the more they will resent or discard them.

制約の背景を把握度合いが薄くなるほどそれを無視しやすくなる

Design system promoters must communicate about those constraints. They have to convince others of their usefulness: they are a cost, but what do they buy us? When the rules are constantly challenged, communication also involves listening. Why should the system change? How should it adapt?

デザインシステムの推進者は制約についてコミニュケーションをとっていく必要がある。

The second struggle comes with scale and the distribution of tasks. If your team is small and you don't have a dedicated full-time team, then you'll need people to do the work of one. Priorities are bound to be conflicting then, especially if the benefits of working on a design system are not clear (and agreed to) by everyone. When those people need to choose, they'll likely pick tasks that are on their main track.

タスク分配の課題。
専任チームがなければ、優先的に手をつけるメリット・理由がなく、対応されない。

There too communication is mandatory. If we want to push requirements, we need constant promotion. Promotion of the design system needs, of course. But promoting what satisfying those needs would achieve is a better point to stress.

専任チームの有無に関わらず、コミニュケーションが鍵。
何が得られるのかを伝えることが大事。

It's crucial to get the designers and developers on board. You want them as champions because the contract is binding them together.

デザイナーと開発者を味方にすることが重要。制約を守ってもらう対象なので。

You need them to ensure people are working for the design system...and you need them to let you work on it as well.

マネージャーにはリソース確保してもらう必要がある

But in my experience, product managers and product owners are incredibly powerful. They can have a deathgrip on the sprint planning, set on a punishing roadmap. Tasks that do not immediately get the product closer to these targets are easily dismissed.

プロダクトの目標達成に直結しないタスクは簡単に却下される

production teams won't try to convince their PMs and POs if you're not investing in that effort yourself.

プロダクト開発のチームは自分自身が関わらないのであればPMやPOを説得することはない

We often assume that the design system's mission of helping people build better products will garner goodwill. It's an easy mistake to make. It's not that people don't want to do better, but they do not have to trust that we know how to get there more than they do.

デザインシステムは好意的に受け入れられると勘違いしがち。それを信頼する理由がない。