見出し画像

デザインについてエンジニアなりに意識していること

dely design

こんにちは。delyデザインエンジニアのJohn(@johnny__kei)です。
普段はクラシルiOSアプリの開発や、Hi-Fiプロトタイプを作成し、ユーザビリティテストを行なっています。

本記事は dely advent calendar 2018 の20日目の記事です。

Qiita: https://qiita.com/advent-calendar/2018/dely
Adventar: https://adventar.org/calendars/3535

前日はサーバーサイドエンジニア兼、新米slackBot整備士のjoeが「サーバーレス+Go言語で作るインタラクティブな哲学slackBot」という記事を書きました。iOSアプリ開発においても、slackBot使っているのですがかなり便利です。

デジタルプロダクトの開発において、デザイナーがデザインをして、エンジニアが実装するというプロセスが一般的ですが、「ものをつくる」ということにおいて、デザイナーとエンジニアの目指すところは異なっています。

デザイナー: 正しいものをつくる
エンジニア: 正しくものをつくる

この違いによって、それぞれの思惑が異なり、ミスコミュニケーションが生まれて、お互いモヤモヤしてしまうこともあるかと思います。

そんななか、ミスコミュニケーションを減らし、デザイナーと協力してプロダクト開発をしていく上で、僕がエンジニアとしてデザインについて意識していることは以下の通りです。

・認知的負荷
・実装の難易度
・仕様の明確化

認知的負荷

認知的負荷が高いUIだと、ユーザーが、使い方を理解できず、結局使われない機能になってしまいます。使われない機能を実装することはしたくないので、実装する前に、ちゃんとユーザーが理解できるUIになっているかを確認しています。

「タップ数を減らして、画面遷移を少なくする」といったことがよく言われますが、画面遷移を減らした結果、1画面の情報のボリュームが多くなってしまい、認知的負荷が高まってしまうようでは、使いづらくて、ユーザーが離脱する原因にもなってしまいます。

最近話題になっているオブジェクト指向UIでは、オブジェクトを先に選んでから、アクションを決めることで、認知がしやすくなっています。これがタスクベースUIだと、先にアクションを決めるので、違うアクションをしたくなったときに最初からやり直しになったりするので、認知的負荷が高くなります。最初からやり直しにされるのはホントつらいですよね。。。

12月にリリースした「クラシルかんたん献立機能」において、最初のUI案では、検索への導線としてナビゲーションバーに検索ボタンが配置されていました。ユーザーが検索したいと思った時に、まず、その導線を探す必要があり、小さなアイコンを探す必要がありました。
現UIでは、画面の下部に、検索フィールドが用意されているので、入力すれば検索できるのが明らかになっています。また、通常人間の視線は上から下に流れるので、気付きやすいようになっています。

実装の難易度

独自のUIコンポーネントを作るときには、ビジュアルだけでなく、ロジック部分も関わってくるので、一手間以上かかります。
全く新しく見たことないUIでないかぎり、実装は可能なはずです。しかし、実装にかかるコストは、UIや個人の力量に依存します。
こだわりすぎると、コストがかかってしまい、リリースが伸びてしまうので、早めに、実装の難易度とコストをデザイナーに伝えて、理想と現実のバランスを取る必要があります。また、本当に必要かどうかも検討します。

「クラシルかんたん献立機能」において、初めてセミモーダルの実装をしました。(「Fluid Interfaces実践 - なめらかなUIデザインを実現する」by ミカサ トシキ )
セミモーダルはiOS11から、Mapアプリを筆頭に、Apple純正のアプリで多く見られるようになりました。しかし、iOS開発でAppleが提供するUIKitにはまだ提供されていません。
Appleのアプリ以外で実装している例が少ないので、めちゃくちゃ大変そうだなと思っていました。そこで、初期のプロトタイプの段階ではセミモーダルは諦めました。セミモーダルみたいだけど、ジェスチャーに追随しないもので、プロトタイピングしていました。それとは平行で、別のプロジェクトファイルで、セミモーダルの実装を試していました。
大変だったのは、複数のセミモーダルが重なるところです(下記のgif)。Siri Shortcuts アプリを毎日食い入るようにみつめて、実装を想像していました。5つくらい作っては壊しの実装を経て、ようやく使いものになるかたちになりました。実際に、クラシルのプロジェクトに導入するときも、手直ししました。

仕様の明確化

正しく作るためには、仕様がはっきりとしていなければなりません。特に、UIには現れてこない、細かい仕様をはっきりさせる必要があります。
例えば、ある条件でのみ、enableになるボタンのロジックなどは、UIには表現されません。それを言語化せずに、エンジニアのいい感じ力に任せてしまうと、iOSとAndroidで異なる実装になったり、思っていたものと違うものが出来上がる可能性があります。そういった状況を防ぐために、デザイナーとエンジニアが密にコミュニケーションをとり、言語化し、共有することで、仕様を明確化し、実装するときの不確実性を減らす必要があります。

弊社では、プロダクトデザイナーがSketch等でモックアップ作成の過程で、デザインの軽いレビューをエンジニアに依頼し、実装面からのアドバイスを挟んだりしています。それに応じて、デザインをブラッシュアップさせる一方、エンジニアも仕様について頭に入れておくことができます。
また、最近では、仕様書ドキュメントの共有とは別に、仕様共有会を行なっていて、実装者が早めに疑問点を解消できるようにしていて、実装後半でつらくならないように、早め早めに不確実性を減らしています。

まとめ

いいプロダクト開発をするには、エンジニアとデザイナーが密にコミュニケーションをとって、実装するかどうかを決定した上で、仕様を明らかにしていき、不確実性を低くしていく必要があります。エンジニアもデザインのことをわかった上で、デザイナーに提案できると、よりスムーズな開発をしていくことができると思います。

dely advent calendar 2018 21日目の明日はサーバーサイドエンジニアの山野井による「【Vue.js】算出プロパティの仕組みについて調べてみた」という記事です。お楽しみに。

いいなと思ったら応援しよう！