logo-idv ico_pp

デザイナーの心に優しいストレスフリーなアプリデザインワークフロー

デザイン

title_imageこんにちは。デザイナーのKです。

インディバルで運営する求人サービス「シフトワークス」はアプリ版も用意しています。
これは既存WEBサービスをiOS・Androidのネイティブアプリへコンバートした内容ですが、単なる置き換えでなく、独自に最適化されたUI・機能も備えています。

本記事では、WEB→アプリの翻訳において、デザイナーが行った作業内容と工夫についてご紹介します。

アプリの特性を考慮してワイヤーフレームを作成

まず、シフトワークスのスマホサイトを参考にしながらワイヤーフレーム(以下WF)を作成します。

新規アプリであれば手描きWFやUI Flowsなどの段階を経て、より抽象的なレベルから全貌を練り上げていくべきですが、ガイドとして既存サービスがあるため、下準備をすっ飛ばしていきなりWFに着手します。

sketch2

Sketch上で全画面をアートボードで管理している様子

アプリ=常連さん向けメディアと定義する

自然流入によるユーザー(一見さん)へのおもてなしを強く意識する必要のあるWEBサービスにくらべ、アプリは、わざわざストアまで行ってダウンロードして起動してくれたユーザーが相手であり、つまり指名客、または常連さん向けのメディアと捉えることができ、WEB版とはモチベーションやリテラシー等、ユーザー特性に違いがあることを考慮する必要があります。

自ずと、要請されるUIにも違いが発生するわけで、アプリデザインでは通常、以下のポイントを念頭に置いて設計することにしています(もちろんケースバイケースですが)。

  • リピーターの居心地の良さ
  • 華やかさよりも、手に馴染む道具としての使い勝手の良さ
  • 可能な限りシンプルに。画面ごとの行動の選択肢を極力減らす
  • WEB版ユーザーよりはネットリテラシーはやや高め
  • 過剰な親切設計は相手を馬鹿にしていることと同じ

この方針が本当に正しいかどうか、そして実践できているかどうかはとりあえず別として(精進します)、
このような指針があると、ブレなく一貫したデザインの道標として重宝します。

Skecthで実寸大のWFを作成

sketch1
https://www.sketchapp.com

ツールはSketchを利用します。
ここ数年、WEB・アプリデザイン業界での台頭が目覚ましいオランダ産のUIデザインツールです。

Sketchは以下のような利点があり、シフトワークスのような情報量が多くミニマルで装飾性の少ないアプリ開発には最適です。

  • 動作が軽い(PhotoShopやIllustratorに比べて)
  • WEB・アプリ設計に特化している
  • ProttやZeplin連携など、プラグインが豊富(後述)
  • 学習コストが低い(Illustrator、Fireworksユーザーは特に)
  • 値段が安い

下図のように各画面を(見かけ上の)実寸大で作成し、期待される挙動を注釈の形で全て書き込んでいきます。
今後この資料が仕様書に限りなく近い資料として機能していくため、この工程はデザイナーの好みの挙動を勝手に盛り込むチャンスです。

シフトワークスのユーザー利用状況を鑑みて、基準にするのはAndroid、360×640サイズの端末です。

sketch3

Prottでプロトタイプを作成

prott1
https://prottapp.com/ja

プロトタイプピングツールはGoodPatch社のProttを利用しています。
ProttはSketch用のプラグインが用意されており、画像書き出しの手間なく迅速にプロジェクトをインポートできます。

インポート後は、各画面間の遷移を独特かつ直感的なGUIで設計していきます。
画面遷移やモーダル表示など静止画や文章で伝えづらいトランジションはプロトタイプ上で表現します。

prott2

Prottで各画面間の遷移を設計していく様子

OSごとの特徴を考慮してデザインカンプ作成

引き続きSketchでデザインを行います。
WF作成の時点で主要な設計はほとんど終えているため、ここでいう「デザイン」とは、「着色する」「見た目を綺麗にする」「装飾を施す」などの、狭義のデザイン作業を指します。

wf2design

また、WF作成時には省略した、スプラッシュ画面、ウォークスルー、エンプティステートと呼ばれるNotFoundなどのイレギュラー画面、そしてiOSアプリの画面設計を行います。

iOSとAndroidのデザインの違い

Androidデザインを作ったら、あとは「このデザインをいいかんじにiOSでも再現しといてね〜」などとエンジニアに丸投げできれば楽ですが、そういうわけにはいきません。

iOSとAndroidはデザインの思想に違いがあり、ナビゲーション一つとっても、推奨UIが大きく異なります。
実装効率を考えるとそれぞれのOSに準拠したUIにするべきで、以下のような違いを考慮した、OSごとのデザインが必要とされます。

iOSとAndroidの主な違い(2016年時点)

iOS Android
画面幅(※) 320px基準 360px基準
ナビゲーション タブメニュー ドロワーメニュー
バックキー なし あり
フォント ヒラギノ角ゴ+Sanfrancisco モトヤマルベリ+Roboto(〜5)
Noto(6〜)

※画面サイズはユーザーの端末シェアに応じて適宜調整

ios-android

メニューの形態の差が、アプリ全体の導線設計にも影響を与えるため、ここをおろそかにすると後で痛い目を見ます

Zeplinを活用してエンジニアとのコミュニケーションを効率化

zeplin1
https://zeplin.io/

エンジニアに対して各部のサイズ、色、文字指定など諸々の情報を伝えるためのデザイン指示書作成には、Zeplinというツールを利用します。
これもSketchとの連携が可能です。

ZeplinにSketchのアートボードをインポートすると、見た目の実装に必要なほとんど全ての情報をブラウザ上で簡単に確認することができます。確認のみであれば専用ツールのインストールなども必要ありません。

デザイン指示書の作成は面倒な上に頻繁に変更が発生するので、デザイナーにとっては煩わしい作業の筆頭ですが、このツールを利用することで劇的な効率化が得られます。

zeplin2

パーツにカーソルを合わせると、サイズ・余白・色・フォント・テキスト情報などを表示できる。カラーコードをSwiftやCSSとして出力もできる優れもの。

デザイン共有をZeplinだけで行うといろいろ捗る

現在はエンジニアとデザインのやり取りする時は「最新のデザインは常にZeplinでしか確認できない」という状態にするように努めています。

これにより「共有サーバーのデザインファイルを更新したのにも関わらず、それに気づかずローカルに保存した古いデザインで実装されてしまう」といった、あるあるなミスを仕組み上で防ぐことができるからです。

デザイナーとしても、いちいちPDFや画像を書き出して、サーバーにコピーして〜、といった手間が減るためいいことづくめです。

Zeplinの詳細については弊社デザイナーが他記事で解説しているので、そちらもご覧ください。

デザインカンプからコード化を加速する!デザイン仕様計測ツール4選

XcodeとAndroidStudioで画面修正

ide

デザインが完成した後は各開発環境上で調整を行います。
この工程をデザイナーが行うべきかどうかで賛否両論あるようですが、私はやるべき派です。

デザイナーがやるべき理由

例えば、デザイン実装を全てエンジニアに依頼した場合、以下の例ような不幸が起きることがあります。

manga

こういうことが積み重なり、互いに疲弊し、気を遣い、あまつさえプロダクトのクオリティが下がり、やがてプロジェクトから笑顔が失われていくのです。

この漫画のデザイナーはだいぶ無能な感じに描いてしまいましたが、実装段階のデザイン調整は細かい細かいトライ&エラーで磨き上げていくことがほとんどで、その作業は感覚に依るものが大きく、それを全て他者に依頼するのはやはり無理があります(少なくともとても難しいです)。

見た目の修正はデザイナーの専門領域なわけで、お互いがお互いの得意分野を手掛けたほうが効率が良く、ストレスも軽く、クオリティも上がり、プロダクトの幸福に繋がるはずです。

「エンジニアに負担をかけたくない」という気持ちはもちろん、「自分でやりたい、そのほうが自分の精神負担が減る。そして自分でやれたほうが楽しい」という動機のためにデザイナーが画面実装も手がけるべきと考えます。

作業内容

詳細は割愛しますが、以下のような作業をデザイナーが担当します。

  • XcodeのStoryboard修正(わかりやすそうに見えるが学習コストはかなり高め。触って覚えるしか無い)
  • AndroidStudioでxml修正(HTML+CSSの考え方と親和性があり、勘と気合でなんとかなる)
  • サイズ、文字、色、余白をデザインカンプに合わせる
  • 端末サイズの違いによる誤差の吸収
  • 必要に応じてSwift・Javaの修正(できる範囲で)

ただし、これらの作業は事前のエンジニアへの相談と、コードレビューは必須!

終わりに

シフトワークスアプリ開発は、興味のおもむくまま、かなり好き勝手にやらせていただきました。

本記事で紹介した手法は弊社(というより私個人)特有のもので、世間一般におけるアプリ開発フローに比べると、要所要所で大雑把だったり特殊なやりかたになっていると思われます。ただ、それも自分なりに社内の体制・環境に最適化した結果です。

アプリ開発は技術の変遷が激しく、例えばPWA(プログレッシブ・ウェブ・アプリ)などの流行によって、本記事の内容が急激に古びることも考えられます。
それもまた刺激の一つであるので、先端技術をキャッチアップしつつ、その都度理想的なデザインフローを見出していきたいと考えています。

執筆者プロフィール

入社4年目のデザイナー。
デザイン作業も面白いですが、結局JavaScript書いているときが一番心が落ち着きます。
この記事を書いている現在は、先日注文したお取寄せの生牡蠣の到着を待ちわびている最中です。

※この記事は、2017年2月に作成されたものです。