UIやUXはエンジニアには無関係と思う人もいるかもしれませんが、そんなことはありません。

エンジニアだからこそ考えないといけないのです。

UIやUXはデザイナーが考えるものと思っていると、常に言われるがままに作ることになります。

そうなると、あなたがどんなに優秀なプログラマであっても、「デザインができないから一人ではWebサイトもアプリも作れない」という悲しいエンジニアになります。

それでもいいでしょうか?

デザインができないのは学んでいないから

絵とかデザインって生まれつきの才能と思う人も多いと思いますが、実は基本的なデザインのことを学んだりちょっと練習をするだけで、色使いがましになったり、少しはカッコイイ絵が描けるようになります。

エンジニアはデザインの勉強をしていないからうまくできない、ただそれだけのことなのです。

プレゼン資料1つ作ったってそうなんです。

エンジニアが作る資料はどうもダサい。

それはなぜかというと、各ページのフォントの種類や大きさが統一されていなかったり、色が脈絡なく使われているからなのです。

ちょっとしたイラストを描くときだって、コツを押さえるだけでそれらしく見えるものなのです。

「デザインはオレには無理、無理」などと言わずに、ちょっと基本的なことを知るだけで「意外といけるかも」という風になれます。

デザインができるエンジニアの強み

デザインと言っても幅が広いですが、

  • レイアウトの方法
  • 色使い
  • 簡単なイラスト

くらいができるようになると格段に自信が持てるようになりますし、仕様を検討する場などでもとても有効になるのです。

具体的なテクニックはデザインの本などを参考にしていただくのが良いのですが、たとえば動画を示すときに、四角い箱に三角形を横にして描けばそれらしく見えます。

その絵がひとつあるだけで「動画」と説明入れるよりもはるかにわかりやすいのです。

エンジニアはどうしてもテキスト(文章)で説明しがちですが、そんな小さな絵を使うことで、ミーティングでの仕様検討が進んだり、ドキュメントでのコミュニケーションの質が上がるのです。

UIはデザイナー任せではいけない

UIはデザイナーが作るもの、そういう風に思っているエンジニアも多いでしょう。

もちろん、仕事の役割としてデザイナーがUIを作る役割を持っています。

でも、それは最終的なデザインを作る役割という意味です。

そこまでには、どういうUIが良いのか検討していきますが、こうしたいけど技術的にできるかできないか、できるとしても難易度が高いのか低いのかなどはエンジニアがアドバイスが必要です。

このとき、単に技術的なアドバイスではなく、ユーザー目線で一緒に考えることも必要なのです。

なぜかと言えば、実装していく中で技術的な課題とか工数的な課題が見つかったときに、UIをそう決めた背景を知っていれば、別の解決方法を提案するなど解決策を見つけ出しやすくなるからなのです。

「この方法は技術的にできません」とだけ言ってしまうと、今度はデザイナーが悩んでしまいます。

「こういう表現方法も考えられるけど、これは技術的にできるのか?できないのではないか?」と。

そうすると本来やりたいUIをあきらめることも出てくるのです。それはUXにも影響を与えるのです。

「言われた仕様を作る」仕事に陥っていると、本来お客さんが望んでいるものやデザイナーを含めサービスを提供する側が作りたいものを見失いがちなのです。

UXを意識することも大事

サービスの提供を考えるとき、UXを意識することもとても大事です。

UXとはUser Experienceのことです。

日本語ではそのまま「ユーザー体験」というのですが、サービスを使ってユーザーはどんな体験ができるかということなのです。

提供するWebサービスやアプリを使うことで、今まで苦労してきたことが簡単にできるようになるとか、とてもできないと思っていたことができるようにようになるのであれば、ユーザーは新しい体験ができるようになるということなのです。

その体験というのは、UIを決める前に考えないといけないことです。

特に新しいWebサービスやアプリでは、「こんなことができるようになりますよ」ということが大事です。

サービスを作るには、本来解決したい課題があってそれを解決するのですが、その解決方法にはいろいろな方法があります。

そして、その解決方法の使い勝手によってユーザーの感じ方も違ってくるのです。

それがUXになるわけです。

エンジニアもこの部分も意識しながら取り組むことが大事です。

そして、デザイナーが気づかないような、あるいは技術的にできないと思っていることに対して、「こういう風にできますよ」と提案することで新たなUXを提供できることにもつながるのです。

こういうことを続けていくことで、「言われた通り作る」エンジニアから「自分で考えて作れる」エンジニアへと変わっていくのです。