*

エンジニアがペーパープロトタイプを作った話

   

これは　NEXTSCAPE クラウドインテグレーション事業本部 Advent Calendar 2018　７日目の記事です。

こんにちは。

今日は私がとあるプロジェクトでUXデザイン担当として、ペーパープロトタイプを作った話をしたいと思います。

 

なぜエンジニアがペーパープロトタイプ作ったのか

私は普段フロントの開発をしていますが、趣味でたまにヘタなりに絵を書いてSNSにあげたりしています。

こんなのとか。


こんなのとか。

あと、Azureもくもく会@新宿、略して”あずもく新宿”でも毎回ホワイトボードやSurfaceHubに落書きしてたりします。

そんな私なので、ビジュアルやデザインにはとても興味をもっていました。

そんな私を上司が見ていたのでしょう。

ある時、とあるPJで開発者兼UXデザイン担当として入って欲しいと言われたのです。

私は「わかりました。」と平静を装いつつ、内心”はい！よろこんで！”と思ったのでした。

 

ペーパープロトタイプを作る環境

私が参加したPJでは、スクラムによる開発でお客さまがPO(プロダクトオーナー）となっていました。

ただし、デザイナーはおらず、POとすべてエンジニアで構成された開発チーム、そしてスクラムマスターという体制でした。

プロジェクトの進め方としてまずはユーザーストーリーマッピングをみんなで作り、それからPBI(プロダクトバックログアイテム）の一つとしてペーパープロトタイプを作るというPBIを起こして、スクラムの中でペーパープロトタイプを作っていました。

 

ペーパープロトタイプを作るための準備

ペーパープロトタイプを作る準備は紙とペンだけ。

あとは、必要であれば保存用のファイルとハサミとノリです。

紙はA4のコピー用紙でもよいのですが、個人的な書き味とペンが裏写りするので、マルマンのスケッチブックを使っていました。

ペンは会社にあったプロッキーを使いました。

ペーパープロトを保管しておく用のファイルはクリアファイルにしました。

あとはちょっと書き間違った時に上から紙を貼って修正できるようにハサミとノリも使いました。

 

ペーパープロトタイプのサンプル

本物はお見せできませんが、大体こんな感じの物を作りました。

１枚せいぜい３分〜５分くらいで書いています。

しかもペンが太いし、定規も使っていないです。

ですから、どうやっても綺麗にはなりません。

ただ、ペーパープロトタイプはそこがミソで、時間をかけていないから、すぐに捨てられるし、綺麗に見えない分、誰もがすぐに意見をいいだしやすいのです。

 

ペーパープロトタイプを作ってよかったこと。

・すぐにプロダクトオーナーと画面イメージの意思疎通が図れた。

ペーパープロトタイプは早く作れるので、POと確認する時間が短縮できました。
その場で書くこともできたので、打合せにはスケッチブックとペンを持っていっていました。

チームの画面イメージの認識誤差が少なくなった。

プロダクトオーナーを含めチームメンバーがペーパープロトをベースに話ができたので、初期の段階から画面イメージのずれが少なかったです。

・画面の抜けや漏れに気づきやすくなった。

　ペーパープロトを作ると画面遷移をイメージすることができるので、足りていない部分が見えてきます。特に確認を促す時などに使うモーダル画面は頭の中だけではイメージしづらいですが、ペーパープロトタイプを書いて俯瞰することで、見えてきました。
　他にも項目の整合性（この画面にはAの項目があるけど、続きの画面にはない）とかも、ペーパープロトタイプの段階でわかるようになりました。

・工数が見積もりやすくなった。

　これは主観ですが、ペーパープロトタイプを作ったことで、画面遷移を含めて画面を見ることができるので、開発メンバーもこの画面にどれくらいかかるのか、何が必要なのかがイメージしやすくなったように思えます。さらに先に作るべき画面がわかっているので、実装方法も予め想像することができるので、心理的な安心もあったんじゃないかと思います。

 

ペーパープロトタイプを作って課題だと思ったところ

・最初に作ったペーパープロトタイプにイメージが引きずられる。

これは良かった点の裏返しなのですが、早く画面イメージが見える分、それでイメージが固まってしまうという問題があります。
ほんとうもっとより良い画面構成があるのかもしれないのですが、イメージが一度できてしまうとそこを改善として議論することは、ペーパープロトタイプ作成者が促さないとなかなか難しいと感じています。
ですから、最初にだすペーパープロトタイプは結構重要だったりすると思っています。

画面が多くなってくると辛い。

１０画面以上になってくると、書くのがちょっと辛くなります。特に全画面共通のメニューがあると辛さが倍になります。その場合は、メニューを省略するなどの工夫をしましょう。画面を見るには全項目入っていたほうが、実際の画面と似た感覚値に近づくとは思いますが、背に腹は代えられません。
もし、それでも全項目書き出したいという場合は、メニュー部分だけをコピーして糊付けするなど、リアルな共通化などが必要になります。

仕事してる感がでない。

これは個人的にですが、PCの前で一人でスケッチブックを書いているので、はたから見ると仕事をしているように見えません。
ちょっと気まずいです。

 

まとめ

ペーパープロトタイプを今回はじめて作ってみて、メリットをより多く実感しました。

特にイメージをすぐに共有できる点は、作業工数の圧縮に貢献すると考えています。

新しい画面や機能を作る場合、まずはペーパープロトタイプを作ってチームメンバーで共有するということをおすすめします。

あと、今回作ってみて思ったのは、絵の上手い下手はあまり関係なく（たいがいは線と○と文字を書くだけですし）、パーツの配置とかレイアウトのセンスが問われるかなと思っています。そこについては名著であるノンデザイナーズ・デザインブックがあるので、興味がある方はぜひご覧ください。

 - SE, スクラム , , ,