手戻りが少ないアトミックデザインの導入

こんにちは、クックパッド株式会社デザイナーの藤井(@kenshir0f)です。
業務では主にKomercoというサービスのデザインを担当しています。

Komercoは料理が楽しくなる料理道具やうつわ、調味料や食材など料理が楽しくなるモノが買えるアプリです。
料理に興味がある方はぜひ触っていただけたら嬉しいです。

さて、今日お話しする内容は新規事業でアトミックデザインを導入したお話です。これから導入を考えている方や、すでに導入している方の参考になればと思います。

Komercoでは立ち上げからリリースまでの間、サービスのデザインを一人で担当していました。
開発初期ではまだサービスの名前すら決まっておらず、ブランディングからロゴ、アプリの体験設計、インタフェースや開発用のデザインガイドラインなどを並行で作業する必要があり、上手に効率化を測りながらデザインしていました。

また、アプリは購入用、出品用と2つあり、エンジニア4人にデザインの仕様を指示する必要もあって、なかなかデザインデータを整理できず難しいな〜と悩んでいました。

デザインするにつれてカオスになっていくデザインデータ。。。辛いですね〜
なんとか上手に管理できる体系的なUIデザインデータ作成手法はないかなーと、調べているうちに見つけたのがAtomicDesignです。

藁にもすがる思いで記事を読んだ記憶があります...
調べてからメリット・デメリットを踏まえ、現状のデザイン環境にも噛み合いそうということで導入を決めたのですが、アトミックデザインに期待していたことは主に3つありました。

一つはデザインデータを管理しやすくなること。
二つ目はデザイン変更の適用がしやすく、かつその状況が目に見えて分かりやすくなること。
そして、それらを踏まえた結果、現状よりも作業スピードが上がっていることです。

実際に導入してみてどうだったか？
学びと反省を共有したいと思います。

アトミックデザインを導入するときのポイントは３つあります。
導入前、導入中、導入後それぞれでご紹介いたします。

まずはアトミックデザインを導入する覚悟とは？についてです。
覚悟とはなんぞや？と思う方もいると思いますが、

初めてアトミックデザインの思想を知ったとき、僕はとても興奮しました。
今まで体系的なUIデザインの作成手法を知らなかったこともあって、効率的にデザインできる環境を作れることにワクワクしたことを今でも覚えています。

何より名前がカッコいいですよね。アトミックデザインやってます！というのを一度言ってみたかったです。

そうなんです、すでにやっているかたは共感されると思いますが、思っていたよりもめちゃくちゃ地味なんですよね〜〜〜
構築は大変だしメンテナンスは頭使いつつ単純作業になるし、もちろん作業スピードは確実に上がりましたが、思っていたよりも普通でした。まぁ当たり前なんですが銀の弾丸ではないので...

最初の構築はもちろんそうなのですが、デザインしていない時間が結構多くなってしまうことが辛いなーと感じました。

こちらのスライドは横軸が時間で、発散と収束を繰り返すイメージで見ていただければと思います。
アトミックデザインの整理は、ある程度デザインしてから共通で使えそうなコンポーネントを後からマージして、それらを使ってデザインして整理してを繰り返す…みたいな感じで開発しています。

この整理整頓タイムが味気のない作業になりがちで、かつ開発の進捗を止めてしまうため想定よりも地味な作業だなと感じてしまいました。

もしこれから導入を考えている方は、あまり期待しすぎるとギャップにウッ...となるかもしれませんので、そこそこに期待するのがよいと感じました笑
また、定期的にディレクターや開発メンバーに整理のための時間確保を伝えることも大事だと思います。エンジニアリングでいうリファクタみたいなものなので、デザイナーもそういった時間がほしいと伝えれば作業する時間はもらえると思います。

次は導入中の学びをお話します。
アトミックデザインを導入するタイミングとその作業量に気をつけてください！ということについてです。

こちらは先程の図ですが、特に新規事業においては仕様変更が多いため定期的に整理整頓するのがベターだと考えています。

ですが、実際はこんなきれいに進まなかったです。。。失敗談を共有させてください。

まずやってみて感じたことは、導入するタイミングが少し遅かった点です。
ある程度デザインデータが肥大化してきたタイミングで整理整頓すべきか迷ったのですが、開発完了を優先して少し後回しにしてしまいました。
その結果、整理整頓時間が長くなってしまい、全体のデザインを整理し終わるのに籠もって3日くらいかかりました。

更にいうとですね...

初めてのアトミックデザイン化ということもあってコンポーネント化しすぎました。これが二つ目の失敗談です。
全てのデザインデータをコンポーネント化しようとして、一回しか使われていないモノに時間を書けたりすぐに削除になったものもあって、無駄に時間をかけてしまいました。
いきなり完璧を目指すのはダメだと分かっていたつもりでしたが、どこまでやるかは判断は難しかったですね...

ほとんどのデザインデータは使われなくなって削除されたりすぐ仕様変更で変わったりしてしまうので、いきなり完璧をめざすのは良くないなと感じました。

まとめると、導入時に気をつけるポイントは2つです。
一つはタイミングに気をつけてほしいこと。早すぎてもコンポーネント作成に時間取られてしまうのと変更によって更に時間を取られてしまうのであまりよくなくて、ある程度散乱してきたら収束させるようにするといいと思います。
もう一つは適度にやろうということです。頑張って作ったコンポーネントはだいたい使われなくなるので、無理に作りきらず他で使われることが多くなってきたタイミングでやると手戻りが少なく健全かなと感じました。

最後は導入して運用に入ったフェーズでの学びです。
曖昧さを許容しようというお話になります。

社内外問わずによく聞かれる質問ですが、コンポーネントの粒度は「チーム内の合意が取れている状態」であればよいと考えています。なので、厳密なルールは設けていません。
基本はデザイナーとエンジニアで話し合って決めているのと、開発のフェーズによってもコンポーネント自体を変化させています。

いきなりですが、例えばこういう問題です。
こちらをデザイナー、エンジニアの目線から見てみると、

デザイナー目線では基本的な形のボタンになるため、ButtonとしてAtomsに入れるのが直感的ですが、エンジニアの目線からするとボタンを押したときの処理によって実装が難しいことがあります。
例えばフォーム内のデータを変換してサーバーに送ったり、レスポンスが帰ってくる間はLoadingのアニメーションを走らせつつdisableにしたり、などを考慮しないといけません。そのうえで、ページ遷移も同じボタンでやりたいとなると、いきなり機能モリモリのボタンが出来上がってしまい、開発スピードが落ちてしまいます。

まずは「ユーザーさんのプロフィール画像をアップロードするボタン」など限定的なコンポーネントを雑に作ってしまい、その後で画像なら他のものと統合できそう、という流れで徐々に抽象化していくのがよいと考えています。

いきなり画像を送信できるButtonにしたとして、もしその機能を削除することになったら無駄に肥大化したButtonができてしまいます。

先程も述べましたが、厳密に作ることよりも開発スピードを上げるために工夫することがユーザーさんにすばやく価値を届けるためには大事なことだと考えています。

曖昧さを許容して、チームですばやく前に進む工夫をしましょう！

というわけで、アトミックデザインの導入について取り組んだことをお話させていただきました。
新規事業では多くの変更や手戻りが発生してしまいますが、どうやったらスピードを落とさずにデザインと実装をうまく繋げられるか、まだまだ試行錯誤している最中ですが、これから導入する方、導入している方の参考になればと思います。

それでは、

ではでは 👋