エンタメ業界からDX領域に飛び込んだデザイナーが今立ち向かっている壁とは / applibot-dx-designer

私は2021年にデザイナー職として新卒入社し、音楽サービス「AWA」で2年間従事したのちアプリボットのDX事業部に異動しました。現在は事業部のリードデザイナーとして、20名ほどの小規模組織で製造業向けのWebアプリケーションを始めとした新規事業をクライアントと協業開発しています。ドメインも事業フェーズも違う領域に飛び込んだ私が、この1年間で学んだこと・今ぶつかっている壁についてお話しできればと思います。

https://cadc.cyberagent.co.jp/2024/sessions/applibot-dx-designer/

Transcript

2. 渡邉哲平 株式会社アプリボット
 DX事業部 リードデザイナー
 2021年度 新卒入社 @tetchann
3. ゲーム開発の知見を生かした
 DX支援を行うアプリボットの事業部 要件定義から開発、サービスグロースまで
 一気通貫の共創事業を行っています
4. 00 概要 DX事業部のデザイナーとして意識していること 少数精鋭チームによるスピーディで高品質な開発 今事業に求められることの優先度を見極めることが大事 BtoB SaaSからゲームまで、幅広いドメイン 事業領域ごとに求められる “品質” の定義は異なる 多様な開発形態に適応する必要がある 1つの手段を極めるだけでなく、いろんな手段を持っておく
5. アジェンダ 開発物の目的が擦りあっていない 目指すべき品質が擦りあっていない 要件を捉えきれずに機能を作ってしまう デザインのルールが整備できていない 仕様に抜け漏れが出てしまう 01 02 03 04 05
6. 壁その1 成果物の目的が擦りあっていない
7. 01 成果物の目的が擦りあっていない 起こりうる課題 細かいところに時間をかけすぎてしまう 大まかな画面構成を固めたかったのに、色やフォントなどに時間を割いてしまう パターンを考慮できていない エンジニアが実装工数を見積もりたかったのに、UIのパターンが考慮されていない
8. 01 成果物の目的が擦りあっていない Y 開発物の全体像を把握するため7 Y 実装工数を見積もるため7 Y プロダクトの世界観を伝えるため7 Y 早く実装して使い心地を確かめるため？ 成果物の目的を事前に擦り合わせた
9. 01 成果物の目的が擦りあっていない f 既存のUIキットを使って素早くUIを構X f デジタル庁デザインシステv f Figma UI Ki9 f ドキュメントツールを使って要件を言語2 f Figmaのプロトタイプ機能を使って触れる状態にす% f FigJamを使って画面遷移図をまとめる 目的に対する最適な成果物を考えた
10. 既存のUIキットを使って素早くUIを構築 0→1のPoC作成に最適 デジタル庁デザインシステム FigmaのUIキット 01 目的に対する最適な成果物を考えた
11. 01 目的に対する最適な成果物を考えた FigJamを使って画面遷移図を作成 開発メンバー向けにプロダクトの全体像を伝えるときや、条件分岐が多い機能を作る際に最適
12. Figmaのプロトタイプ機能を使って動く状態にする 使い心地を確かめたり、画面の抜け漏れを洗い出すのに最適 01 目的に対する最適な成果物を考えた
13. 壁その2 目指すべき品質が擦りあっていない
14. 02 目指すべき品質が擦りあっていない 起こりうる課題 目指すべき品質が定義できていない “使いやすい” サービスを作ろうとしているが、チーム内で言語化できていない スピードと品質のバランスを見誤る デザイナーが開発リソースに見合わない機能を作ろうとしてしまう
15. 02 目指すべき品質が擦りあっていない プロダクトコンセプトの言語化 プロダクトコンセプト UIコンセプト ユーザビリティコンセプト グラフィックコンセプト q プロジェクトの目t q プロジェクトのゴーƒ q プロダクトの概g q ターゲッr q カスタマージャーニーマップ q どんな人に向けたUIにするf q どんな使いやすさを目指すか q どんな表現で伝えるべきf q どんな世界観で伝えるべきか
16. 02 目指すべき品質が擦りあっていない プロダクトコンセプトの言語化 あるプロジェクトではデザインフローの前にチームでコンセプトの言語化を行なった
17. 02 目指すべき品質が擦りあっていない ベンチマークの定義 ベンチマークA ベンチマークB ベンチマークD ベンチマークC ベンチマークE ベンチマークF
18. 02 目指すべき品質が擦りあっていない ベンチマークの定義 ベンチマークA ベンチマークA 作りたいプロダクト ベンチマークB ベンチマークE ベンチマークF ベンチマークC ベンチマークE ベンチマークF UIのトンマナ 作り込み具合 インタラクション 機能の使いやすさ
19. 壁その3 要件を捉えきれずに機能を作ってしまう
20. 03 要件を捉えきれずに機能を作ってしまう 起こりうる課題 ユーザーや⁨⁩ステークホルダーからの意見を
 そのまま機能に落とし込もうとする 一見良さそうに見えるアイデアもプロダクト全体で考えた時に
 トレードオフがあるかもしれない 要件が曖昧なまま進行し、後から大幅な変更が必要になる デザインや実装の手戻りが発生してしまう
21. 03 要件を捉えきれずに機能を作ってしまう 要件定義フェーズでの徹底的なヒアリング エンドユーザーと接点の多い関係者からのリアルな課題を直接聞いてみる バックログ
 アイテムの決定 課題の
 ヒアリング 要件定義書の
 作成 要件の
 すり合わせ ...
22. 03 要件を捉えきれずに機能を作ってしまう トレードオフを考慮する 機能の追加によるメリットだけでなくデメリットについても考慮しておく 考慮すべきトレードオフの例： h 挙動の一貫性が失われていないか— h 他のUI要素の優先度が下がってしまわないか— h 他のユースケースにおいて不便を生じてしまわないか
23. 壁その4 デザインのルールが整備できていない
24. 04 デザインのルールが整備できていない 起こりうる課題 デザインの一貫性が保たれず、画面ごとに挙動が変わってしまう エンドユーザーにとっても使いづらさを生む温床となる デザインの意図がエンジニアに伝わらず、
 実装と乖離が生まれてしまう 想定と異なる挙動になってしまうだけでなく、開発の負債となってしまう。
25. 04 デザインのルールが整備できていない 必ずエンジニアを巻き込んで進める ƒ デザイナー側でルールを作ったとしても、最終的にプロダクトに反映されていなければ意味がな€ ƒ 作ったルールをどのようにプロダクトに反映させていくか、エンジニアやPdMと相談しながら進める
26. 04 デザインのルールが整備できていない デザインと実装で共通化するトークンを事前に定義 あるプロジェクトでは事前に以下のデザイントークンを定義し、Figma上でVariablesとして管理しQ ƒ カラg ƒ タイポグラフc ƒ ドロップシャドF ƒ 角D ƒ スペーシンp ƒ アニメーション
28. 04 デザインのルールが整備できていない 作る過程でルールを明文化していく 開発初期段階ではあまりルールを設けずデザインのスピードを重視。必要になったタイミングで
 ガッツリ決める Tips: はじめに設計しておくと助かるルールの例  通知系コンポーネントの使い分け (トースト / ダイアログ / お知らせバナーなどx  入力画面における、未入力項目がある場合の対g  読み込み中におけるアニメーションの使い分け
29. 壁その5 仕様に抜け漏れが出てしまう
30. 05 仕様に抜け漏れが出てしまう 起こりうる課題 追加タスクの発生によりスケジュールに影響が出る 重要な画面を見落としたり、新たなエッジケースやエラー状態を発見したり 後から仕様を足していくことによる全体的なユーザー体験の悪化 なるべく初めから全ての状態を考慮してUIを設計できるとよい
31. 05 仕様に抜け漏れが出てしまう 起こりうる課題 追加タスクの発生によりスケジュールに影響が出る 重要な画面を見落としたり、新たなエッジケースやエラー状態を発見したり 後から仕様を足していくことによる全体的なユーザー体験の悪化 なるべく初めから全ての状態を考慮してUIを設計できるとよい ただし、抜け漏れを完全に無くすことは難しい
32. 05 仕様に抜け漏れが出てしまう 定期的に仕様の抜け漏れを 確認する会を作る 参加者が洗い出しやすいよう、目的に沿った 資料を用意しておV C 画面数の網羅 → Figmaのプロトタイt C エラー状態の洗い出し → 仕様書やユース ケース 仕様抜け漏れ洗い出し会の様子
33. まとめ
34. 06 まとめ 開発フェーズごとに様々な解決策を持っておく “ デザイナーは開発組織のハブになりやすF “ つまり、開発における課題にいち早く気づける人物でもあ… “ デザイナーが感じている課題感をチームに伝え、一緒に開発フローを見直していくことが大事