本記事は Goodpatchのインターン生が 自社サービスStrap の「エンジニア主導デザイン」タスクを取った話 〜概要編〜 の続きとなっています。
はじめに
株式会社グッドパッチ でエンジニアインターン中のちげと申します。「ハイキュー!!」と「映像研には手を出すな!」が好きなフロントエンドエンジニアです。現在、Strap というオンラインホワイトボードサービスの開発に携わっています。
Strap を開発しているエンジニアには「エンジニア主導デザイン」というタスクの種類があります。エンジニア主導でデザインを行うタスクです。「概要編」と「体験談編」の2つの記事に分けて紹介していきます。エンジニア主導デザインの概要について知りたい方は こちらの「概要編」 からどうぞ。
今回はインターン生として「エンジニア主導デザイン」タスクを行った実際の体験談をお話しします。
「エンジニア主導デザイン」タスクを取った背景
インターン中のある日、Strap の新規機能開発を任されました。「ボード内テキスト検索機能」の開発です。
上の画像のように、ホワイトボード内にあるテキストを検索する機能です。
この機能のデザインおよび実装が「エンジニア主導デザイン」タスクでした。
ボード内検索機能のエンジニア主導デザイン体験談を話す上で、わかりやすさのために以下の3つの観点に分けてみました。
- 開発背景と仕様の理解
- 技術的な目線でのデザインと設計
- UIに落とし込むデザイン工程
一番「エンジニア主導デザイン」らしい話は3番目かなと思います。
1. 開発背景と仕様の理解
仕様を決めるために開発背景を理解すること、使うユーザーとユースケースを想定すること、仕様とユーザー体験を結びつけて考えることはデザインを行う上で重要です。
機能の背景を理解する
私はインターン生として途中からJoinしたので、すでにテキスト検索機能の仕様がある程度まとまっている段階からのスタートでした。そこで、仕様の背景理解から始めました。仕様の背景が理解できていないと、設計やデザインができないからです。
仕様の背景が理解できる過去の議論は Strap のボードにまとめられていました。しかし、私は最初それを見ずに、PBIに書いてある仕様とちょっとしたチームメンバーからの共有だけで設計をスタートしていました。そのため、設計を行う上で「この仕様は必要なのか」「こうしたらいいんじゃないか」というような思考を1から行うことになってしまい、少々時間を浪費してしまいました。背景を理解することに時間を割くことが、最終的な効率化につながるんだなと感じました。「なぜこれをやるのか」を大事にするグッドパッチの文化の重要性を改めて感じました。
テキスト検索機能の根本にある背景は「過去に書いたテキストベースの情報を探したい」というニーズです。付箋やテキストが膨大にあるボード内で、書いた場所を忘れてしまった場合、どこにあったかわからなくなってしまうという問題がありました。その解決策としてテキスト検索機能の開発が始まりました。
また「タスクに自分の名前を書いておいたけど、自分にアサインされているタスクがわからなくなってしまった」などの、検索機能を作ることによって解決されるであろう細かい課題やニーズの掘り起こしも過去に行われていました。過去にどんな議論があったのかについてもチームメンバーに共有してもらいました。
ユースケース分析を理解する
では「テキストベースの情報を探したい」というニーズから、具体的にどのようなUIでテキスト検索機能を提供すれば良いでしょうか？
その答えを見つけるためのユースケース分析も Strap のボードにまとめられていました。どのようなユースケースが考えられるか。またそのユースケースはどんな機能で解決できるかがまとめられています。
このように Strap 開発チームでは、Strap の得意とする「簡単に図にまとめられる体験」をエンジニアもフル活用して、チームの意思決定の透明化に貢献しています。
体験フローと実装仕様を理解する
ユースケース分析で必要となる機能を洗い出して選別した後、どんな体験フローがあるか、どんな仕様で実装するかについての議論がありました。その議論も Strap にまとめられていました。
2. 技術的な目線でのデザインと設計
ここまでは、Strapチームのメンバーが過去に行ってくれていたことを理解するだけでした。ここからが実際に手を動かす私の仕事になります。
デザインはただ見た目を美しくするだけでなく、ユーザーの目的に寄り添う必要があります。その目的に寄り添えるよう、技術的な目線でデザインを行なっていきます。デザインという言葉には設計という意味も含まれています。目的に合うように設計するのはエンジニアの得意分野ですよね。
まず、この時点で決まっている仕様は以下のようになっています。
- 検索ボタンクリックで検索バーを開いたり閉じたりできる。バツボタンで検索バーが閉じる。
- あいまい検索でボード内の全てのテキストを検索
- 「次へボタン」で次のエレメントへ、「前へボタン」で前のエレメントへ、ボード内を移動する。最後のエレメントまで行くと最初へループする。
- 検索ヒット件数が表示される。
- ショートカットキーで操作できる。
これらの仕様から、実際に必要なボタンや Input 要素を配置し、検索の仕組みの実装と、仕様の調整に取り掛かりました。
検索ソートの仕様について
最初に引っかかったのは検索時のソートの仕様です。
Strapの検索機能は、ボード内を滑るように移動して検索結果を一つずつ表示していくスタイルです。しかし、ボードはほぼ無限の広さがあり、上下左右に空間が広がっています。そのため、検索結果をどんな順番で表示するか検討が必要で、以下3つの案がありました。
- 純粋に左から右へ、上から下へとヒットさせる案。
- 現在見えている画面内のエレメントを優先してヒットさせる案。
- 画面中央から外側へ順番にヒットさせる案。
他のエンジニアからは「パフォーマンスの都合上、画面外のエレメントを描画しないようにしているので、画面内のエレメントから順番にヒットさせた方がパフォーマンス的に良いのではないか」という意見が出ました。
その意見には目から鱗でしたし、賛同しました。 ただ、実際に実装してみないとわかりません。まずはソートの実装難易度と計算コストが低い、左から右へ上から下へとヒットさせるソートを実装しました。図形や付箋がピッタリ揃ってなくても順番通りになるよう、多少の位置ずれを許容する実装になっています。
実際に実装してみると、この純粋な検索ソートは Strap と相性が良さそうだと感じました。Strap では、左から右へ上から下へと自動でコネクター（矢印）をつなげる機能（スマートアド機能）があり、そのスマートアド機能で描けるツリー構造と似た順番で検索がヒットするからです。充分ユーザーの目的は達成されそうだと感じたので、ここでは実装コストを優先し、ひとまずこの仕様で開発を進めることにしました。
もし今後、実務で検索機能を使った時にパフォーマンスやソート順に違和感があれば、試験的に画面内のエレメントからヒットさせる仕様に変更するかもしれません。
このようにエンジニア主導タスクでは、実際に作ってみて動きを確認しながら、実装コストも考慮し仕様を決めていきます。
ショートカットの仕様について
次に論点となったのはショートカットの使用についてです。Macなら Cmd+F、Windowsなら Ctrl+F のショートカットで検索バーが現れて、検索の input に focus が当たります。計画段階での仕様では、検索バーを閉じる時のショートカットも同じショートカットを使う予定だったのですが、実際に触ってみて違和感がありました。
その違和感について分析すると、他のサービスでは Esc が使われていることが多かったので以下のような提案をしました。
過去の議論を共有いただいた上で、私の意見にも納得していただき、Esc で閉じる仕様が採用されました。
このような細かい仕様のすり合わせを踏まえ、私は仕様やコードとの戦いに頭が混乱しかけていました。"どんな実装方法で仕様を実現するか" と、"どんな仕様がベストか" が頭の中で混じってきてしまっていました。 その時、プロダクトマネージャーに Strap で図にまとめる方法をおすすめしていただき、複雑だったショートカットの動作仕様や実装方法を Strap にまとめていきました。
以下が実際に Strap で図解していったものです。数分で作れるので楽ですね。
ショートカットの仕様をまずまとめ、それぞれの細かい仕様に対してどう実装するのがいいかという思考の流れをビジュアライズしています。
思考をビジュアルに落とし込む作業は、デザインの現場では非常によく使われる方法です。このように図にしてまとめておくことで、自分の脳内整理に効果的なだけでなく、他のエンジニアやデザイナーさんからの質問返答や、意思疎通などの議論がやりやすいというメリットがあります。実際、自分の考えたことを非常にスムーズに他のエンジニアやデザイナーに伝えることができましたし、素早く的確にアドバイスを受けることができました。また、マウスカーソルを置きながら「コレは〜」というだけで「今何についての話をしているか」が正確に伝わるので、指示語が多くて話下手な私には嬉しいポイントでした。
情報整理や、わかりやすくビジュアライズ化する作業をデザイナーやマネージャーのスキル、専門技能に依存するのではなく、誰でもその恩恵を受けられるように Strap は設計されているんだなぁと改めて感じました。
スムーススクロールについて
スムーススクロールを行う関数はすでにありましたが、実際に使ってみると連続でスクロールさせた時にアニメーションがカクついていました。カクつくのは非常に美しくないですよね。
原因はスクロール中の関数アクセスをキャンセルしていたことでした。完全にスクロール移動が完了する前に、新たにスクロールしろと連続で呼び出してもちゃんとアニメーションがスムーズに行われるようにプログラムを変更しました。 このような細かいユーザー体験の向上も、エンジニア主導でデザインします。
3. UIに落とし込むデザイン工程
ここまでだけなら普通にエンジニアがやっていることですよね。「エンジニア主導デザイン」の名前の通り、もちろんUIデザインの検討も行いました。 Strapの検索機能は状態のパターンが多いので、実際の動きを見ながらデザインしていきます。
左が初期に作ったUIで、右が最終的に採用したUIです。
DOM 構造や CSS 的には初期に作ったUIの方がシンプルに記述できます。初期UIはとりあえず状態遷移やUIのイメージを掴むためのものだったので、シンプルな記述で十分です。ボタンに機能もついていません。
ある程度機能の実装が完了した段階で、細かいスタイリングの修正を行い、右のUIに落ち着きました。
再検索ボタンを追加
最初は再検索の仕様はなく、初期に作ったUIの段階では、再検索ボタン（検索アイコン）はコンポーネントが用意したアイコンで、何の機能もありませんでした。検索バーの表示/非表示ボタンとアイコンがカブるので消そうかと思ったくらいです。しかし途中で再検索の機能があったほうが良いと気づき、検索アイコンに再検索の役割を付与したデザインを提案しました。
しかも上記スクショを見る限り、この時点では検索バーの角丸の R が最終形より大きく、検索アイコンの背景のホバーエリアも角丸正方形になっていますね（最終形は円形）。このような小さなデザイン変更も実際の動作を見ながら行なっています。
ツールチップをつける
ボタンが並んでいるだけでは、どうやって使うのかわかりません。また、便利なショートカットの利用も促すためにボタンにツールチップを付与しました。ツールチップで表示する文字については、最低限の文字で機能が伝わるよう工夫しています。「検索」から「ボード内検索」へ変更したり、ショートカットの表記を追記したりしました。
ちなみにですが、ツールチップを表示するために、既にあったコンポーネントのCSSプロパティを編集する必要があり、他の場所でスタイル崩れが起きないか確認しながら進めなければならなかったので、作業には慎重を要しました。
細かい状態別のUIデザイン
検索機能には、各種ボタンや検索ヒット数を表示する機能があります。それらのスタイリングは現在の検索バーの状態によって変化します。
例えば、文字が未入力の状態では、検索ヒット数は表示されず、バツボタン以外のボタンは disabled 状態になって押すことができなくなっています。disabled状態ではアイコンが薄い灰色になり、マウスカーソルを重ねてもカーソルのデザインがポインター化しないようになっています。
このように状態遷移が多いUIコンポーネントの場合、表示・スタイル変更・押下可能、などの各種条件を、それぞれ細かいUI要素単位で考える必要があります。ただ、どんな条件の時にどんなUIが必要かを、実際に動くものがない時に判断するのは難しく、どうしても漏れが出てしまいます。
実際に動くものができていれば、検証しながら各種条件の設計ができます。エンジニアにUIデザインの裁量権があるのは動きやすかったですし、デザイナーとのやり取りもスムーズでした。
アイコンの調整
上記画像の初期のアイコン（特に上矢印と下矢印アイコン）を見て何か気になる点はありませんか？
そうです。上下中央揃えされているように見えませんね。上矢印アイコンは下寄り、下矢印アイコンは上寄りに見えます。計算上は上下中央揃えなのですが、人間の錯視でそう見えてしまいます。過去に行っていたUIデザインのバイトで私自身もこのような矢印アイコンの錯視補正作業を経験したことがあり、すぐに気づきました。
当時、Strap の SVG アイコンは下矢印アイコンしか使われておらず、上矢印アイコンがデザインアセットにありませんでした。そのため、下矢印アイコンをCSSで上下反転させたところ、この錯視の問題が浮上しました。そこで Strap チームのデザイナーに上下中央に揃って見えるよう、錯視の補正と、上矢印アイコンのアセットへの追加をお願いしました。
綺麗に錯視効果が除去されたアイコンを作成してくれました。さすがプロのデザイナーです。 私がやったらゲシュタルト崩壊を起こして一生アイコンを上下に動かしていたと思います。
私が勝手に追加しようとした上矢印アイコンが、デザイン的に良しとされるものではないということがわかったのは、デザインを学んでいて良かったと思うポイントでした。
スペーシングの調整
先ほどのアイコン画像をもう一度ご覧ください。初期と最終形を見比べてみると最終形では、上下の矢印アイコンとバツアイコンが少し離れています。上矢印は前の検索結果へ、下の矢印は次の検索結果へ移動する機能です。この類似機能のまとまりを作るために、バツアイコンとの間に余白を設けています。
このようにグループを示すための余白は、スタイリングの手法としてよく用いられています。
インターン生としての感想
私が一人で行ったように書いていますが、デザイナーや他のエンジニアとの相談、PMとの仕様すり合わせなども必要に応じて行っていたので、一人で全部やっているという感覚はありませんでした。特にデザイナーとのやり取りで、新しく気づく視点も多かったです。
チームの皆さんに助けてもらいながら、初めての「エンジニア主導デザイン」でいいものを作ることができたので、非常に楽しかったです。
今回紹介したボード内検索機能は、リリース後多くの人に使われており、良い反響もたくさんいただいたので、次の開発タスクへのモチベーションになりました。また、今回のエンジニア主導デザインを通して、Strapが非デザイナーにデザイン的手法を与える良いプロダクトだと改めて実感したので、Strapにより貢献したいと感じるようにもなりました。
エンジニアでも場合によってはデザインタスクを取るし、かなりの裁量権がありました。たとえインターン生であっても正社員と同じように意見が尊重されましたし、チームの雰囲気が良かったので、臆せずに自分の意見が言えました。私のデザインに関する知識についても評価していただいたので、より一層精進しようと改めて感じました。
おわりに
2編にわたって紹介した Strap の「エンジニア主導デザイン」について、皆さんの目にはどのように映ったでしょうか？ グッドパッチならではのタスクだと思ったので、記事として取り上げてみました。本記事が何か開発時の参考になれば幸いです。
グッドパッチではチームメンバーと職種を超えてコラボレーションしながら開発していただける仲間を募集しています。 カジュアル面談からでもぜひご応募ください。
