アプリエンジニアもUIレビューしよう

f:id:haru_skywalker:20170617020613p:plain

私が所属しているチームはBtoBのWebサービスを開発しているのですが、専属デザイナがいるわけではないため、デザイナ経験のある私がUI全般の責任者をしています。

UIに変更が入る時は、Issueの時点でデザインをどうするかコメントを求められたり、担当者がPRした内容のうちUI部分のレビューをする、という感じになってます。

小さな機能変更であれば、現場の開発者がボタンを1個増やす程度の修正はよくあるかと思います。そういうちょっとしたUIの変更時に、コードレビューとは別に「UIレビュー」を別のエンジニアがやってみたらどうだろう?と、ふと思いました。

というのも、今日偶然このスライドを見て、これは良いなと思ったのです。


初めてのレビューでも、二次受けレビュアーがいてくれれば安心できますよね。自分が気付けなかった部分があれば、指摘で更に成長できる。

これって何もコードレビューだけじゃなく、色々なことに応用できそうです。そう、UIレビューです。

ツールを使うだけがデザインではない

デザインを勉強したいけど、デザインツールを使ってまで何か作るのはちょっと…と思ってる人は多いんじゃないかと。それなら、UIレビューから初めてみませんか。

おそらく、大半のエンジニアはUIデザインに真剣に向き合う機会がほとんど無いと思うのです。なのでレビュアーになることでその機会を作りましょう。

実際にやってみると分かるのですが、デザインルールが決まっていないグレーゾーンのものって結構多くて、例えばサブミットボタンなら色や配置は決まっていても、そうでないボタンの色/大きさはどうすべきか?など。ある程度ルールがあったとしても、やはり例外は出てくるものです。そんな時に、

  • このボタンデザインはこれで正解なのか
  • 配置はここで良いか
  • ラベルは利用者にとって分かりやすいか
  • 前後のパーツとのバランスは取れているか
  • 押した時の動きはどうか

たかがボタン1つですが考える視点はいくつもあります。コンシューマ向けサービスだと、更にコンバージョンへの影響なども気にする必要があるかもしれません。

レビューを正しく行うことよりも、これらを真剣に考えることが大切なのです。二次受けのレビュアー(デザイナ)がいれば、自分のレビューの答え合わせになりますし、気付けなかった指摘があれば一粒で二度美味しい。

これならイラストレーターやフォトショップを使うこともないので、やってみようかな?という気持ちになれたんじゃないでしょうか。

UIレビューの具体例

デザインレビューって個人の好みになってしまうのでは?と懸念するかもしれませんが、大きなデザイン変更ではなく、ちょっとした変更のレビューであれば、好みが入る余地はあまり無いです。

例えば今日私が実際にレビューしたのは、こんな感じでした。

これまではグレーのボタンが1つだったボックスに、機能追加でボタンが2つ追加されていました。1つの時は良かったのですが、狭いボックス内にグレーのボタンが3つとなると事情は変わってきます。私がコメントしたのは、

「メイン操作となるボタンだけ色を付けて目立たせ、利用者が迷いなく操作できるようにしよう」

というものでした。結果だけ聞くと簡単そうだと思ったかもしれません。実装している時には既存のデザインに引きずられたりして、案外気付かないものですが、レビュアーになるとよく見えてきます。

そしてこの程度なら、指摘された人は今後似たようなケースの時にすぐに応用できますね。小さな変更のレビューでは、指摘の大半は容易に実践できて応用可能なものなので、爆速でパターンの引き出しが増えていきます。

毎回レビューするのも大変だとは思うので、期間を決めてやるといいかもしれません。例えばチーム内で週ごとに順番でやるのも良いと思います。

さいごに

どんな方法であれ、大切なのは真剣に向き合う機会を作ることです。それが意識に繋がります。私たちの身の回りは、ありとあらゆるデザインで溢れています。意識が芽生えるだけで、目に入るほぼ全てのものが勉強対象になるのです。

今日、新しい洗濯機が届いたのですが、この操作パネルを見てください。

一色しか使っていなくても、ボタンの形状や大きさが異なるだけで、分かりやすくなっています。 意外と身近なところに色んな発見やヒントはあるのに、意識していないと気付けない。でも意識していれば気付くこともある。ただそれだけのことなのです。