「運用できるデザインを作るためにできること」 by 長谷川 恭久さん
なぜ共通言語が必要なのか?
一人でデザイン
作って終わりではない → 更新・改善が前提
必ずしもデザイナーだけがデザインするのではない
新しいツール(Sketch、Figmaなど)
一人のデザイナーがファイルを持つのではない
オーナーシップの変化(複数人で共有)
デザイナー以外もファイルを持つ
コンポーネント化(オレオレファイルからの脱却、その場その場のデザインからの脱却)
情報入り口の変化(SNS)→サイト外へ向けた制作の増加
認知の導線の変化
認知の役割は Web サイトはすでに持っていない
ソーシャル
広告
イベント
→ 一人で作るのは難しくなってきている。中規模でも一人では困難
Marketing Automation
A/B テストを自動化
無限のパターンをユーザー属性に応じて自動で配信
オープンソースのツール mautic
部品を組み合わせて配信 → コンポーネントベース
最高の見た目を目指してても回らない
デザイナー以外が画面設計、使えるツールを作る
固定で完璧なもの → 柔軟性の高い
他の人が見てもわかりやすいファイル作り・命名規則・レイヤ構成
正しい名前を使う NG例:「上の方にあるやつ」、間違えた名前
Bootstrap・Foundation ← コンポーネントの名前が似てるけど違う!
名前をチーム内でしっかり合わせる
グラフィックツールで作る限り、そのイメージはウソ
ちょっと変えただけで崩れるデザインだと使えない
→ もしもこうなったら大丈夫か(理想にならない場合)
同業者すら言葉があっていない
どのコトを話しているのか
どう合わせるか
→ 地味に聞いていく
聞いて一箇所にまとめる
→ ヒアリングして名前を決める
思考の視覚化
この場合どうなるのか?
5秒以上読み込みにかかったら...
ガイドラインにない言葉が行き交う
開発・デザイン以外の視点も考慮(マーケティングやmanager)
UI の機能、要求する機能を明確化
デザインの目的
以前: 品質を上げる
→ Web 関わる人が増加 → どこかでクオリティが落ちる
→ あるレベルより下には下がらないようにするために考える
共通言語を作る
ニュアンスの共有
「いい」の定義
チームにおける「いい」を定義 → ポスターのようにして貼りだす → 実装する機能が価値観に合っているか問う
ひっくり返る ニュアンスの共有ができていない
お客さんの大事にしている言葉・価値観をヒアリング ... 付箋で書き出す
マズローの5段階欲求的に分類する
一番下に身体的・心理的 安全(自分が認められているか) = 欠かせない価値観
同意を得た価値観に合っていることを示す
まずは言葉、必要であればその後にカスタマージャーニーマップ
① 自分達だけの言葉を作る
② 言葉を視覚化してニュアンスを深める
確実に「いい」ものを作るために
さらに進んだ新しいツール
使っているツールが全然違うから、共通言語が必要になる
→ 同じツール使えばいいじゃん(トレンド)
Framer
もはやコード
デザインもコードも同じ
Module
Phase
WebFlow
Studio
→ コードでデザインする(WebFlow や Studio はホスティングまで)
コードでデザインするツール
プロが使える高い表現力(細かな微調整もコードで行える)
ホスティングまで一緒にする