Tweet
Tweet

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

渡邉哲平 株式会社アプリボット
 DX事業部 リードデザイナー
 2021年度 新卒入社 @tetchann

Slide 3

Slide 3 text

ゲーム開発の知見を生かした
 DX支援を行うアプリボットの事業部 要件定義から開発、サービスグロースまで
 一気通貫の共創事業を行っています

Slide 4

Slide 4 text

00 概要 DX事業部のデザイナーとして意識していること 少数精鋭チームによるスピーディで高品質な開発 今事業に求められることの優先度を見極めることが大事 BtoB SaaSからゲームまで、幅広いドメイン 事業領域ごとに求められる “品質” の定義は異なる 多様な開発形態に適応する必要がある 1つの手段を極めるだけでなく、いろんな手段を持っておく

Slide 5

Slide 5 text

アジェンダ 開発物の目的が擦りあっていない 目指すべき品質が擦りあっていない 要件を捉えきれずに機能を作ってしまう デザインのルールが整備できていない 仕様に抜け漏れが出てしまう 01 02 03 04 05

Slide 6

Slide 6 text

壁その1 成果物の目的が擦りあっていない

Slide 7

Slide 7 text

01 成果物の目的が擦りあっていない 起こりうる課題 細かいところに時間をかけすぎてしまう 大まかな画面構成を固めたかったのに、色やフォントなどに時間を割いてしまう パターンを考慮できていない エンジニアが実装工数を見積もりたかったのに、UIのパターンが考慮されていない

Slide 8

Slide 8 text

01 成果物の目的が擦りあっていない Y 開発物の全体像を把握するため7 Y 実装工数を見積もるため7 Y プロダクトの世界観を伝えるため7 Y 早く実装して使い心地を確かめるため？ 成果物の目的を事前に擦り合わせた

Slide 9

Slide 9 text

01 成果物の目的が擦りあっていない f 既存のUIキットを使って素早くUIを構X f デジタル庁デザインシステv f Figma UI Ki9 f ドキュメントツールを使って要件を言語2 f Figmaのプロトタイプ機能を使って触れる状態にす% f FigJamを使って画面遷移図をまとめる 目的に対する最適な成果物を考えた

Slide 10

Slide 10 text

既存のUIキットを使って素早くUIを構築 0→1のPoC作成に最適 デジタル庁デザインシステム FigmaのUIキット 01 目的に対する最適な成果物を考えた

Slide 11

Slide 11 text

01 目的に対する最適な成果物を考えた FigJamを使って画面遷移図を作成 開発メンバー向けにプロダクトの全体像を伝えるときや、条件分岐が多い機能を作る際に最適

Slide 12

Slide 12 text

Figmaのプロトタイプ機能を使って動く状態にする 使い心地を確かめたり、画面の抜け漏れを洗い出すのに最適 01 目的に対する最適な成果物を考えた

Slide 13

Slide 13 text

壁その2 目指すべき品質が擦りあっていない

Slide 14

Slide 14 text

02 目指すべき品質が擦りあっていない 起こりうる課題 目指すべき品質が定義できていない “使いやすい” サービスを作ろうとしているが、チーム内で言語化できていない スピードと品質のバランスを見誤る デザイナーが開発リソースに見合わない機能を作ろうとしてしまう

Slide 15

Slide 15 text

02 目指すべき品質が擦りあっていない プロダクトコンセプトの言語化 プロダクトコンセプト UIコンセプト ユーザビリティコンセプト グラフィックコンセプト q プロジェクトの目t q プロジェクトのゴーƒ q プロダクトの概g q ターゲッr q カスタマージャーニーマップ q どんな人に向けたUIにするf q どんな使いやすさを目指すか q どんな表現で伝えるべきf q どんな世界観で伝えるべきか

Slide 16

Slide 16 text

02 目指すべき品質が擦りあっていない プロダクトコンセプトの言語化 あるプロジェクトではデザインフローの前にチームでコンセプトの言語化を行なった

Slide 17

Slide 17 text

02 目指すべき品質が擦りあっていない ベンチマークの定義 ベンチマークA ベンチマークB ベンチマークD ベンチマークC ベンチマークE ベンチマークF

Slide 18

Slide 18 text

02 目指すべき品質が擦りあっていない ベンチマークの定義 ベンチマークA ベンチマークA 作りたいプロダクト ベンチマークB ベンチマークE ベンチマークF ベンチマークC ベンチマークE ベンチマークF UIのトンマナ 作り込み具合 インタラクション 機能の使いやすさ

Slide 19

Slide 19 text

壁その3 要件を捉えきれずに機能を作ってしまう

Slide 20

Slide 20 text

03 要件を捉えきれずに機能を作ってしまう 起こりうる課題 ユーザーや⁨⁩ステークホルダーからの意見を
 そのまま機能に落とし込もうとする 一見良さそうに見えるアイデアもプロダクト全体で考えた時に
 トレードオフがあるかもしれない 要件が曖昧なまま進行し、後から大幅な変更が必要になる デザインや実装の手戻りが発生してしまう

Slide 21

Slide 21 text

03 要件を捉えきれずに機能を作ってしまう 要件定義フェーズでの徹底的なヒアリング エンドユーザーと接点の多い関係者からのリアルな課題を直接聞いてみる バックログ
 アイテムの決定 課題の
 ヒアリング 要件定義書の
 作成 要件の
 すり合わせ ...

Slide 22

Slide 22 text

03 要件を捉えきれずに機能を作ってしまう トレードオフを考慮する 機能の追加によるメリットだけでなくデメリットについても考慮しておく 考慮すべきトレードオフの例： h 挙動の一貫性が失われていないか— h 他のUI要素の優先度が下がってしまわないか— h 他のユースケースにおいて不便を生じてしまわないか

Slide 23

Slide 23 text

壁その4 デザインのルールが整備できていない

Slide 24

Slide 24 text

04 デザインのルールが整備できていない 起こりうる課題 デザインの一貫性が保たれず、画面ごとに挙動が変わってしまう エンドユーザーにとっても使いづらさを生む温床となる デザインの意図がエンジニアに伝わらず、
 実装と乖離が生まれてしまう 想定と異なる挙動になってしまうだけでなく、開発の負債となってしまう。

Slide 25

Slide 25 text

04 デザインのルールが整備できていない 必ずエンジニアを巻き込んで進める ƒ デザイナー側でルールを作ったとしても、最終的にプロダクトに反映されていなければ意味がな€ ƒ 作ったルールをどのようにプロダクトに反映させていくか、エンジニアやPdMと相談しながら進める

Slide 26

Slide 26 text

04 デザインのルールが整備できていない デザインと実装で共通化するトークンを事前に定義 あるプロジェクトでは事前に以下のデザイントークンを定義し、Figma上でVariablesとして管理しQ ƒ カラg ƒ タイポグラフc ƒ ドロップシャドF ƒ 角D ƒ スペーシンp ƒ アニメーション

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

04 デザインのルールが整備できていない 作る過程でルールを明文化していく 開発初期段階ではあまりルールを設けずデザインのスピードを重視。必要になったタイミングで
 ガッツリ決める Tips: はじめに設計しておくと助かるルールの例  通知系コンポーネントの使い分け (トースト / ダイアログ / お知らせバナーなどx  入力画面における、未入力項目がある場合の対g  読み込み中におけるアニメーションの使い分け

Slide 29

Slide 29 text

壁その5 仕様に抜け漏れが出てしまう

Slide 30

Slide 30 text

05 仕様に抜け漏れが出てしまう 起こりうる課題 追加タスクの発生によりスケジュールに影響が出る 重要な画面を見落としたり、新たなエッジケースやエラー状態を発見したり 後から仕様を足していくことによる全体的なユーザー体験の悪化 なるべく初めから全ての状態を考慮してUIを設計できるとよい

Slide 31

Slide 31 text

05 仕様に抜け漏れが出てしまう 起こりうる課題 追加タスクの発生によりスケジュールに影響が出る 重要な画面を見落としたり、新たなエッジケースやエラー状態を発見したり 後から仕様を足していくことによる全体的なユーザー体験の悪化 なるべく初めから全ての状態を考慮してUIを設計できるとよい ただし、抜け漏れを完全に無くすことは難しい

Slide 32

Slide 32 text

05 仕様に抜け漏れが出てしまう 定期的に仕様の抜け漏れを 確認する会を作る 参加者が洗い出しやすいよう、目的に沿った 資料を用意しておV C 画面数の網羅 → Figmaのプロトタイt C エラー状態の洗い出し → 仕様書やユース ケース 仕様抜け漏れ洗い出し会の様子

Slide 33

Slide 33 text

まとめ

Slide 34

Slide 34 text

06 まとめ 開発フェーズごとに様々な解決策を持っておく “ デザイナーは開発組織のハブになりやすF “ つまり、開発における課題にいち早く気づける人物でもあ… “ デザイナーが感じている課題感をチームに伝え、一緒に開発フローを見直していくことが大事