デザイン原則#

Turtle は以下の5つの価値を大切にします。

• Achieve Goals - エンドユーザーが効率的に目的を達成できるか？
• Bring out Abilities - クリエイターの能力を最大限に引き出せているか？
• Consistency - 一貫性を担保できているか？
• Design Intent - 設計の意図は明確になっているか？
• Evolve - 変化を恐れず進化を選択できているか？

なぜこの原則が必要か？#

Turtle は単なるコンポーネント集ではありません。以下の理由で、明確な原則が必要です。

• 迷った時の指針 - 開発中に判断に迷った時、この原則に立ち返ることで一貫した判断ができる
• 品質の担保 - 5つの価値に基づいて設計することで、高品質なデザインシステムを維持できる
• メンバー間の統一 - デザイナー、エンジニア、プロダクトマネージャー全員が同じ基準で判断できる

対象#

この原則は、Turtle のリソース全般 （Storybook, 開発フロー等を含む）に適用し、Turtle を利用する全てのクリエイターが迷った時の指針とすることができます。

ここでは、全てのクリエイターは次のように表現します。

• 利用者：Turtle を使うデザイナー、エンジニア、プロダクトマネージャー
• Turtle開発チーム：Turtle を開発するデザイナー、エンジニア、プロダクトオーナー

A. 効率的に目的を達成できる#

なぜこの原則が重要なのか？#

エンドユーザーもデザインシステム利用者も、誰もがストレスなく目的を達成できることが、プロダクト成功の鍵だからです。様々な制約を持つエンドユーザーでも、Turtle を使ったコンテンツを不便なく利用できるようにする必要があります。

以下の多様性を持つエンドユーザーを対象とします（近代科学社 2016年『人間中心設計入門』より引用）。

• 特性に関する多様性：年齢、性別、障害、一般的身体特性、人種と民族、性格、知識、技術など
• 指向性に関する多様性：文化、宗教、社会的態度、嗜好、価値態度など
• 状況や環境に関する多様性：精神状態、一時的状態、経済状態、物理的環境、社会的環境など

どう実現するのか？#

Should#

• エンドユーザー がどんな制約がある中でも決済までストレスなく完了できるよう、主要なシナリオのボタンの扱いをそろえる
• 利用者 がすばやくプロトタイプを作れるよう、汎用的なコンポーネントを揃えておく
• Turtle開発チーム が安定的に品質の高いコンポーネントを提供できるよう、チェックリストを整備する

Shouldn't#

• エンドユーザー に視力の制約があるにもかかわらず、非常に小さい文字サイズをデフォルトとする
• 利用者 の業務フローを深く理解できておらず、使いづらいコンポーネント提供の仕方をしている

B. クリエイターの能力を最大限に引き出す#

なぜこの原則が重要なのか？#

クリエイターが能力を最大限に発揮できる環境を提供することで、私たちの価値提供は、Turtle 利用者への価値提供、ひいてはエンドユーザーへの価値提供へと連鎖します。創造的で本質的な業務に時間を割ける環境を作ることは、全体の価値提供プロセスを円滑にすることに直結するはずです。

どう実現するのか？#

Should#

• 利用者 が単純なデザインやコーディング作業に使う時間を削減し、ユーザー体験向上に時間を多く使えるよう、必要なコンポーネントを取り揃える
• Turtle開発チーム が Turtle の品質をアップデートし続けられるよう、保守・運用の作業をできる限り自動化する

Shouldn't#

• 利用者 が導入の不便を感じているにも関わらず、統一性がなく検索性が悪いドキュメントを放置している
• Turtle開発チーム が使いづらさを感じているにもかかわらず、目先の工数増加を理由に抜本的な設計改善を後回しにする

C. 一貫性を担保する#

なぜこの原則が重要なのか？#

一貫性があることで、プラットフォーム全体で DMM らしさを表現するだけでなく、ユーザーの学習コストを低減し、ストレスのない予想通りの操作ができるようになります。

以下の3つの一貫性を担保します。

1. 設計の一貫性：props や命名規則の統一性
2. 視覚的な一貫性：フォーム要素の高さの一致やスタイルの共通性
3. 操作の一貫性：予想通りの振る舞いをさせる

どう実現するのか？#

Should#

• エンドユーザー が学習コストを低減できるよう、単一の目的に対しては単一のコンポーネントを利用する
• 利用者 がプロダクトを跨いだとしても一貫性のある画面設計がしやすいよう、コンポーネントの使い方をガイドラインとして示す
• Turtle開発チーム が認知負荷の低い開発が行えるよう、全てのコンポーネントでマークアップや props に一貫性を持たせて設計する

Shouldn't#

• エンドユーザー にとっては同じ目的にもかかわらず、視覚的にたくさんのバリエーションが存在する
• Turtle開発チーム の開発体験が悪いにもかかわらず、一貫性のない設計や開発フローが放置されている

D. 設計の意図を明確にする#

なぜこの原則が重要なのか？#

ソフトウェア設計では、なぜそれを行うのか（Why）、何を対象にするのか（What）、どのように実現するのか（How）を考える必要があります。しかし、仕様書やソースコードを見ても Why を後から知ることは非常に困難です。

意思決定の経緯は設計を考える上で非常に重要で、これらを後からでも知ることができるような仕組みが必要です。

どう実現するのか？#

Should#

• 利用者 が設計意図を知り改善要望を出しやすくなるよう、過去の設計意図や背景に誰でもアクセスできるようにする
• Turtle開発チーム が過去の理由や背景を知り無駄なく開発が行えるよう、設計や意思決定について ドキュメントや Pull-Request のコメントに積極的に残す

Shouldn't#

• 利用者 が Slack でコンポーネントの仕様について質問したが、誰も答えられなかった
• Turtle開発チーム が改善のため、あるコンポーネントの設計の意図を知りたいが、どこにもその理由が示されていないためいろんな人に聞いて回らなければならなかった

E. 変化を恐れず進化する#

なぜこの原則が重要なのか？#

Turtle は一度作ったものが完成形ではありません。私たちが目指しているのは、ニーズや環境の変化に応じて適切に変化していくシステムです。例えば、デザイン原則自体も時には懐疑的に評価し、見直しを検討する必要があります。

どう実現するのか？#

Should#

• エンドユーザー がストレスなく DMM プラットフォームを利用できるよう、ベストプラクティスとアンチパターンを考察した上でより優れた体験を追求する
• 利用者 のプロダクトが新しい技術のアップデートをしていけるよう、基盤である Turtle が率先して最新仕様・技術・ブラウザの進化に対応する
• Turtle開発チーム が Turtle を通じてプラットフォームを技術でリードしていけるよう、新しいことを学び続ける機会を作る

Shouldn't#

• 利用者 が Turtle をより良くするためのアイデアを持っているが、そのアイデアを Turtle に反映する機会を作れていない
• Turtle開発チーム がデザイン原則に欠陥があると認知しているにもかかわらず、思考停止して改善を怠っている