2023年6月23日に行われた「デザナレ展 vol.2 | 優れたチームのすごいラフを一挙公開！リアルで見知れるデザイン展」で発表した内容を加筆修正したものです。 https://vivivit.connpass.com/event/285606/
デザイナーとして動き方の変化榎本直
View Slide
CONFIDENTIAL自己紹介自己紹介
経歴海外の大学で4年半グラフィックデザインを学ぶ → 新卒で株式会社Goodpatchに入社 → 2020年SmartHRに入社
サービス紹介
CONFIDENTIALpage title
CONFIDENTIAL
SmartHRにおけるデザイナーの役割
チームの体制や個人のデザインに対するアプローチの仕方でSmartHRのプロダクトデザイナーの動き方は全く違うチームAデザイナーAアクセシビリティチームAデザイナーAアクセシビリティ≠チームBデザイナーBフロントエンドチームBデザイナーBフロントエンド≠チームCデザイナーCユーザーリサーチチームCデザイナーCユーザーリサーチ≠チームDデザイナーDUIチームDデザイナーDUI
チームメンバーの構成、チームの状況、会社の状況、色々な変数があってデザインプロセスを変えていったチームA???チームA???チームB???チームB???
2つの事例を実際のデザインファイルと共に紹介
ÇÄ 人事評価機能
「どのシートを見ればいいの？」「どこに評価を書いたらいいの？」といった相談がとても多かったですね。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
約1年の開発期間2020/10 開発開始2020/10 開発開始 2021/10 リリース2021/10 リリースUIDIAPMMPM / PdEUIDIAPMMPM / PdEUIDIAPMMPM / PdEPMPdEPdEPdEPdEPdEQAUXWUIDIAPMMPM / PdEPMPdEPdEPdEPdEPdEQAUXWプロトタイピング / 技術検証
１ 「ボツ案の墓場」2 他は気にしない
通称「ボツ案の墓場」
「もうブラウザのメモリの限界に近いよ」1 ボツ案の墓場
1 ボツ案の墓場こんなぶっ飛んだ案もあった
1 ボツ案の墓場Q なぜそこまでボツ案を多く作ったのか？A完全に新しい領域だったので、 （私含め）チーム全体で学習が必要だった
CONFIDENTIAL今まで開発していた人材マネジメント機能とは全く違うドメイン範囲（2020年当時）1 ボツ案の墓場
ユーザーストーリーユースケースオブジェクトの構造プロトタイピング技術検証 ドメイン業務の理解プロトタイプ作成と情報の整理を交互に行うことでドメイン業務の理解を促進1 ボツ案の墓場
1 あらためて現状のUIの課題をあげる2 オブジェクトの依存関係のメモ3 課題の依存関係のメモ4 依存関係を整理して改善するUIの提案の模様1234途中まで実装していたUIを元に実際のユーザーストーリーの理解を深め、そして1から作り直す1 ボツ案の墓場
Q なぜそこまでボツ案を多く作ったのか？ASmartHRの人材マネジメント機能の中でもかなり規模が大きく複雑だったから1 ボツ案の墓場
CONFIDENTIALリリースまでの期間(私調べ)約4ヶ月約6ヶ月約8ヶ月約9ヶ月約12ヶ月ステークホルダーの種類評価対象者評価者人事担当者1 ボツ案の墓場
モーダル モードレスレイアウトフィードバックフィードバック入力デバイス入力デバイスAaコントラストコントラスト1 ボツ案の墓場
もちろん、段階や状況に応じてパターン作る必要とそうじゃない時はありますが、常にUIにはユースケースや、ユーザーの文脈、あらゆる制約を満たした上でのパターンが存在するという可能性は捨ててはいけません。そのパターンというのは、実際のプロダクトの構造やUIのインタラクションの選定、レイアウトや色を含むビジュアルデザイン、全てに変数がありそれらを考える必要があります。例えば、一つのユースケースをとっても、モーダルもしくはモードレスのどちらで表現するべきなのか、選択するというユースケースにおいてはラジオボタンなのか、チェックボックスになるのか。どちらでもユースケースは満たせるがどちらが、ユーザービリティを考えられたUIになるのかを吟味しなければなりません。引用: 社内ドキュメントより1 ボツ案の墓場
墓場はあらゆる可能性を残すための物1 ボツ案の墓場
こんな会話きっとあるはず。このUI要素はよく見受けられるから採用しよう。このUI要素はよく見受けられるから採用しよう。他社はこういう風なUIなので真似しよう。他社はこういう風なUIなので真似しよう。2 他は気にしない
UIのレファレンス集めや競合製品のUIの調査は全く行わなかった。2 他は気にしない
DBのスキーマやプロダクトの構造インタラクションや細かいビジュアルデザインも全て「ユーザーがどう使うべきか」が反映されるべき。2 他は気にしない
例え競合製品間でユーザー像が似ていたとしてもユーザーやプロダクトを取り巻く環境など細かい所で差は出るはず。≠ 競合プロダクトA 競合プロダクトBUIが良いプロダクトC2 他は気にしない
逆に他を気にするとツギハギのようなUIになってしまう競合製品Aの良い所有名プロダクトDの良い所有名プロダクトCの良い所競合製品Bの良い所2 他は気にしない
ちゃんとあなたが作ってるプロダクトのユーザーに向き合えば別に新しいUI、一見馴染みのないUIが生まれたっていい。自ずとお互いが適応するはず。2 他は気にしない
私達がつくったのは というシステム。向き合うのは競合製品や有名プロダクトでもなくそのシステムとそれを使うユーザーとユーザーのドメインだけ。「SmartHRにおける人事評価」2 他は気にしない
ÉÅ 開発中の新規機能
昨年末 ぼちぼち始動昨年末 ぼちぼち始動まだまだ始まったばかり
１ 高機能なデザインツールに縛られる日々２ ゆるふわなFigma
ベクター編集ベクター編集 プロトタイピングプロトタイピング アニメーションアニメーション Dev ModeDev Modeコンポーネントライブラリコンポーネントライブラリ デザインシステム管理デザインシステム管理 コラボレーションコラボレーション コード出力コード出力コメント機能コメント機能 バージョン管理バージョン管理 プラグイン開発プラグイン開発 オートレイアウトオートレイアウトタイポグラフィタイポグラフィ フレーム管理フレーム管理 セクションセクション ダークモードダークモード Absolute PositionAbsolute PositionVariantsVariants コンポーネントプロパティコンポーネントプロパティ 細かいビジュアルデザインの設定細かいビジュアルデザインの設定1 高機能なデザインツール
1 高機能なデザインツール人事評価機能のデザインプロセスでは、Figmaを使いすぎるあまり整備にコストがかかり、開発速度の低下を感じていた。またデザイナー以外が触れるコストや教育コストも一定はある。チームでデザインしていくには良くない状態もあった。コラボレーションを促進するためのツールでコラボレーションに悩むというジレンマ
出典: https://goodpatch.com/blog/the-processes-of-design1 高機能なデザインツール
1 高機能なデザインツール戦略戦略要件要件構造構造骨格骨格表層表層 私の解釈はこんな感じ。ジャンプする時もあれば逆に戻ることもある。
1 高機能なデザインツール「形」の品質に最終責任を持つデザイナーだからこそ理想の形から入って適当な仮説を見出していく「アブダクション」の頻度を高めて、高品質かつ高速でプロダクトを作る方法を模索した。
1 高機能なデザインツールスプリントレビューメンバーチームイテレーションを最速でやるため実装まで「手描き」でやり続けた。UXW PDSP DMCS PMMPMPdE概念の整合性命名概念の整合性命名ユーザーストーリーユースケースユーザーストーリーユースケースSmartHR UIやDBとの整合性やプロダクトの拡張性SmartHR UIやDBとの整合性やプロダクトの拡張性ビズサイドの視点ビズサイドの視点PD = プロダクトデザイナー DM = ドメインマスター = 手描きファイル
1 高機能なデザインツールQ なぜ上手くいったのか？A比較的シンプルだったし、何よりチームの共通認識を多く持てていた
1 高機能なデザインツール今回はチーム組成時から多くの共通認識を持てていた。SmartHR UIチームドメイン知識 Webに対する知識他プロダクトの知識DB
1 高機能なデザインツール本質的な議論を高速で出来る表層やインタラクションにとらわれず、プロダクトの核となる要件や構造だけで議論をしました。またフィードバックから修正までの時間がほとんどかからずモブデザインを最大限まで効率化できます。他の人もプロトタイプを作れる手描きなので、特別なスキルは必要ありません。最低限可視化することができれば一緒にUIを設計できますし、最悪描けなくても、要件を聞けばその場で私がパターンを手描きで量産していました。紙とペンさえあればできるデジタルである必要もないですし、PCの前に座っていてもいいアイデアは生まれないはず。手描きであればいつでもどこでもUI設計が出来ます。
2 ゆるふわなFigmaFigmaで実装用データを成形したあとでもあえて詳細なデータを作らなかった
デザインファイルを作りすぎない / これが正でないという姿勢を見せることで自分が執着しすぎない / チームメンバーがUI設計に関与できる余地を作るもうこれは決まってるんですか？もうこれは決まってるんですか？ここはこういう風にするのが良いと思いますここはこういう風にするのが良いと思います一応この方針で行きたいのですが、変更の余地は全然あります。一応この方針で行きたいのですが、変更の余地は全然あります。どういう形が理想だと考えますか？どういう形が理想だと考えますか？2 ゆるふわなFigma
結論
じゃあ、あなたはFigmaを触らずに、今何をしてるの？
最近はバックエンドを書いたり、フロントエンドを書いたりQAしたり、セールスの方と情報交換したり
UIUIUXWUXWQAQAビズサイドビズサイド利用者利用者PMPM会社会社バックエンドバックエンドフロントエンドフロントエンドUIが各職種との界面だからこそ、色んな所にUI設計 / 改善のアイデアがある
デザイナーの役割はツールでフィニッシュワークを作ることではないはず。各職種と密接に融けるデザイナーだからこそ自分の役割を変えてプロダクトを開発していこう。
naoenomoto
moriyuya
uxevents
onf
solmetts
dieckg
norinity1103
kawaiirailroads
uxaustralia
stephaniewalter
ajstarks
romanshamin
goodpatch
hannesfritz
3n
geeforr
smashingmag
keavy
phodgson
moore
sonatard
thoeni
ammeep
philhawksworth
jnunemaker