こんにちは。HelpfeelのCTOを務める秋山博紀です。当社ではGyazo、Scrapbox、HelpfeelといったB to C(個人向け)WebサービスやB to B(法人向け)Webサービスなど、さまざまなプロダクトを開発しています。この連載の執筆は、これらのプロダクトの責任者であるエンジニアチームのメンバーが担当します。私も含めて、各メンバーは個人でもソフトウェアを開発して世に出しています。
さて、人とコンピュータの関係を考えると、二者間には常にインタフェースが存在します。本連載では人とコンピュータを介在するインタフェースに着目し、インタフェースとそれらを世に生み出すプロダクト開発について議論します。初学者の方からプロフェッショナルの方まで、何らかのプロダクト開発のヒントを持って帰っていただけるような連載を目指します。
当社Helpfeelは、さまざまな方から「プロダクトの会社ですよね」との言葉をいただくことがあります。そこで、本連載では、当社が独自のインタフェースを実装しながら便利さと楽しさを備えたWebサービスをどのように開発しているのかをお伝えします。
インタフェースを考える際の3つのヒント
プロダクト開発において、良いインタフェースを追求するためには何が必要でしょうか。最初からベストなインタフェースを考えられればいいのですが、実際は試行錯誤が必要です。試行錯誤の過程においてシステムをブラッシュアップできますし、間違った選択を取った時に手戻り少なく開発できる(あるいは開発を中止できる)のも大きな利点です。プロダクト開発における試行錯誤の例として、「ワイヤフレーム」「モックアップ」「プロトタイプ」といった中間成果物を作ることがあります。
仕様書を作って本番環境に耐え得るシステムをプログラミングするのは、それなりに骨が折れる作業です。今回紹介する「ワイヤフレーム」「モックアップ」「プロトタイプ」の3種類の中間成果物は、多大な労力を払う前に開発コストに見合う価値があるかどうかを早期に判断する材料となります。以下に、これらの中間成果物がどういった観点で活用できるのかをご紹介します。
ワイヤフレーム
「ワイヤフレーム」はシステムの画面構成や画面遷移を表す図です。基本的には無彩色のみを使って線やテキストを構成します。複数の画面構成を矢印で結ぶことで画面遷移も表現できます。読み手の想像力が要求されるものの、どういった構造を持つシステムかを俯瞰して見られるメリットがあります。
例えば「退会画面で理由を聞きたい」のような自然文(話し言葉)では人によって想像する画面が分かれるので、あなたと同僚の間では全く異なる画面を想像しているかもしれません。ワイヤフレームを作ることでこういった認識の差を減らし、同じ画面を想像しながら議論を進められます。
モックアップ
「モックアップ」は、色やサイズなど審美的な要素も含めて画面構成を表現する図画資料です。英語のmockupを訳すと「原寸模型」です。より本物に近い模型を見ることで、ユーザーが機能をどう捉えるのかを想像しやすくなります。モックアップの中でも静的なものを「コールドモック」、動的なものを「ホットモック」と呼びます。
ホットモックはクリックやタップなどのユーザーインタラクションに対応するように作ることで、実際にエンドユーザーが操作した時の挙動を紙芝居のように画面を切り替えて体感できます。コールドモックと比べるとホットモックは作成に手間がかかりますが、見た目だけではなく挙動の確認もできる大きな利点があります。
機能がシンプルな場合にはコールドモックで済ませてよいですが、複雑な画面遷移やユーザー入力を伴う場合は、ホットモックを作成するとルック・アンド・フィールの両方を確認できる分かりやすい資料になるでしょう。特に画面遷移においては実際に遷移を体感することで、矛盾や分かりにくい挙動といった、ユーザーを迷子にさせるような問題点を見つけやすくなるはずです。
プロトタイプ
「プロトタイプ」は最も完成品に近い中間成果物です。プロトタイプを作ることを「プロトタイピング」と呼びます。プロトタイピングの過程では本番環境に資するコードを書く必要はありません。機能やシステムの本質的な価値を体験できる最低限の仕様を実装します。
必要に応じてデータの入出力や通信処理を実装することもありますが、本番環境ではないので例外処理やユーザー入力のバリデーションなど、機能の本質から外れる仕様については実装を省略しても問題ないことが多いです。
見た目そのものに価値がある場合は審美的な実装を行いますが、機能そのものに価値がある場合は審美的な実装を最小限にとどめることもあります。大切なことは、ユーザーにもたらされる価値が実現可能かどうかを検証することです。
まずは手を動かして作ってみよう
ここまで、試行錯誤のための3種類の中間成果物をご紹介しました。これらの中間成果物は、必ずしも順序立てて全てを作る必要はありません。ワイヤフレームの段階で完成物が十分に想像できるのであれば、早速プロトタイピングに取りかかることもあります。状況によっては、いきなりホットモックを作ってから本番環境の実装を進めることもあります。
大切なのは、チームにとって不明な点を適切に把握し、不明な点に対してどの種類の中間成果物が理解を深めてくれるかを考えることです。もしあなたのチームが機能に対してまだ漠然とした企画をしている段階であれば、静的に概要を示すワイヤフレームを作れば十分です。一方で、より緻密に完成品を想像する必要があれば、動的かつ詳細なホットモックやプロトタイプを作るのが良いでしょう。
どのような中間成果物を作った場合でも、積極的に手戻りを受け入れる姿勢が重要です。投下したコストが低い段階で機能のフィードバックを収集することで、その機能がそもそも必要なのかどうかを議論するなど、一旦原点に立ち返れます。実は、先ほどプロトタイプの例に挙げた機能は、実際にはリリースしないことを決めました。
もし、あなたが初めて「ワイヤフレーム」「モックアップ」「プロトタイプ」といった言葉を知ったのであれば、これからどのようにしてこれら中間成果物を作成すると良いでしょうか。
十数年前までは、ワイヤフレームやモックアップを作るために「Adobe Illustrator」や「Microsoft PowerPoint」といったベクター画像を作図できるツールが活用されていたように思います。ここ数年ではプロダクト開発における作図に特化したツールが登場しています。
中でもFigmaは現在多く活用されているツールの一つと言えるでしょう。Figmaはワイヤフレームやモックアップの作図だけでなく、インタラクションを含むホットモックの作成も可能です。
また、複数人による共同編集も可能なため、チームでのプロダクト開発に非常に便利です。Figmaは無料でも使えるので、本稿を読んで試行錯誤の中間成果物に興味を持たれた方は、ぜひ使ってみてください。どんなツールであれ、手を動かして試行錯誤することが最も重要です。
冒頭にも書きましたが、本連載はHelpfeelのエンジニアチームのマネージャー陣が執筆します。開発の最前線にいるメンバーがさまざまな視点からインタフェースとプロダクト開発について執筆していくので、次回以降も楽しみにしてください。
文:秋山博紀