ENECHANGE Developer Blog

ENECHANGE開発者ブログ

作る前に知っておきたかった、アプリデザイン時のチェックポイント4選

EV充電サービス事業部デザイナーの @hoshility と申します。

2022年5月に電気自動車 ( EV )・プラグインハイブリット車 ( PHEV ) 向けの充電サービスのアプリをリリースしました。こちら大変便利なアプリになっているので、ぜひ使ってみていただけると嬉しいです。

ENECHANGE EV CHARGE

iOSアプリはこちら

Androidアプリはこちら

はじめに

本アプリの初期リリースまでの実装期間は2021年12月中旬から2022年3月までのおおよそ3.5ヶ月でした。ゼロからアプリを作るにしてはそれなりに開発期間がタイトだったかと思います。 また、会社としてネイティブアプリ自体の開発を行ったことがなかったため、社内にノウハウがなくエンジニア・デザイナー共に手探りなことが多い開発でした。 本開発におけるエンジニアリング面での創意工夫については @yuyasat が別記事で紹介していますので、ぜひそちらをご覧ください。

本記事では、デザイン面において着手前に知っておくと楽だったポイントを4つまとめてみました。 当たり前なことやアプリの開発に限らないこともありますが、一つのケーススタディとしてお読みいただければ幸いです。

前提条件

  • デザイナーは2人( @hoshility ともうひとり。もうひとりはおおよそ週3程度)
  • デザインツールは Figma
  • Flutter を用いた開発。iOS、Android を同時並行で開発
  • アプリエンジニアは全員リモート

1. まずは検証機の文字サイズが標準であることを確認

エンジニアに実装してもらった画面がどうも Figma のフォントサイズと違う。なんか小さい。 エンジニアに調査してもらっても原因がわからずといったことがありました。原因は検証端末の文字サイズが小さく設定してあったことでした。エンジニアの方本当にすみませんでした。。

実装してもらった画面の文字サイズに違和感を感じた時はまず、端末の文字サイズの設定を見返しましょう昔の自分。

2. UIを描く際は各状態の画面を作ることを忘れずに。特に検索フォーム。

今回開発したアプリには検索フォームがついています。 細かく作り込んでいくと、検索フォーム一つとっても様々な状態があります。デフォルトの状態、フォームにフォーカスを当てた状態、地図をずらした状態(フォーム下に検索ボタンが出る)、検索結果の状態…などなどです。アプリの開発経験が乏しかった僕は「フォームがここにある。以上!」といったかたちでエンジニアにデザインを渡してしまいましたが、考慮すべき事柄が実はたくさんあり、当初の想定より多くリソース割くことになってしまったという経験がありました。検索フォーム、甘く見てました。 特に今回のような地図と検索フォームを連動させるといった、複雑な動きをするUIはひとつひとつのアクションをした場合の状態をしっかり定義しておかないと実装漏れやバグの原因にもなるため、最初から丁寧に各状態のUIを描くことが重要かと思います。

フォームの状態の一部
フォームの状態の一部

検索フォーム以外で忘れがちな状態の画面も備忘録的に書いておきます。

データ一覧を表示する画面

  • empty の状態

フォーム

  • バリデーションエラーのUI
    • フォームの周辺で表示する場合
    • サーバーサイドエラーで表示する場合

作るのを忘れがちなUI
作るのを忘れがちなUI

3. 概念に名前をつけてメンバーに周知する

アプリに限ったことではないですが、形容し難い概念だけれども名前をつけて認識を合わせておくとコミュニケーションが楽ということがありました。例として充電スポットの表示パターンを挙げます。

下記の画像のように、充電スポットを探すUIにおいて主に2つのモードがあり、UIの込み入った議論をする際に名前をつけておけたので説明の手間が省けて便利でした。

名前をつけておくと便利だった画面 : 地図メインモードとリストモード
名前をつけておくと便利だった画面 : 地図メインモードとリストモード

4. デザインデータを整理するリソースを確保しておく

今回の開発では、基本的にはデザイナーがワイヤーフレーム作成からUIデザインまでワンストップで行いました。デザイナーは前述の業務に加えて、エンジニアからのUIのフィードバックや質問に回答して業務を進めていたため、なかなかデザインデータの整理にリソースが避けていないまま開発を行っていました。

当然ではありますが、時間が経つにつれて、デザインデータが散漫な状態になってきました。 似たようなUIだけども微妙にフォントサイズが違ってしまっているケースや、 Figma 上には複数現れている全く同じ画面が各所で微妙に要素が変わってしまいどれが正かわからない、といったケースが散見されるようになりました。長い目で見るとデザイナー・エンジニア共に確認コストがかかってしまうため、やはり都度コンポーネント化するようにリソースを確保しておく必要があると身を持って感じました。今回のようにデザイナーが複数の業務を掛け持ちする場合は、デザインシステムを整理する要因を別途一人つけるくらいリソースをかけても良いかなと感じます。


本記事では、かんたんではありましたが特に紹介したい事柄を4つ挙げてみました。記事の長さの都合上紹介できなかったものがまだあるので、別の機会に紹介したいと思います。

デザイナー募集してます

本アプリはひとまず最低限の機能でリリースを行いましたが、追加したい機能やアイディアはまだまだたくさんあります。僕らと一緒にデザインを行ってくれる仲間を募集しておりますので興味がある方はぜひご連絡ください!

enechange.co.jp