2019年2月28日木曜日
デザインレビューはじめました
2月 28, 2019
こんにちは、デザイナーの藤村です。デザインチームで最近デザインレビューを始めました。とても勉強になるし、やっていてデザインそのものの面白さにさらに気付かされています。チームでTryしている内容をご紹介します。
※ここで言う「レビュー」とは、リリース判断の可否を決める機能のことではなく、デザインをブラッシュアップさせるための、批評とフィードバックそのものを指しています。
開発チームの一員としてのデザイナー
シタテルの開発チームは、デザイナー1名＋エンジニア数名＋関係者（企画、マーケ、営業、生産など様々）という構成です。デザイナーは特定のサービスに所属しており、これまでデザインのレビューはサービスチーム内でのみ行なっていました。シニアエンジニアが実装判断した上でチームで要件定義を行い、デザイナーが仕様の叩きを作成、フィードバックをもらいながら徐々にビジュアル面を作り込んでいくという流れが主です。
開発チームでのレビューのいいところ
複数の職種で構成されているため、さまざまな視点からの批評を集めることができます。
エンジニアは機能的な破綻がないか、条件による表示を想定できているか、堅牢性を保つことができているのか、と言った視点で批評を返してくれます。お客様と向かいあっている方からは、お客様に対して自身が機能や画面説明ができるのかという視点で、マーケティング担当は有用なデータが取れるのかという視点で、それぞれフィードバックを返してくれます。
エンジニアは機能的な破綻がないか、条件による表示を想定できているか、堅牢性を保つことができているのか、と言った視点で批評を返してくれます。お客様と向かいあっている方からは、お客様に対して自身が機能や画面説明ができるのかという視点で、マーケティング担当は有用なデータが取れるのかという視点で、それぞれフィードバックを返してくれます。
悩ましいところ
一方で、狭義の意味での”デザイン”を批評する環境がありませんでした。機能上は問題ないのに違和感がある、なんだか野暮ったい、画面を使おうとしたとき操作に迷う瞬間がある。。ちょっとした相談はデザイナー同士でしてましたが、お互い忙しそうだと遠慮してしまったり、各々がモヤモヤしながら自分ひとりで格闘していました。
デザインチームでレビューを始めた
シタテルのデザイナーは週に1回情報共有のための定例会を行なっていました。各プロジェクトの進捗を共有することを目的にしていましたが、みんなでデザイン力を上げようということで、他サービスのデザインレビューもやってみることにしました。
意見がほしいときは、以下のテンプレートを使ってGithubにissue化します。見てほしいデザイナーにアサインをして、後はみなさんの意見を待ちます。
レビューの仕方は、わたなべなつきさんの「デザインチームでよりよいコミュニケーションをおこなうための工夫」を参考にさせていただきました。
レビューをしてみる
Zeplinにコメントをしあう形で進めました。1デザインに対して数十に及ぶ場合もありました。私自身もいざコメントをしようとすると、どこに違和感や改善点を見出したのか、なかなか言葉にすることができず思った以上に時間がかかりました。
どうしても、「こうして欲しい」という指示型のコメントになってしまうのです。「ここでは目的と違う認識をしてしまうので再考が必要だと感じました」のように、根本的な問題点を指摘するようにするには、批評者自身もそこまで潜っていかないと見つけることができないんだなと実感しました。デザインをどう見るか、焦点がどんどん精緻化していくので、とても面白く勉強になります。
どうしても、「こうして欲しい」という指示型のコメントになってしまうのです。「ここでは目的と違う認識をしてしまうので再考が必要だと感じました」のように、根本的な問題点を指摘するようにするには、批評者自身もそこまで潜っていかないと見つけることができないんだなと実感しました。デザインをどう見るか、焦点がどんどん精緻化していくので、とても面白く勉強になります。
3週間やってみて
デザイナー定例でみんなで振り返って以下のような感想があがりました。やってみた感覚と共に、もっとよくするためのアイディアも色々出てきました。当たり前のことなんですが、実際にやってみるって本当に大切ですね。
これからもレビューを重ねていって、私たち自身のデザインを見る目を育てながら、チームで成長できる方法をTryしていきたいと思います！
2019年1月28日月曜日
WEBエンジニアが知っていてもいいかもしれない出版やデザインの話
1月 28, 2019
私は出版・DTPをかじったことが少しだけあるのですが、デザインや文章校正の基礎知識はエンジニアの仕事でも活用できる機会が時折あったりします。
基本的なキーワードだけ簡単にご紹介します。
興味がでたらぜひ本格的なデザインや文章校正の本などで調べてみてください。
少し気にするだけでも、画面が結構「それっぽく」なりますので、コスパの良い知識だと思います。
ジャンプ率
1画面（1紙面）でのフォントサイズの変化率を指す言葉です。一般に、落ち着いた雰囲気にしたい場合はジャンプ率を小さく、派手な印象を与えたい場合はジャンプ率を高くすべきと言われています。
色の指定方法
RGB
WEBエンジニアがまず思いつくのはこれかと思います。光の三原色ですね。HSB
色相（Hue）、彩度（Saturation）、明度（Brightness）の3要素で色を指定する方法があります。色相は赤系・青系などの色味、彩度は鮮やかさ（小さいほどグレーに近くなる）、明度は明るさ（小さいほど黒に近くなる）を表します。
SBを固定し、Hのみを変動させることで、比較的まとまりのある色のバリエーションが作りやすいです。
例えば、画面上でステータスAとステータスBの表示色を変えて視認性を上げたい、といった場合には、色相のみ違う2色を用いると、比較的おさまりが良かったりします。
CMYK
インクの4色です。基本的に印刷物の色味はCMYKで表現されます。WEBだと気にする機会はあまりないですが、RGBやHSBで表現できる色は、必ずしも同じ見え方のCMYKに変換できない、という点は知っておいてもいいかもしれません。
人物写真の「首切り」
インタビューに添付される人物写真において、人物の顔部分に背景の直線（窓枠等）が被る構図はNGとされています。必ずしも合理的な理由はない（私が知る限りでは）ですが、確かにちゃんとしたサイトや紙面の写真では見ない構図ですから、気にしておくといいかと思います。
文章の書き方
表現したい内容によって正しい日本語の書き方というのは当然変わりますが、かっちりした文章を書く場合には新聞ルールを参考にすると、素人感が出なくていいです。- 「出来る」と「できる」はどちら？
- 「行なう」と「行う」はどちら？
- 「〜です（〜）。」「〜です。（〜）」はどちら？
たとえばこういう疑問に対して、どっちがプロっぽいか、という回答を与えてくれます。
文献としては共同通信社の記者ハンドブックなどがメジャーですが、買うと高いので、新聞社サイトの文章を参考にするなどでもいいかもしれません。
以上です。散文になってしまいましたが、ご参考になれば幸いです。
登録:
投稿 (Atom)
