私が所属しているチームはBtoBのWebサービスを開発しているのですが、専属デザイナがいるわけではないため、デザイナ経験のある私がUI全般の責任者をしています。
UIに変更が入る時は、Issueの時点でデザインをどうするかコメントを求められたり、担当者がPRした内容のうちUI部分のレビューをする、という感じになってます。
小さな機能変更であれば、現場の開発者がボタンを1個増やす程度の修正はよくあるかと思います。そういうちょっとしたUIの変更時に、コードレビューとは別に「UIレビュー」を別のエンジニアがやってみたらどうだろう？と、ふと思いました。
というのも、今日偶然このスライドを見て、これは良いなと思ったのです。
初めてのレビューでも、二次受けレビュアーがいてくれれば安心できますよね。自分が気付けなかった部分があれば、指摘で更に成長できる。
これって何もコードレビューだけじゃなく、色々なことに応用できそうです。そう、UIレビューです。
ツールを使うだけがデザインではない
デザインを勉強したいけど、デザインツールを使ってまで何か作るのはちょっと…と思ってる人は多いんじゃないかと。それなら、UIレビューから初めてみませんか。
おそらく、大半のエンジニアはUIデザインに真剣に向き合う機会がほとんど無いと思うのです。なのでレビュアーになることでその機会を作りましょう。
実際にやってみると分かるのですが、デザインルールが決まっていないグレーゾーンのものって結構多くて、例えばサブミットボタンなら色や配置は決まっていても、そうでないボタンの色／大きさはどうすべきか？など。ある程度ルールがあったとしても、やはり例外は出てくるものです。そんな時に、
- このボタンデザインはこれで正解なのか
- 配置はここで良いか
- ラベルは利用者にとって分かりやすいか
- 前後のパーツとのバランスは取れているか
- 押した時の動きはどうか
たかがボタン1つですが考える視点はいくつもあります。コンシューマ向けサービスだと、更にコンバージョンへの影響なども気にする必要があるかもしれません。
レビューを正しく行うことよりも、これらを真剣に考えることが大切なのです。二次受けのレビュアー（デザイナ）がいれば、自分のレビューの答え合わせになりますし、気付けなかった指摘があれば一粒で二度美味しい。
これならイラストレーターやフォトショップを使うこともないので、やってみようかな？という気持ちになれたんじゃないでしょうか。
UIレビューの具体例
デザインレビューって個人の好みになってしまうのでは？と懸念するかもしれませんが、大きなデザイン変更ではなく、ちょっとした変更のレビューであれば、好みが入る余地はあまり無いです。
例えば今日私が実際にレビューしたのは、こんな感じでした。
これまではグレーのボタンが1つだったボックスに、機能追加でボタンが2つ追加されていました。1つの時は良かったのですが、狭いボックス内にグレーのボタンが3つとなると事情は変わってきます。私がコメントしたのは、
「メイン操作となるボタンだけ色を付けて目立たせ、利用者が迷いなく操作できるようにしよう」
というものでした。結果だけ聞くと簡単そうだと思ったかもしれません。実装している時には既存のデザインに引きずられたりして、案外気付かないものですが、レビュアーになるとよく見えてきます。
そしてこの程度なら、指摘された人は今後似たようなケースの時にすぐに応用できますね。小さな変更のレビューでは、指摘の大半は容易に実践できて応用可能なものなので、爆速でパターンの引き出しが増えていきます。
毎回レビューするのも大変だとは思うので、期間を決めてやるといいかもしれません。例えばチーム内で週ごとに順番でやるのも良いと思います。
さいごに
どんな方法であれ、大切なのは真剣に向き合う機会を作ることです。それが意識に繋がります。私たちの身の回りは、ありとあらゆるデザインで溢れています。意識が芽生えるだけで、目に入るほぼ全てのものが勉強対象になるのです。
今日、新しい洗濯機が届いたのですが、この操作パネルを見てください。
こいつ、光るぞ…！ pic.twitter.com/TuzOarC7OC
— HAL ( ˘ ³˘)♥量産型 (@bump_of_kiharu) 2017年6月16日
一色しか使っていなくても、ボタンの形状や大きさが異なるだけで、分かりやすくなっています。 意外と身近なところに色んな発見やヒントはあるのに、意識していないと気付けない。でも意識していれば気付くこともある。ただそれだけのことなのです。
