デザインの言語化を振り返る

デジタルエクスペリエンス部所属の内田です。
アピリッツではこの2月に新しい期が始まりました！区切りの機会に、この1年を振り返ってみたいと思います。
個人的にはこの1年で「デザインの言語化を強化する」という目標を立て、日々試行錯誤してきました。今回はその成果や反省点を振り返ります。

デザインの言語化が必要な理由

デザインの言語化を強化したいと思ったのは①お客様にデザインを説明するときと②コーディング以降の工程の2つの段階でその必要性を実感したためです。

①お客様にデザインを説明するとき

デザインがなかなか決まらない

デザイナーなら誰しも経験するこの場面。単にクリエイティブが上達すれば回避できるわけではないことを薄々感じ始めていました。
デザイン決定までには様々な調整が必要となります。そんな中で、デザインがイメージ通りでない時に、お客様もまたどう直してほしいかうまく言葉にできていないことに気づいたのです。

そこでこちらがデザインを提出する際に、
〇〇なニーズや課題がある（説明）→だからこういうレイアウトや色にしました（ビジュアル）
というように説明とデザインをセットで提示するようにしました。

お客様にはまずその説明を読んでいただけるため、その課題感や解決策について認識合わせができ、それがビジュアル化されたときの細かいニュアンスについて説明した言葉をもとに微調整が可能になります。
こうすることで考え方の方向性が違うのか？細かいビジュアル調整だけでいいのか？などがコミュニケーションの中で明確になり、デザイン決定までの意志疎通がスムーズになったと実感しています。

スピード感のある制作と決定が必要となった

MVP開発やアジャイル開発が多くなった昨今では、毎工程ワイヤーフレームをじっくり考案し、それをもとにデザイン制作…といった決まった工程が繰り返されるわけではありません。システムや事業担当者の検討会議では実際のデザインをもとに議論をしたいという場面も発生しました。

その中でデザインを考え、説明を準備して提示していく…となると、スピードを上げたいにもかかわらず工数が増加してしまいます。

そのため、事前に論点を絞って重要な課題をピックアップしてから作業することで、必要なデザインだけを効率的に作成しました。
始めにテキストベースで整理されていると、そのまま説明資料にも活用できるため便利です。

また、説明資料では毎回共通のフォーマットを使用しました。デザイン確認に精通していない人でも認知負荷がかからず理解しやすくなるようにするためです。
「デザイン確認に精通していない人でも認知負荷がかからず理解しやすい」ということがとても重要で、共通フォーマットで説明とデザインの併記を徹底することで、解決したい課題や行うべき施策といった本質的な議論に集中できる環境を作ることができたと感じています。

②コーディング以降の工程

大きなプロジェクトになると自分で作成したデザインを他のメンバーにコーディングしてもらうことが増え、コーダーさんやエンジニアさんととの関わりが増えていきます。それと同時に次のような問題も増えました。

意図したデザインとなんか違う…？

まずこれは「デザイン通りの見た目になっていない！」という話ではないことを前置きしておきます。
デザイン通りの見た目になっている上で、出来上がったものが、なんだか、ちょっとだけ、意図したものと違うのです。

状態変化のパターンや既存or新規で作ると影響範囲がどうなのかなど……様々なことを考えデザインが出来上がるも、そのデザインの経緯や理由が伝わっていないと実装時にそれらが反映できず、不要な工数やコードが積みあがってしまう危険性があります。

そのような悲しい状況を防ぐためにも、デザインファイル内に細かくデザイン意図を記載し、コーディング担当者へ向けてデザインの経緯や理由・指示を書き込むようにしました。

例としては、このような感じです。

• ここは大小さまざまな写真が入る予定なのでcssは〇〇の指定にして写真がすべて同じ大きさに見えるようにしてください。
• このリンクはページ下部の△△へのアンカーリンクです。ヘッダーが追従してくるので移動後に見出しが隠れないようにお願いします。

思い返してみると、動的にデータが入る部分や移動を伴う要素への注意書きが多い気がします。

無駄な確認工数が発生する　

こちらもまず前提を話しておくと「いちいち聞かないで！」みたいな話ではありません！！
「だいたいよく発生するコミュニケーションって決まってるから、決まった場所によく聞かれることがまとまっていれば効率がいいのでは？」という発想になったお話です。

どんなプロジェクトでも途中でメンバーの出入りが発生しますし、その度に「この案件とは…」という共有ミーティングが開催されます。
また、プロジェクトが大きくなればなるほどファイルの種類や規模も大きく、すべてを把握することが難しくなってきます。

そこで、案件の基本情報やデザインファイルの場所を記載したドキュメントを作成しました。Slackの案件チャンネルなどにピン止めしておけば、プロジェクトに新しいメンバーが加わる時や探し物がある時に便利です。

さらに、デザインファイル内でも基本的なデザインルールや使用できる値を明確にしておく（デザイントークンを作成する）ことで、複数人で作業する場合や、規模が大きくなってきたときに一貫性のあるデザインが作成できます。

結局はコミュニケーション

ここまでデザインの制作と連携をスムーズにするために行った様々なことを振り返ってみました。もちろん言葉や伝え方に気を使えば使うほど、自分の意図の伝わらなさに落ち込んだり、他の人の意図をうまくくみ取れなかったりして、コミュニケーション面で「難しいなぁ」と感じることが多々ありました。

しかし「デザインの言語化」も結局はどうコミュニケーションをとって他業種の人や作業者同士で連携していくかということに終始しているように思います。
なぜなら、その方法について調べたり試したりする中で、私だけでなく、多くの仲間が同じ問題に直面していることに気づいたからです。

そのような課題を解決しようと行動することは”DesignOps”と呼ばれ、専任の担当者やチームまで誕生している企業もあります。
自分のやってきたことはDesignOpsの中のほんの一部かもしれませんが、もっと周りの業務を効率化してデザインの質を高めていこうという気運が高まっているのは確かです。

2023年はそんなDesignOpsをもっと深堀りしつつ、よりよいものを作っていきたい！という新たな目標を立て、新しい1年を頑張っていこうと思います。