プログラミングとUIデザインの境界、およびデザインの環境設定について

timakin
9 min readJan 18, 2018

--

今回言いたいこと

・UIデザインとそれを書き起こすプログラミングの乖離は、いくらわかってるつもりでも想定より大きくなる

・工数や実装都合上、泣く泣く見た目を変えざるをえない場合のデザイナーのストレスは、スピード優先で設計がおろそかになったときのエンジニアにかかるストレスより大きいのではないか

・雑にプロトタイプを出していい時代は終わってるのでは?と思うので、デザインを勉強していくべき

「デザインを勉強したい」

学生の頃から、dribbbleやbehance、デザイナーブログをみるのが大好きで、「うわーこんなかっこいいロゴ思いつかないよ、すげー」とか、「フォントの微差によく気を使ってるんだなー」とか、「このサイトの余白は過剰だけど、こっちはいい塩梅だなー」とか、そういうのがかなり気になってしまうタイプでした。

というと聞こえがいいのですが、結果的にエンジニアの道を選んで、UIは実装しながら考えるフローを踏むことはあっても、デザインから設計することはなく、レストランのナプキンとかにプロトタイプ案を描くとか、そういうチープな段階に止まっていました。

が、最近のアプリを見ていたり、自分が業務でつくってるアプリを振り返ると、どうしてもデザインの効力が増しているように思えました。もっというと、機能自体の独自性よりも、デザインのレベルの高さが、そのアプリが生き残るかどうかという結果に及ぼす影響が大きくなっていると感じました。最近の学生のチームが出すアプリのデザインのレベルが高いことこの上ないですよね…

そんなこんながあり、デザインを勉強しないとプロダクトを作る身として危ない気がするぞ、せめてデザイナーに正確に意思を伝えたり、優秀なデザイナーの方とお仕事ができるように共通言語としてデザインを勉強しておこう、みたいなモチベが湧きました。

デザインのための環境構築

で、僕は壊滅的にイラストがかけないので、UI設計的なことをやることにしました。

今回自分がUIデザインを勉強・実践するに当たって利用したツール、サービスは以下です。

Sketch

定番です。これなしでUIとかできません。有料ライセンス買いましょう。そもそもこれがないとエンジニアがmac持ってない的な感じです。(macじゃなくてもプログラミングできるとかそういうのはわかってるんですが、一種のたとえなので勘弁してください)

Symbolという、同じオブジェクトをする、ポインタ的な機能があるのですが、これのおかげで再利用性を高めてデザインすることができました。あとプラグインが充実してて、IDEにプラグインをドカドカ入れてコード書くみたいな感覚に似てます。アプリアイコンをデザインするときとかは、自動で様々なサイズに調整して画像を描き出してくれるプラグインとか、本当に便利なものが揃っています。

また、ちょっとしたアイコンなどのリソースは、

  • dribbbleで無料配布されてるものを使う
  • sketch.imでダウンロード
  • sketchappsourcesでダウンロード

などの方法があります。sketchappsourcesよりもsketch.imの方がイケてるものの方が多いです。

Invision

デザインを共有、実機確認、コメントなどをするチームのためのデザインツールです。別にチームで使わなくても、実機でデザインを展開するときに便利です。ZeplinとかProttを使ってる人も多いのではないでしょうか。

Design system managerってやつが最近出てきまして、これを使うとカラースキームやコンポーネントの管理・共通が楽になります。が、現状Zeplinとどっちが楽だと言われると..微妙なところですかね。

Abstract

エンジニアでいうgithubみたいなものですね。バージョン管理ができます。ブランチやらコミットやら、完全にGitと同じですね。コンポーネントごとの差分が見られるので重宝します。というかこれがないと、新しいコンポーネントを足したり、色や幅を変えるときに不安でしょうがないです。

実践結果

年末にせこせこ作っていたのですが、Sketchをまともに起動してから3、4日くらいしてこんな感じのものができました。

また、これに伴いdribbbleのアカウント招待をいただくことができました。以前からデザインを勉強し始めたらdribbbleに招待を受けられるくらいにはしたい、と思ってたので、かろうじて人権を獲得できました。

得られたフィードバック

紙ナプキンに絵を描くのとは全く違った体験で、その過程で得られたフィードバックは大きかったです。

同じく物を作る立場としての反省点

エンジニアって主語だと少し大きいので、僕個人でいうと、やっぱり「この機能シンプルだしよくあるから、すぐできるよね?」って話を見積もり全く把握できない人からされたら、だいぶ内心キレると思うんですね。

エンジニアに対してそういうことを行ってくる人はすごく少なくなったと思いますし、幸い僕の身の回りにはそういう人少なかったんですが、周囲の話を見聞きする限り、あるあるな話ですね。

で、「デザイナーの方もこういうのないのかな?あるいは自分もデザイナーの方に軽く仕事を振りすぎてないかな?」と。

あとはこの記事のように、真の意味でデザインが重要です、と言えているんでしょうか?

少なくとも同じように物を作っていく上で、「あなたの持っているスキルはプロダクトに不可欠で、一緒に頑張っていきましょう」と、違う立場から言えていえるかというと、まだまだ至らないところがあったなと思わされました。

理想のデザインとの乖離ともどかしさ

僕が作ったUI、そのまま実装したら実はそんなに映えないと思うんですよ。なのでポートフォリオ用に、画像をちょっと変える必要とかがありました。理想のデザインに近づけるために少し背伸びしてしまった感じです。

そもそも、例えばメディアのアプリとかなら、記事の執筆者名を出したり、サムネイルを出したり、ボタンを追加したりするだけで、もともと綺麗にデザインしていた理想像とはかけ離れたものになってしまいます。スペースがあるから綺麗に整頓されて見える、という状態でしょうか。

実際ヒットしてるアプリを見ても、dribbbleとかで上位の優れたデザインがそのまま適用されてるものは多くないと思います。というかほぼない。

折衷案を見つける難しさ

理想のデザインを妥協しなきゃいけないとき、「じゃあ折衷案を考えましょう」となりますね。このとき、「ちょっと雰囲気よくないので、もう少し軽い、いい感じでお願いします」とか言ったら、デザイナーの方は辛いでしょうね。

そもそも妥協しなきゃいけないことが多いのに、さらに具体的な方針もわからない状況で、「いい感じに」するって相当辛いと思うんですよね。なので、「このアプリのコンポーネントみたいな色合いにしてください」「アニメーションはこのサンプル見たいな時間感覚でお願いします」とか、できるだけデザイナーが悶々としなくても済むような提案ができたら良いですよね。「それがデザインスキルだろ?」という考えもあるんですが、僕はあんまり好きじゃないです。

プロトタイピングの質

冒頭でデザインを勉強しないといけないという危機感について述べましたが、このまとめが問題点をよく表していると思います。初期実装だから雑なデザインでもいいよね、なんてことはもうなくて、初期リリースでも十分デザインには気を払わなきゃいけないと思います。エンジニア一人でもプロダクトができる、、とも言いがたいのかなと。

少なくとも初期の段階においては、プログラミングとデザインの専門スキルの境界線を引かず、両方できるくらいじゃないと、これからは良いプロダクトができないなと思います。

まとめ

結構エモいですが、より良いプロダクトを作るために、プログラミングのスキルだけではなくデザインのスキルも自分の選択肢に組み込まなければならないな、と感じた話でした。

--

--