Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

nao
June 26, 2023

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

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

nao

June 26, 2023
Tweet

More Decks by nao

Other Decks in Design

Transcript

  1. デザイナーとして動き方の変化
    榎本直

    View Slide

  2. CONFIDENTIAL
    自己紹介
    自己紹介

    View Slide

  3. 経歴
    海外の大学で4年半グラフィックデ
    ザインを学ぶ → 新卒で株式会社
    Goodpatchに入社 → 2020年
    SmartHRに入社

    View Slide

  4. サービス紹介

    View Slide

  5. CONFIDENTIAL
    page title

    View Slide

  6. CONFIDENTIAL

    View Slide

  7. SmartHRにおけるデザイナーの役割

    View Slide

  8. チームの体制や個人のデザインに対するアプローチの仕方で
    SmartHRのプロダクトデザイナーの動き方は全く違う
    チームA
    デザイナーA
    アクセシビリティ
    チームA
    デザイナーA
    アクセシビリティ

    チームB
    デザイナーB
    フロントエンド
    チームB
    デザイナーB
    フロントエンド

    チームC
    デザイナーC
    ユーザーリサーチ
    チームC
    デザイナーC
    ユーザーリサーチ

    チームD
    デザイナーD
    UI
    チームD
    デザイナーD
    UI

    View Slide

  9. チームメンバーの構成、チームの状況、会社の状況、色々な変数が
    あってデザインプロセスを変えていった
    チームA
    ???
    チームA
    ???
    チームB
    ???
    チームB
    ???

    View Slide

  10. 2つの事例を実際のデザインファイルと共に紹介

    View Slide

  11. ÇÄ 人事評価機能

    View Slide

  12. View Slide

  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

    View Slide

  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
    プロトタイピング / 技術検証

    View Slide

  15. 1 「ボツ案の墓場」
    2 他は気にしない

    View Slide

  16. 通称「ボツ案の墓場」

    View Slide

  17. 「もうブラウザのメモリの限界に近いよ」
    1 ボツ案の墓場

    View Slide

  18. 1 ボツ案の墓場
    こんなぶっ飛んだ案もあった

    View Slide

  19. 1 ボツ案の墓場
    Q なぜそこまでボツ案を多く作ったのか?
    A
    完全に新しい領域だったので、

    (私含め)チーム全体で学習が必要だった

    View Slide

  20. CONFIDENTIAL
    今まで開発していた人材マネジメント機能とは全く違う

    ドメイン範囲(2020年当時)
    1 ボツ案の墓場

    View Slide

  21. ユーザーストーリー
    ユースケース
    オブジェクトの構造
    プロトタイピング
    技術検証 ドメイン業務の理解
    プロトタイプ作成と情報の整理を交互に行うことで

    ドメイン業務の理解を促進
    1 ボツ案の墓場

    View Slide

  22. 1 あらためて現状のUIの課題をあげる
    2 オブジェクトの依存関係のメモ
    3 課題の依存関係のメモ
    4 依存関係を整理して改善するUIの提案の模様
    1
    2
    3
    4
    途中まで実装していたUIを元に実際のユーザーストーリー

    の理解を深め、そして1から作り直す
    1 ボツ案の墓場

    View Slide

  23. Q なぜそこまでボツ案を多く作ったのか?
    A
    SmartHRの人材マネジメント機能の中でも

    かなり規模が大きく複雑だったから
    1 ボツ案の墓場

    View Slide

  24. CONFIDENTIAL
    リリースまでの期間(私調べ)

    4ヶ月

    6ヶ月

    8ヶ月

    9ヶ月

    12ヶ月
    ステークホルダーの種類
    評価対象者
    評価者
    人事担当者
    1 ボツ案の墓場

    View Slide

  25. モーダル モードレス
    レイアウト
    フィードバック
    フィードバック
    入力デバイス
    入力デバイス
    Aa
    コントラスト
    コントラスト
    1 ボツ案の墓場

    View Slide

  26. もちろん、段階や状況に応じてパターン作る必要とそうじゃない時はありますが、常にUI
    にはユースケースや、ユーザーの文脈、あらゆる制約を満たした上でのパターンが存在する
    という可能性は捨ててはいけません。


    そのパターンというのは、実際のプロダクトの構造やUIのインタラクションの選定、レイ
    アウトや色を含むビジュアルデザイン、全てに変数がありそれらを考える必要があります。


    例えば、一つのユースケースをとっても、モーダルもしくはモードレスのどちらで表現する
    べきなのか、選択するというユースケースにおいてはラジオボタンなのか、チェックボック
    スになるのか。どちらでもユースケースは満たせるがどちらが、ユーザービリティを考えら
    れたUIになるのかを吟味しなければなりません。
    引用: 社内ドキュメントより
    1 ボツ案の墓場

    View Slide

  27. 墓場はあらゆる可能性を残すための物
    1 ボツ案の墓場

    View Slide

  28. こんな会話きっとあるはず。
    このUI要素はよく見受けられるから採用しよう。
    このUI要素はよく見受けられるから採用しよう。
    他社はこういう風なUIなので真似しよう。
    他社はこういう風なUIなので真似しよう。
    2 他は気にしない

    View Slide

  29. UIのレファレンス集めや競合製品のUIの調査は

    全く行わなかった。
    2 他は気にしない

    View Slide

  30. DBのスキーマやプロダクトの構造

    インタラクションや細かいビジュアルデザインも全て

    「ユーザーがどう使うべきか」が反映されるべき。
    2 他は気にしない

    View Slide

  31. 例え競合製品間でユーザー像が似ていたとしても

    ユーザーやプロダクトを取り巻く環境など細かい所で差は出るはず。
    ≠ 競合プロダクトA 競合プロダクトB
    UIが良いプロダクトC
    2 他は気にしない

    View Slide

  32. 逆に他を気にするとツギハギのようなUIになってしまう
    競合製品A

    の良い所
    有名プロダクトD

    の良い所
    有名プロダクトC

    の良い所
    競合製品B

    の良い所
    2 他は気にしない

    View Slide

  33. ちゃんとあなたが作ってるプロダクトのユーザーに向き合えば

    別に新しいUI、一見馴染みのないUIが生まれたっていい。

    自ずとお互いが適応するはず。
    2 他は気にしない

    View Slide

  34. 私達がつくったのは という

    システム。向き合うのは競合製品や有名プロダクトでもなく

    そのシステムとそれを使うユーザーとユーザーのドメインだけ。
    「SmartHRにおける人事評価」
    2 他は気にしない

    View Slide

  35. ÉÅ 開発中の新規機能

    View Slide

  36. 昨年末 ぼちぼち始動
    昨年末 ぼちぼち始動
    まだまだ始まったばかり

    View Slide

  37. 1 高機能なデザインツールに縛られる日々
    2 ゆるふわなFigma

    View Slide

  38. ベクター編集
    ベクター編集 プロトタイピング
    プロトタイピング アニメーション
    アニメーション Dev Mode
    Dev Mode
    コンポーネントライブラリ
    コンポーネントライブラリ デザインシステム管理
    デザインシステム管理 コラボレーション
    コラボレーション コード出力
    コード出力
    コメント機能
    コメント機能 バージョン管理
    バージョン管理 プラグイン開発
    プラグイン開発 オートレイアウト
    オートレイアウト
    タイポグラフィ
    タイポグラフィ フレーム管理
    フレーム管理 セクション
    セクション ダークモード
    ダークモード Absolute Position
    Absolute Position
    Variants
    Variants コンポーネントプロパティ
    コンポーネントプロパティ 細かいビジュアルデザインの設定
    細かいビジュアルデザインの設定
    1 高機能なデザインツール

    View Slide

  39. 1 高機能なデザインツール
    人事評価機能のデザインプロセスでは、Figmaを使いすぎるあまり

    整備にコストがかかり、開発速度の低下を感じていた。


    またデザイナー以外が触れるコストや教育コストも一定はある。

    チームでデザインしていくには良くない状態もあった。


    コラボレーションを促進するためのツールで

    コラボレーションに悩むというジレンマ

    View Slide

  40. 出典: https://goodpatch.com/blog/the-processes-of-design
    1 高機能なデザインツール

    View Slide

  41. 1 高機能なデザインツール
    戦略
    戦略
    要件
    要件
    構造
    構造
    骨格
    骨格
    表層
    表層 私の解釈はこんな感じ。
    ジャンプする時もあれば

    逆に戻ることもある。

    View Slide

  42. 1 高機能なデザインツール
    「形」の品質に最終責任を持つデザイナーだからこそ

    理想の形から入って適当な仮説を見出していく

    「アブダクション」の頻度を高めて、高品質かつ高速でプロダクトを

    作る方法を模索した。

    View Slide

  43. View Slide

  44. 1 高機能なデザインツール
    スプリントレビューメンバー
    チーム
    イテレーションを最速で

    やるため実装まで「手描き」でやり続けた。
    UXW PD
    SP DM
    CS PMM
    PM
    PdE
    概念の整合性

    命名
    概念の整合性

    命名
    ユーザーストーリー

    ユースケース
    ユーザーストーリー

    ユースケース
    SmartHR UIやDB

    との整合性や

    プロダクトの拡張性
    SmartHR UIやDB

    との整合性や

    プロダクトの拡張性
    ビズサイドの視点
    ビズサイドの視点
    PD = プロダクトデザイナー DM = ドメインマスター = 手描きファイル

    View Slide

  45. 1 高機能なデザインツール
    Q なぜ上手くいったのか?
    A
    比較的シンプルだったし、

    何よりチームの共通認識を多く持てていた

    View Slide

  46. 1 高機能なデザインツール
    今回はチーム組成時から多くの共通認識を持てていた。
    SmartHR UI
    チーム
    ドメイン知識 Webに対する知識
    他プロダクトの知識
    DB

    View Slide

  47. 1 高機能なデザインツール
    本質的な議論を高速で出来る
    表層やインタラクションにとらわれず、プロダクトの核となる要件や構造だけで議論をしました。

    またフィードバックから修正までの時間がほとんどかからずモブデザインを最大限まで効率化できます。
    他の人もプロトタイプを作れる
    手描きなので、特別なスキルは必要ありません。最低限可視化することができれば

    一緒にUIを設計できますし、最悪描けなくても、要件を聞けばその場で私がパターンを手描きで量産し
    ていました。
    紙とペンさえあればできる
    デジタルである必要もないですし、PCの前に座っていてもいいアイデアは生まれないはず。

    手描きであればいつでもどこでもUI設計が出来ます。

    View Slide

  48. 2 ゆるふわなFigma
    Figmaで実装用データを成形したあとでも

    あえて詳細なデータを作らなかった

    View Slide

  49. デザインファイルを作りすぎない / これが正でないという姿勢を見せることで

    自分が執着しすぎない / チームメンバーがUI設計に関与できる余地を作る
    もうこれは決まってるんですか?
    もうこれは決まってるんですか?
    ここはこういう風にするのが良いと思います
    ここはこういう風にするのが良いと思います
    一応この方針で行きたいのですが、変更の余地は全然あります。
    一応この方針で行きたいのですが、変更の余地は全然あります。
    どういう形が理想だと考えますか?
    どういう形が理想だと考えますか?
    2 ゆるふわなFigma

    View Slide

  50. 結論

    View Slide

  51. じゃあ、あなたはFigmaを触らずに、今何をしてるの?

    View Slide

  52. 最近は

    バックエンドを書いたり、

    フロントエンドを書いたり

    QAしたり、セールスの方と情報交換したり

    View Slide

  53. UI
    UI
    U
    X
    W
    U
    X
    W
    Q
    A
    Q
    A
















    P
    M
    P
    M






























    UIが各職種との界面だからこそ、色んな所に

    UI設計 / 改善のアイデアがある

    View Slide

  54. デザイナーの役割はツールで

    フィニッシュワークを作ることではないはず。
    各職種と密接に融けるデザイナーだからこそ

    自分の役割を変えてプロダクトを開発していこう。

    View Slide