見出し画像

エンジニアとデザイナーがデザインシステムを一緒に作った話

こんにちは。UI/UXデザイナーの kotani(こにたん)です。
少し前まで担当していた SALON TOOL ( 以下、サロンツール )というアプリーケーションのデザインシステムを作った時の話を書きます。
今回はデザインシステムの中でも特に、エンジニアと協力した部分=コンポーネントの切り分け単位と命名について一緒に試行錯誤したお話です。

サロンツールとは

まず、サロンツールがそもそもどんなものなのかという話です。

サロンツールとは、個人集客できるミニモを、店舗で一括管理をしたいサロン様のニーズに応えた無料で使える予約管理システムです。サロンツールは、PCがあればサロンや自宅等どこからでも利用することができます。
画像:https://minimodel.jp/info/salon
テキスト:https://minimodel.jp/info/faq#salon

サロンツールチームでデザインシステムを作ることになったきっかけ

サロンツールは諸々の事情によりリニューアルをすることが決まり、エンジニアとデザイナー2人のチームができました。(リニューアルの理由はまた別の機会に)

それまで、私は別アプリのデザインを担当していたのですが、下の絵のように、デザイナーが思っているコンポーネントの分け方と実装で分け方が異なっていて、エンジニアとコミュニケーションがうまくいかないことが何度かありました。

二人きりのチームなのでリソースが少ないこともあり、こういった手戻りはなるべく避けたいということでチームのエンジニアが「デザインシステムというのをしっかり作るのが良さそう!その中でも特にコンポーネントの単位と命名をデザイナーエンジニアで同じ認識を持とう!」と提案してくれました。

たしかに、同じものを一緒に作っているのだから、2人の認識をしっかりと揃い、チームがデザインもエンジニアリングもできる1人が作ってるように振る舞えれば、今まで自分がぶつかっていた課題は解決できそうだと思いました。

コンポーネントの切り分け単位と名前をエンジニア、デザイナー間で一致させるためにしたこと

いざデザイナー / エンジニアで同じ分け方と名前のコンポーネントを使おうとしたときに行ったフローはこんな感じです。

【コンポーネントづくりのフロー】
① デザイナーが 1 つのページ(機能)のリデザインをする
② デザイナーが設計意図や法則性をすべてエンジニアに説明する(この時に、このへんで分けると良さそうだと思っているというのも伝える)
③ エンジニアがコンポーネントの切り分け方と命名の叩きを作る
④ 二人ですり合わせて合意が取れたら完成(合意が取れない場合は ② 〜 ④ を繰り返す)

キャッチボールのように作業を進めたおかげで、デザイナー / エンジニアのどちらかしかわかっていない。という本末転倒なことが、起こりませんでした💯

また、デザインはページごとではなくひとつのアプリ全体で一貫性を持たせなくてはいけないので、デザイナー間であればなんとなく分かるようなことでも丁寧に伝え、下記の画像のように資料として残しました。

ここで伝えておきたいのが、これらの全体にかかる設計思想についての資料を最初に作ったのかというと、そうでは無いということです。
もちろん設計思想は、初めに固めないとデザインができないので、プロジェクトの最初から自分(デザイナー)の頭にはありました。
しかし、それを反映させたモノがない状態でいくらエンジニアにそれを説明し理解してもらおうとしても、それは机上の空論でしかなく理解に時間がかかると思いました
そのため、全体理解については思想が反映されたモノを見せながら一緒に説明し、しっかりとまとめた資料はその説明をしながら徐々に完成していく。という風になりました。

atomic design を参考にしたけど、完全にそうではなかった。

コンポーネントの切り分け方は atomic design を参考にしました。( atomic design のわかりやすい記事 )

atomic design では、要素を「Atoms」「Molecules」「Organisms」「Templates」「Pages」の5階層に分けますが、コンポーネントとして用意するものは使いまわし可能な部分のみと決めていたので、実際に作って命名したのは、主に「Atoms」「Molecules」の2階層でした。

作りながら「Atoms」はパーツ、「Molecules」はパーツの配置方法=マージンという感じだね。と言う気付きもありました。

落とし所を探すのが難しかった部分

コンポーネントの最小単位を決めるのはかなり難しかったです。

例えばのボタンの場合、デザイナーはベタ塗りの色面に文字が載っている( 2 つのパーツの集まり)。エンジニアは文字の周りに色がついている(周りに色のついた文字)といった具合に、使っているツールが違う故の認識違いが起きていたからです。

こういった部分に関してはお互い根気強く説明して解決しました。
ちなみにボタンについては、ベタ塗りの色面と文字をバラバラには使わないので、エンジニアの考え方を採用しました。

コンポーネントの完成によって得られたこと

- 狙い通りスピード感があり手戻りの少ない開発ができるようになった
- ルールが決まっているので、UIの基礎設計に迷いがなくなり、結果的にUX設計や細かな表現に使える時間が増えた
- エンジニアと喧嘩しなくなった(大事)

なかなか分かりづらい部分も多いと思うので、質問等ありましたらコメント欄や twitter( @asamikotani )にぜひお願いします!
また、余力がある時に atomic design を使ってみて感じたことも書いてみたいと思います。



この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

note.user.nickname || note.user.urlname

サポートはこにたんの人生を豊かにするために使います。

🍺
123
クラフトビールが好きなデザイナーです。今はピースオブケイク社で働いています。

コメント4件

こんにちは、普段エンジニアをやっています。
記事読ませていただきました!
Atoms単位の切り分けで、ボタン以外にエンジニアと意見が分かれた要素等あったりしましたか?
もし、あれば教えていただきたいです!
実は職種が違うことで意見が真っ二つってことはそこまで多くなかったです。ただ、どうするか決めかねる部分は割とありました。

例えば、atomic design 原典では色やフォント (グリフ) も atom なので、おそらくアイコンの形そのものなども atom になります。
ただ、自分たちが作りたかった再利用の単位としての atom ( UI 上に単体で存在できる、かつ分解したら意味を成さない) を適応させた時に、色そのものやアイコンの形などそれ単体では意味を成さないので atom に入れるのはちょっと違うなあとなりました。(ここは atom の下に global という色そのもの、アイコンの形そのものなどを入れる階層を作るということで落ち着きました。)

それとはちょっと別でエンジニアの方はデザインシステムに乗せるためにわざわざ煩わしい書き方をしているところがあって、レビューの段階でレビュワーから「それもっと綺麗に書けるからそう直しなさい」と言われちゃって、調整が大変そうだった。ということがありました。
なるほど。丁寧にご回答ありがとうございます。
最後のレビュー段階が結構大事な要素な気もしますね。
今回の記事、自身にとってすごく学びになりました。ありがとうございます!
気に入っていただけて嬉しいです。ありがとうござます!
コメントを投稿するには、 ログイン または 会員登録 をする必要があります。