デザイナーとして動き方の変化

2023年6月23日に行われた「デザナレ展 vol.2 | 優れたチームのすごいラフを一挙公開！リアルで見知れるデザイン展」で発表した内容を加筆修正したものです。 https://vivivit.connpass.com/event/285606/

Transcript

1. デザイナーとして動き方の変化 榎本直
2. CONFIDENTIAL 自己紹介 自己紹介
3. 経歴 海外の大学で4年半グラフィックデ ザインを学ぶ → 新卒で株式会社 Goodpatchに入社 → 2020年 SmartHRに入社
4. サービス紹介
5. CONFIDENTIAL page title
6. CONFIDENTIAL
7. SmartHRにおけるデザイナーの役割
8. チームの体制や個人のデザインに対するアプローチの仕方で SmartHRのプロダクトデザイナーの動き方は全く違う チームA デザイナーA アクセシビリティ チームA デザイナーA アクセシビリティ ≠ チームB デザイナーB フロントエンド チームB デザイナーB フロントエンド ≠ チームC デザイナーC ユーザーリサーチ チームC デザイナーC ユーザーリサーチ ≠ チームD デザイナーD UI チームD デザイナーD UI
9. チームメンバーの構成、チームの状況、会社の状況、色々な変数が あってデザインプロセスを変えていった チームA ??? チームA ??? チームB ??? チームB ???
10. 2つの事例を実際のデザインファイルと共に紹介
11. ÇÄ 人事評価機能
13. ​「どのシートを見ればいいの？」「どこに評価を書いたらいいの？」といった相談がと ても多かったですね。SmartHR人事評価にしたことで、こういった問い合わせが減っ たのは、使いやすくなった証拠かなと。​ ​「どのシートを見ればいいの？」「どこに評価を書いたらいいの？」といった相談がと ても多かったですね。SmartHR人事評価にしたことで、こういった問い合わせが減っ たのは、使いやすくなった証拠かなと。​ いまSmartHRを使っている人は人事評価機能の優れたUIやUXも気に入るはず いまSmartHRを使っている人は人事評価機能の優れたUIやUXも気に入るはず 引用: https://mag.smarthr.jp/guide/user-story/yappli/ 権限設定の柔軟性がすごい
 マニュアルを見ずとも、GUIで操作が理解できる。でもヘルプページは親切 権限設定の柔軟性がすごい
 マニュアルを見ずとも、GUIで操作が理解できる。でもヘルプページは親切 引用: https://note.com/ayumu_watanabe/n/n4238aea96091 「計算機能」のおかげもあって、集計はかなりスムーズになりました。以前まで1週間 以上かかっていたのが、現在は2日にまで短縮できています。 「計算機能」のおかげもあって、集計はかなりスムーズになりました。以前まで1週間 以上かかっていたのが、現在は2日にまで短縮できています。 引用: https://smarthr.jp/case/schoo
14. 約1年の開発期間 2020/10 開発開始 2020/10 開発開始 2021/10 リリース 2021/10 リリース UID IA PMM PM / PdE UID IA PMM PM / PdE UID IA PMM PM / PdE PM PdE PdE PdE PdE PdE QA UXW UID IA PMM PM / PdE PM PdE PdE PdE PdE PdE QA UXW プロトタイピング / 技術検証
15. １ 「ボツ案の墓場」 2 他は気にしない
16. 通称「ボツ案の墓場」
17. 「もうブラウザのメモリの限界に近いよ」 1 ボツ案の墓場
18. 1 ボツ案の墓場 こんなぶっ飛んだ案もあった
19. 1 ボツ案の墓場 Q なぜそこまでボツ案を多く作ったのか？ A 完全に新しい領域だったので、
 （私含め）チーム全体で学習が必要だった
20. CONFIDENTIAL 今まで開発していた人材マネジメント機能とは全く違う ドメイン範囲（2020年当時） 1 ボツ案の墓場
21. ユーザーストーリー ユースケース オブジェクトの構造 プロトタイピング 技術検証 ドメイン業務の理解 プロトタイプ作成と情報の整理を交互に行うことで ドメイン業務の理解を促進 1 ボツ案の墓場
22. 1 あらためて現状のUIの課題をあげる 2 オブジェクトの依存関係のメモ 3 課題の依存関係のメモ 4 依存関係を整理して改善するUIの提案の模様 1 2 3 4 途中まで実装していたUIを元に実際のユーザーストーリー の理解を深め、そして1から作り直す 1 ボツ案の墓場
23. Q なぜそこまでボツ案を多く作ったのか？ A SmartHRの人材マネジメント機能の中でも かなり規模が大きく複雑だったから 1 ボツ案の墓場
24. CONFIDENTIAL リリースまでの期間(私調べ) 約 4ヶ月 約 6ヶ月 約 8ヶ月 約 9ヶ月 約 12ヶ月 ステークホルダーの種類 評価対象者 評価者 人事担当者 1 ボツ案の墓場
25. モーダル モードレス レイアウト フィードバック フィードバック 入力デバイス 入力デバイス Aa コントラスト コントラスト 1 ボツ案の墓場
26. もちろん、段階や状況に応じてパターン作る必要とそうじゃない時はありますが、常にUI にはユースケースや、ユーザーの文脈、あらゆる制約を満たした上でのパターンが存在する という可能性は捨ててはいけません。 そのパターンというのは、実際のプロダクトの構造やUIのインタラクションの選定、レイ アウトや色を含むビジュアルデザイン、全てに変数がありそれらを考える必要があります。 例えば、一つのユースケースをとっても、モーダルもしくはモードレスのどちらで表現する べきなのか、選択するというユースケースにおいてはラジオボタンなのか、チェックボック スになるのか。どちらでもユースケースは満たせるがどちらが、ユーザービリティを考えら れたUIになるのかを吟味しなければなりません。 引用: 社内ドキュメントより 1 ボツ案の墓場
27. 墓場はあらゆる可能性を残すための物 1 ボツ案の墓場
28. こんな会話きっとあるはず。 このUI要素はよく見受けられるから採用しよう。 このUI要素はよく見受けられるから採用しよう。 他社はこういう風なUIなので真似しよう。 他社はこういう風なUIなので真似しよう。 2 他は気にしない
29. UIのレファレンス集めや競合製品のUIの調査は 全く行わなかった。 2 他は気にしない
30. DBのスキーマやプロダクトの構造 インタラクションや細かいビジュアルデザインも全て 「ユーザーがどう使うべきか」が反映されるべき。 2 他は気にしない
31. 例え競合製品間でユーザー像が似ていたとしても ユーザーやプロダクトを取り巻く環境など細かい所で差は出るはず。 ≠ 競合プロダクトA 競合プロダクトB UIが良いプロダクトC 2 他は気にしない
32. 逆に他を気にするとツギハギのようなUIになってしまう 競合製品A の良い所 有名プロダクトD の良い所 有名プロダクトC の良い所 競合製品B の良い所 2 他は気にしない
33. ちゃんとあなたが作ってるプロダクトのユーザーに向き合えば 別に新しいUI、一見馴染みのないUIが生まれたっていい。 自ずとお互いが適応するはず。 2 他は気にしない
34. 私達がつくったのは という システム。向き合うのは競合製品や有名プロダクトでもなく そのシステムとそれを使うユーザーとユーザーのドメインだけ。 「SmartHRにおける人事評価」 2 他は気にしない
35. ÉÅ 開発中の新規機能
36. 昨年末 ぼちぼち始動 昨年末 ぼちぼち始動 まだまだ始まったばかり
37. １ 高機能なデザインツールに縛られる日々 ２ ゆるふわなFigma
38. ベクター編集 ベクター編集 プロトタイピング プロトタイピング アニメーション アニメーション Dev Mode Dev Mode コンポーネントライブラリ コンポーネントライブラリ デザインシステム管理 デザインシステム管理 コラボレーション コラボレーション コード出力 コード出力 コメント機能 コメント機能 バージョン管理 バージョン管理 プラグイン開発 プラグイン開発 オートレイアウト オートレイアウト タイポグラフィ タイポグラフィ フレーム管理 フレーム管理 セクション セクション ダークモード ダークモード Absolute Position Absolute Position Variants Variants コンポーネントプロパティ コンポーネントプロパティ 細かいビジュアルデザインの設定 細かいビジュアルデザインの設定 1 高機能なデザインツール
39. 1 高機能なデザインツール 人事評価機能のデザインプロセスでは、Figmaを使いすぎるあまり 整備にコストがかかり、開発速度の低下を感じていた。 またデザイナー以外が触れるコストや教育コストも一定はある。 チームでデザインしていくには良くない状態もあった。 コラボレーションを促進するためのツールで コラボレーションに悩むというジレンマ
40. 出典: https://goodpatch.com/blog/the-processes-of-design 1 高機能なデザインツール
41. 1 高機能なデザインツール 戦略 戦略 要件 要件 構造 構造 骨格 骨格 表層 表層 私の解釈はこんな感じ。 ジャンプする時もあれば 逆に戻ることもある。
42. 1 高機能なデザインツール 「形」の品質に最終責任を持つデザイナーだからこそ 理想の形から入って適当な仮説を見出していく 「アブダクション」の頻度を高めて、高品質かつ高速でプロダクトを 作る方法を模索した。
44. 1 高機能なデザインツール スプリントレビューメンバー チーム イテレーションを最速で やるため実装まで「手描き」でやり続けた。 UXW PD SP DM CS PMM PM PdE 概念の整合性 命名 概念の整合性 命名 ユーザーストーリー ユースケース ユーザーストーリー ユースケース SmartHR UIやDB との整合性や プロダクトの拡張性 SmartHR UIやDB との整合性や プロダクトの拡張性 ビズサイドの視点 ビズサイドの視点 PD = プロダクトデザイナー DM = ドメインマスター = 手描きファイル
45. 1 高機能なデザインツール Q なぜ上手くいったのか？ A 比較的シンプルだったし、 何よりチームの共通認識を多く持てていた
46. 1 高機能なデザインツール 今回はチーム組成時から多くの共通認識を持てていた。 SmartHR UI チーム ドメイン知識 Webに対する知識 他プロダクトの知識 DB
47. 1 高機能なデザインツール 本質的な議論を高速で出来る 表層やインタラクションにとらわれず、プロダクトの核となる要件や構造だけで議論をしました。 またフィードバックから修正までの時間がほとんどかからずモブデザインを最大限まで効率化できます。 他の人もプロトタイプを作れる 手描きなので、特別なスキルは必要ありません。最低限可視化することができれば 一緒にUIを設計できますし、最悪描けなくても、要件を聞けばその場で私がパターンを手描きで量産し ていました。 紙とペンさえあればできる デジタルである必要もないですし、PCの前に座っていてもいいアイデアは生まれないはず。 手描きであればいつでもどこでもUI設計が出来ます。
48. 2 ゆるふわなFigma Figmaで実装用データを成形したあとでも あえて詳細なデータを作らなかった
49. デザインファイルを作りすぎない / これが正でないという姿勢を見せることで 自分が執着しすぎない / チームメンバーがUI設計に関与できる余地を作る もうこれは決まってるんですか？ もうこれは決まってるんですか？ ここはこういう風にするのが良いと思います ここはこういう風にするのが良いと思います 一応この方針で行きたいのですが、変更の余地は全然あります。 一応この方針で行きたいのですが、変更の余地は全然あります。 どういう形が理想だと考えますか？ どういう形が理想だと考えますか？ 2 ゆるふわなFigma
50. 結論
51. じゃあ、あなたはFigmaを触らずに、今何をしてるの？
52. 最近は バックエンドを書いたり、 フロントエンドを書いたり QAしたり、セールスの方と情報交換したり
53. UI UI U X W U X W Q A Q A ビ ズ サ イ ド ビ ズ サ イ ド 利 用 者 利 用 者 P M P M 会 社 会 社 バ ッ ク エ ン ド バ ッ ク エ ン ド フ ロ ン ト エ ン ド フ ロ ン ト エ ン ド UIが各職種との界面だからこそ、色んな所に UI設計 / 改善のアイデアがある
54. デザイナーの役割はツールで フィニッシュワークを作ることではないはず。 各職種と密接に融けるデザイナーだからこそ 自分の役割を変えてプロダクトを開発していこう。