2019-03-27

フロントエンドエンジニアが UI 設計〜実装で考えていること

おはこんばんちは、開発本部エンジニアの大岡です。

先日、TechLunch という社内勉強会で「フロントエンジニアが UI 設計〜実装で考えていること」という内容で発表しました。UI 設計から実装の細かい話ではなくどういう気持ちで望んでるかという話で、基本的なことしか書いていませんが紹介させていただければと思います。

UI 設計

UI 設計をデザイナーがして、それをエンジニアが実装する場合とエンジニアが単独で UI 設計から実装までする場合があります。今回はそれぞれのケースで、フロントエンドエンジニアがどういうことを考えてるかを紹介します。

とその前に、他人と UI について話すときに気をつけてる言葉で分かりやすくまとまっているツイートがあったので紹介します。

自分が他の人に UI デザインの説明をするとき、あまり使わないようにしている言葉がいくつかあるので、それらについて描きました。
私の中では、これ系の言葉は、
初心者：使いがち
中級者：ほぼ使わない
上級者：たまに使ってる
みたいな印象があります。 pic.twitter.com/O2URgRCVHe

— シンギュラリティ (@singularity8888) December 2, 2018

• 普通はそうする
• 直感的にわかる
• 使いやすい
• わかりやすい

これらの言葉は誰にとってなのか?やそれまでの経験によって意味合いが変わってきてしまうので対象を明確にしないと相手と話が噛み合わなくなることもあるので気をつけています。今回何ヶ所か使っていますが実際 UI について話すときは使わないように心がけています。

デザイナーから画面仕様をもらう場合

デザイナーが優秀であればあるほど、もらった画面仕様を元に早く手を動かしたくなります。ですがここはグッと堪えます。落ち着いて以下のようなことを考えてます。

• なぜこの課題がうまれたのか
• 解決したい課題の本質はなんなのか
• 他の解決策はないのか
• この機能を追加してしまうことにより他に影響がでてしまわないか
• 追加ではなく他の機能を落とすことにより解決できないのか
• そもそも必要なのか

など、この段階で理解できないことはチームで話したりして解決しておきます。次に画面仕様に目を向けまた考えます。

• 似たようなコンポーネントがあったら統一できないか
• より使いやすくできないのか
• 操作感が他と明らかに違わないか
• 操作に対して予想した動きになっているか
• 表示されている情報に意味があるのか

など、画面仕様からは理解できないことや疑問点などはデザイナーとコミュニケーションをとり齟齬がでないようにします。

手を動かす前にある程度ユーザが解決したい課題を精度高く汲み取り落としこめるように努力してます。

自分で UI 設計をする場合

「デザイナーから画面仕様をもらう場合」に書いたことをまずは考えています。

それらを踏まえ、すでに実装済みの UI で似たようなものがあれば似たように作ります。理由としては既にユーザが学習済みの UI のため新たに追加した機能だとしても比較的学習コストが低くなるのではないかと考えるからです。

似たような UI がなく新たに作らなければならないときは以下を意識しています。

• 表示する情報の精査
• 表示する情報はリストなのか詳細表示なのか
• 表示する情報に対しての操作はどんなものがあるのか
• 操作に対してのレスポンス・納得感はどうすれば得られるのか
• エラー表示をどうするのか
• 表示する情報が多すぎて収まり切らない場合どうするのか
• 表示する情報がない場合どうするのか
• 画面サイズ毎に適切に表示できるか
• 状態（クリックやホバーなど）を表現できてるか
• リストの場合デフォルトの順番は適切なのか

などをざっくりノートなどに書き出し詳細を詰めていっています。行き詰まったら迷わずデザイナーに相談しにいきます笑

実装

細かい実装部分というよりはもっと大枠の基本的なことですが紹介します。

• 何も考えずにコピペしない
  • 修正が大変になるので一箇所になるべくまとめる
• 用途にあったコンポーネントを使う
  • 似てるからと使い回すとコンポーネント修正時に思わぬ変更が加わる可能性があるかも
• コンポーネント間の関係が疎になるようにする
  • 密接な関係だと気を使い合わなくてはならず修正が大変
• コンポーネントを作成する際に無理に汎用性をもたせない
  • 修正が困難になり逆に汎用性がなくなる場合が多い
• Reduxに管理させるステートの粒度は適切か
• なんでもかんでも Redux に状態を管理させてしまっていないか
• 無駄な再レンダリングをしていないか
• 無駄な通信をしていないか
• 非同期通信のレスポンスが遅い場合にサーバー側の処理に問題がないか
• 関数や変数は適切な命名で適切な場所に書かれているか
• マジックナンバーを使ってしまっていないか
  • 使ってると修正大変
• なるべく簡単に書けないか
• エラー・例外時の動きは適切か

など細かいことを言い出したらキリがないですが、こんなこと意識してます。

よりよいものを届けるために

いろいろと書きましたが UI 設計から実装完了まではなるべく早く終わらせようと意識しています。１サイクルを

1. UI 設計
2. 実装
3. 触る
4. フィードバック

とした場合に、このサイクルをリリースまでに多く回すことによってより多くの気づきが得られるからです。基本的には一回作ってうまくいくことは希かと思っているからです。

ただ、フィードバックの段階で本当に色々な意見がでてきます。心が折れかけることやイライラすることもあるかもしれません。ですが、プロダクトとして必要なのか、今必要なのか、対象とする利用者としてなのか、ただの愚痴なのか等を見極め軸をぶらさないことが大切です。

フロントエンドの UI やパフォーマンス系は事業的に見ると優先度が低い場合が多い印象を受けます。優先度が上がるときは強い競合、数字的な上昇が見られなくなった時など危機感がでてきたときかなと。。。足りない機能を追加しないといけないし、そもそも人的リソースが足りないなどしょうがないことなのかなとも思っています。

初回リリース時に時間が足りなくても精度の高いものを作りたいという気持ちがあるため先ほどのサイクルを多く回し一人でも多くの人に触ってもらい気付ける回数を増やすことは大事なことだと思っています。

さいごに

あくまで私個人が考えてることなのでフロントエンジニア全てにあてはまるわけではありません。出来てないこと抜けてしまう時や本質的に理解していないことも多々あると思いますが、自分はこんなことを考えているという紹介でした。最後までお読みいただきありがとうございました。

▼ メドレーで働くクリエイターたちのストーリーはこちら

www.medley.jp