UXデザインのペーパープロトタイプの講座を受けにいってきました

昨日、ユーリカ株式会社さんが催行しているUXトライアウト・2時間で学ぶペーパープロトタイプに、前回と同じくブログ書く枠として応募したところ抽選に当たったので参加させていただいたのでそのレポートです。

今回もまた詳細な内容は講義を受けたほうがより正しい内容なはずなので、主には概要と感想です。

イベント概要

UXデザイン会社のユーリカ株式会社さんで定期的に行なわれる「UXトライアウト」と題したコースがあって、基礎知識からUXデザインで行なわれる各行程ごとに2時間のワークショップ。どんなものがあるかはTECH PLAYのユーリカ株式会社|UXデザインで売れるモノづくりを応援しますのイベント・技術情報 - TECH PLAY[テックプレイ]で見ると良いと思います。

ちなみに通常は有料の講義だけどブログ書く枠は抽選枠ですが無料参加で募集しているようです。

参加動機

前回も書いたけど、良いものを作るためのUXデザインの話まで自分としても注力していきたいので。その技術を業務で活かしたいのはもちろんなんだけど、僕は個人開発も行なってるので個人でやる場合は全部を自分でやらなきゃいけない。

実は応募自体は前回のものと同時につづけざまにしたので前回と動機に違いはないものの、UXデザインの具体的な手法として例えばユーザーインタビューとかあるけど、まず個人レベルで手がつけやすそうなのはペーパープロトタイピングかなーと思っての応募。

講義について

前半は、ペーパープロトタイピングってどのようなものか、どうやってやるのか、やるための便利なツール(アプリなど)の紹介という感じ。
後半は実際にワークショップとしてやってみて、レビューしてみて、という感じの大きくは2部構成。

前半:ペーパープロトタイピングについて

まず話として、「へー」と思ったのが「評価」することを前提として作るということ。僕は何かをつくるときそれがWebでも趣味のレザークラフトでも基本的にまずラフスケッチをするんだけど、それは頭にあるものをちょっと具体化する程度のもので書き散らすことが多い。

工程としてそれも必要かもしれないけど、作るときは気分が乗ればガーっとコーディングから始めてしまう。だけどプロトタイプはちゃんと評価する、というのが違うんだなぁと思った。まあその結果が作ってる途中で「あ、これこうだとダメじゃん」とかって手戻りが発生するわけなんだけど。

で、アプリやWebの開発の場合、ペーパープロトタイピングでは全ての画面や動きなどをできるかぎり手書きでOKなので用意して、実際の操作を模して、紙を変えたり乗せたりしてシミュレーションする感じで評価するとのこと。

これは欠点として紹介されてたけど、その紙の差し替えは非常に面倒だという問題。なので例えば写真にとってデジタルツールと組み合わせてやると良いということでツールの紹介があった。

個人的にはここでFigmaの名前があがらなかったのが不思議だったけど、Sketchの名前も出なかったので、実際この講座は初心者向けなために、きっとそういうデザイナー寄りのツールではなくてまず使うための前提知識や技能が要求されないものをオススメしてくれたんだろうと思う。

ちょっと残念だったのは思ったよりこのツールの使いかたや類似ツールの説明などの話のボリュームを減らして、実際のペーパープロトタイピングの具体的なやり方とか気をつけること、守るべきルールとかをもうちょっと教えてほしかったなぁという気がしなくもない。アプリの使いかたはアプリが違えば変わってしまうので。もちろん僕は個人的にFigmaとかでやるだろうなぁ、と思ったという背景もあるけど。

後半:ペーパープロトタイピング体験

そんな説明があった後にじゃあ実際体験してみようということで出たお題は「Instagramを記憶、または想像だけで再現してみよう」というお題。

まず僕が作ったのはこんな感じ

実習

日頃から個人開発とかやるときに画面構成を書いたりしてるのと、業務でも仕様書的なものを見てるのでわりと想像はつきやすかった。

やって思ったのはInstagramはあまり使うほうではないけど、それでも迷うことなく使えている。かといってどこにどのような要素があったかというのは正確に把握してるわけでなく、なんとかそれなりに書けたのも、よくあるUIならここに置くだろうという推測で描いた要素のほうが多かった。

実際に簡易的な取り込みアプリをつかって、操作を模してレビューしてもらったりした。決定とか削除ボタンとか付けわすれた。あとは、何がどこにあるべきか、って思ったよりは難しかった。逆に面白かったのは、自分でちゃんと投稿されたかどうかのモーダルを想像できたり、「ここで多分GETのAPI叩いて、Arrayで返ってくるから」と想像してたのは無意識に発露したサーバーサイドエンジニア目線なんだろうなぁと感じて面白かった。

実際に体験してみるまでは、いきなりSketchとかFigmaとかのツールでやったほうが早くない? と思ったけどそうではなくって、触ることを意識したり、紙の状態でもいいからこれを触ったらこう反応して、というインタラクティブな動きをシミュレートすることで不足を炙りだすのにすごく役に立つと実感した。

なんというか「早く失敗する」というか。最初から最良のアウトプットを出そうとするんじゃなくて手書きでパパーっと描いてシミュレートする、過不足を早い段階で炙りだしてから問題なさそうなら次にもっとしっかりしたものをデジタルで作る、みたいな工程を組んだほうが結果的に早そう。

ただしそれが絶対というわけではなく、同じような画面や同じような部品のものは、手書きだと逆にコンポーネント化して使い回しとかできずにイチイチ書かなきゃいけないからかったるいなーとも思った。だからそういうところ上手く簡略化してやるのが良い落しどころなのかもなぁ。

まとめ

こうしてやってみたらやっぱり重要な工程だった。だけどこれだけやればじゃあUIに関してはバッチリかいうとそうではなく、使う人がどのような層なのかというコンテキストで最適な配置や表現する文言や使う単語、アイコンも変わってくる。だから他のユーザーインタビューやペルソナを想定したり、カスタマージャーニーマップも必要になってくるんだと思う。

2時間ではもちろん時間が足りないのでどうしても「お試し体験」的学習になるけど、それでも今回もなかなか良い学びでした。やっぱり何ごともトライして試して手を動かさないと。他の人はどうかわからないけど、とりあえず手をつける、体験してみる、が僕が僕を活かせる勉強のやりかただと思ってるし、そこを躊躇しないのが僕の強みだと思ってるので。

今回も今や便利ツールがいっぱいあるのに手書きでやることの意義とか効果とかも実感できたので良かった。今も職場で小さいホワイトボードが欠かせないように、デザインだけじゃなくて、シーケンスやら分岐やら、設計もわりと手で描いてみて考えるタイプなので、手書きを活かすアイデアが1つ足されたような感じ。

それと同時に余裕があれば(といってるうちはいつまでたってもそんな日は訪れないんだけど)Figmaとかももっと触っていきたいと思った。

今後もUX系の講座には参加したいと思うものの、今はそれが本業ではないのでいったんはこれくらいにして、紹介された本やUIに関するガイドラインとかをまず読むところからひとつづつ一歩づつ進むことにしよう。粛々と。

Git 初回コミットのメッセージをちゃんと決めてみる作戦コンポーネント時代のCSSの命名ルールを考えてみよう