ここ数年、私が担当するプロジェクトでは、後輩や委託先が上げてきた画面デザインのリテイク回数が増えているような感じがします。
デザインの重要性はアプリだけではなくPR動画やプレゼンなど、年々上がり続けています。
非エンジニアからはスマホに入っているようなキレイなアプリを見慣れているためか、エンジニアには「なんで同じようにできないの？」という突き刺さるような視線が胃を厳かに刺激します。
「センスは知識量」と言われますが、デザインセンスは天性のものとは限らず、そのほとんどは学習によって身に着けることができます。万人が唸るようなセンスを身に着ける必要はありません。しかし私たちは「最低限、人が不快に思わないデザイン」ができているでしょうか？
エンジニアが持つべき視点というか根っこの考え方はこの記事が参考になるかと思います。
https://qiita.com/mskmiki/items/544149987475719e417b
さて今回指摘したのは Web やモバイルアプリではなく。 BtoB などの業務アプリやプロユース、あるいはコンストラクションツールなネイティブアプリの画面デザインです。
プログラミングに入る前にやれることはたくさんります。まずは次のような点を意識してみると良いかもしれません。
- デザインガイドラインを読む
- 製品の目的や要件を確認する
- 資料を集める
- ワイヤーフレームやプロトタイプを作る
デザインガイドラインを読む
世の中にはデザインガイドラインやデザインシステムというものがあります。 Android アプリならこう、 Windows アプリならこうといったガイドラインが、プラットフォーマーから公開されています。
例えば次のようなことはどうでしょう。
- [OK] ボタンと [キャンセル] ボタンは、どちらが左側でしょうか？
- ダイアログウィンドウの余白はどの程度取るべきでしょうか？
- チェックボックスとトグルスイッチはどのように使い分けるべきでしょうか？
これらは非機能要求とも言えます。クライアントがあえて要求として明示することはまずないでしょう。開発者自身もそうです。普段は気にせず空気のように、色々なアプリを使っているのではないでしょうか。
とはいえこれら気にせず場当たり的に作ってしまうと小さな積み重ねが集まって、「動きは問題ないけと、なんかダサい」となっていくのではないかと思います。
私のチームではこれらの読み合わせを毎週行っています。どれもかなりの分量があるので、新人に「読んでおいて」と丸投げしたり、一人で立ち向かうよりはみんなで集まって進める方が良いと思います。先輩は読み合わせのついでに、用語の説明とかもしてあげると良い教育の時間になります。
製品の目的や要件を確認する
特に重要なのはターゲットユーザーです。改めて確認しましょう。
プログラミングだけしているときはそれほど気にしなくても大丈夫なことが多いですが、画面デザインを任せられたのであれば、一気に話は違ってきます。
あなたのツールのユーザーはどんな人でしょうか？ITスキルは？若者？ベテラン？管理職？
沢山のデータを効率的に編集するなら、Webではあまり使われないマルチウィンドウをあえて採用するべきかもしれません。ユーザーのモチベーションを維持するために、時には大げさなアニメーションが必要かもしれません。標準のメニューバーは、もしかしたら年配の管理職の方の目には小さすぎるかもしれません。僕のように明るい色が苦手なのでダークテーマを所望する人はいるでしょうか？
ガイドラインに従うことは重要ですが、それ以上にあなたの顧客がどんな人なのかをイメージし、必要であればその理由と共に最適な GUI を探しましょう。
資料を集める
少しソフトウェアから話がそれますが、イラストなどデザインの仕事をしている方は「依頼された絵をかく前の資料集め」をとても重視しているらしいです。私も絵描きの端くれだったりするのでよくわかります。特に初心者のうちは「何も見ずに描けてこそ一人前だ！」という思いがありますが、大きな落とし穴です。
資料集めは文化や流行り、一般常識を学んだり確認する機会です。例えば、着物の合わせはどちらが前でしょうか？昭和と令和で色の使い方の傾向はあるでしょうか？
アプリ開発であれば、ガイドラインを確認することにも通ずると思います。
「何も見なくても描けるのがプロ」？ プロこそ大切にしている、資料について【絵で食べていきたい／第12回】
「設計」も英語では「デザイン」と呼びますよね。このように資料を集めて考察を深めるのは、イラストもアプリ開発も同じことだと思います。ところが私の周りでは、画面デザインとなると自分の頭と経験だけで考えてしまうプログラマがとても多いように見えます。要注意ポイントかもしれません。
資料集めの例ですが、例えばプロフィール画面を作るとしたら、Pintarest とかで「プロフィール画面 ui」などと検索してみましょう。あなたのアプリのイメージに合いそうな画像を数点選んで、良い点・悪い点を考えたり、それらに共通しているUI部品があるならなぜそうなっているのかを考察しましょう。
ただPCアプリは検索で画像を集めるのが難しかたり、見た目よりも効率的な動きができているかが重視されることもあるため、実際のところは類似ツールを集めて動かしてみることが多いかもしれません。
ワイヤーフレームやプロトタイプを作る
figma でも Excel でも、紙に手書きでもよいので、どんなイメージを持って実装しようとしているのかをメンバーと共有しましょう。小規模なダイアログウィンドウとかであれば作らないこともありますが、大きな画面デザインではできるだけ作って、プロダクトオーナーやデザイナーなど責任を持っている人に見てもらいましょう。
ワイヤーフレームはイラストでいうならラフ画です。もしアプリの新規開発でクライアントが居る場合は可能な限り共有しましょう。（普通は要件定義フェーズですり合わせると思いますが）
プロトタイプはデモや動画といった形でレビューしてもらうことになると思います。
メンバーやクライアントにデモや動画を見せて、反応をよく観察しましょう。
さいごに
個人的な印象ですけど、Webやモバイルアプリはパターンがある程度出来上がっていると言いますか、そのためプラクティスの共有や自動テストも活発ですよね。でもPCネイティブアプリは自由度の高さや積み重ねてきた歴史のためか、本当に多種多様で、正解を導くのは非常に困難だと思います。
それでも何とかやり抜かなければならないのですが、そんなときのためのアンテナの張り方のひとつとして、この記事が参考になれば幸いです。
なお今回は画面デザイン(GUI)を取り上げましたが、「インターフェース」と付くもの（API とか CLI とか）はだいたい同じようにデザインが伴うものは大体同じ感じになると思います。
作業するときに、ぜひ周りを見渡してリサーチしてみてください。