High-Fidelity Prototyping with Xcode

こんにちは、delyでiOSエンジニアをしているJohn(@johnny__kei)です。
最近は、Xcodeでのプロトタイピングを行い、デザイナーと一緒にユーザビリティテストにも参加しています。

先日、弊社のプロダクトデザイナーであるミカサ(@acke_red)が「リーンなプロダクト開発におけるデザイナーの役割」という記事を投稿しました。
記事中にもありますが、弊社では、プロダクト開発において、デザインフェーズと実装フェーズに分けています。

デザインフェーズでは、アイデアの検証のために、プロトタイピングを行い、ユーザビリティテストを行なっています。その際にXcodeを使用し、よりHigh-Fidelityなプロトタイプを作成することがもあります。今回はXcodeでのプロトタイピングについて、以下の項目について書いていきます。

・プロトタイプのFidelity
・利用する状況
・メリット・デメリット
・工夫していること

プロトタイプのFidelity

Xcodeでのプロトタイピングでは、High-Fidelityプロトタイプの中でも、よりHigh-Fidelityなプロトタイプを作ることができます。

Fidelityとは、精度のことです。どれだけ、プロダクトの完成版に近いかを示しています。一般的にLow-FidelityとHight-Fidelityに分かれます。
Fidelityが高い方が、ビジュアルのデザインや、コンテンツ、インタラクションなどが整った状態になっています。

Low-Fidelityの例だと、ペーパープロトタイプなどが挙げられます。
紙に書くので、フィードバックや、話し合ったことからの変更が簡単にできます。また、メモなどを書き込めるので、仕様書にもなりえます。
High-Fidelityの例だと、Sketch, Flintoなどのツールを用いたプロトタイプが挙げられます。
ビジュアルも整っていて、画面遷移やアクションの結果が認知しやすいものとなっています。

状況に応じて、使い分けることが必要です。

メリット・デメリット

デメリット
Xcodeで、画面遷移や新機能追加を行うので、エンジニアの工数がかかります。
また、デザインフェーズに時間がかかると、実装フェーズに入るのが遅くなってしまうことも挙げられます。ですから期日が決まっている場合との相性が悪そうです。

メリット
ユーザビリティテストをする際に、プロトタイピングツールだと、画面の一部分しか機能していなかったり、スクロールできなかったりと、制限があるので、テスターの意識がそういったところにいってしまい、動かないことにイライラしてしまうということもありえます。そうすると、本来、テストしたいところが検証できなくなってしまうことがありえます。
Xcodeでのプロトタイピングでは、実際のアプリと遜色なく動く状態で、テスターに触っていただくことができるので、より現実味のあるフィードバックを得ることができるようになります。

利用する状況

kurashiruのアプリでは、レシピを探す体験がメインの体験となります。ユーザーの行動フローには、検索やお気に入りといった行動が付いて回ります。したがって、行動フローも加味した新機能などは、Xcodeでのプロトタイピングをして、ユーザビリティテストを行なっています。

kurashiruのお気に入りフォルダと機能を例にとってみましょう。
ユーザーは、お気に入りしたレシピを自分で作ったフォルダに分類することができます。自分でフォルダの名前をつけ、自分で分類します。
こういった操作をする際に、普通のプロトタイプなどでは、決まった部分しかタップできないので、ユーザーの意図が反映されません。それでは、テスターも戸惑ってしまう可能性もあります。

ユーザーの行動の結果が、他の画面にも影響がある場合などは、Xcodeでのプロトタイピングを利用しても良いかもしれません。

工夫していること

今も試行錯誤しているのですが、デザインフェーズでのサイクルをいかに回すかを考えると、最速でプロトタイプを作ることが重要だと考えています。そのために工夫していることを書いていきます。

早い段階での情報共有
デザイナーがUIデザインをするときは、一旦紙にワイヤーフレームを書いてから、Sketch等でモックアップを作り込みます。
僕は紙のワイヤーフレーム作成が終了した段階で、情報を共有してもらうことにしています。
そうすることで、抜け漏れを防げたり、実装上の都合などもデザイナーに伝え、認識をすり合わせることができたり、プロトタイプで実装しないものも決定できたりします。
また、その時点で必要な画面や機能がわかるので、プロトタイプの実装を開始できます。それによって、モックアップの作成完了の待ちが発生しないので、デザインフェーズでの時間を短縮することができます。
モックアップが出来上がったあとは、Zeplinで共有してもらって、デザインを当てはめていくという、通常の開発フローのように進めていきます。

こだわりすぎない
アニメーションやピクセル単位での位置調整などにこだわりすぎないようにしています。こだわりすぎると、そこに時間がかかってしまうので、それとなくな感じにしています。
例えば、リストの追加・削除のアニメーションなどは、iOS標準のアニメーションを用いたりします。
かっこよいアニメーションは、かっこよい分、イージングなど細かい調整が必要なので、そういったものは、実装フェーズに回すようにしています。

コードを捨て去る覚悟
最初の方は、デザインフェーズでの実装を、実装フェーズでそのまま、利用できるようにと、アーキテクチャなども意識して、ある程度の再利用性を考えたコードを書いていました。
しかし、スプリント内で複数回ユーザーテストを行うとなると、結構時間がないので、再利用性は無視して、結構ゴリゴリで汚いコードで実装したりしています。もちろん一部のコンポーネントは、そのまま、利用できたりします。そこらへんは、実装フェーズでの実装者に任せています。

-----

Xcodeでのプロトタイピングは、エンジニアの工数もかかってしまうのですが、より不確実性を減らしたプロダクト開発をすることができます。
うちの会社ではこうやっているという例があれば、ぜひ教えていただきたいです。

kurashiruのデザイナー募集
最後に、delyではUI/UXデザイナーを募集しているので、リーンなプロダクト開発に興味がある方の参加をお待ちしております。

クラシルのユーザー体験を磨き上げるUI/UXデザイナーを募集！ by dely株式会社