デザインと修正のためのコミュニケーション

こんにちは!
今回のテーマは「デザインと修正のためのコミュニケーション」です。
デザインに関わる上で避けられない「修正」への対処方法について、アプリ開発の観点からお話しします。
これからデザイナーとして世に羽ばたく方や、同じテーマで悩んでいるよ~と言う方に見て頂ければと思います。


デザインと修正

作っても直しても終わりの見えない修正、締切直前の戻し、追加依頼…。
自分のデザインが悪いからいけないんだと悩んだ事はありませんか?

それは、あなたのデザインが悪いのではなく、コミュニケーションが足りていないだけかもしれません。

修正はデザイナーにとって切っても切れない関係なので、ある程度はどうしようもない事です。なので、必要以上に気に病む必要はありません。
何事も、一発OKでトントン拍子に物事が完璧に上手くいく事はないからです。
クライアント、ディレクター、SE、営業など、様々な役職と価値観を持った不特定多数の人間が関わるプロジェクトであれば尚更です。

個人的な趣味の作品でない限り、デザインは1人で考えて完結させられる物ではありませんので、プロジェクトメンバーが納得出来る落とし所を考える事が大切です。
その対策として必要なのが「コミュニケーション」です。

コミュニケーションを活用して、不要な修正を回避し、必要な修正にしっかり時間を掛ける事で、良いデザインが作れるように工夫してみましょう!


デザインと修正のためのコミュニケーションとは

コミュニケーションと言っても、みんなで仲良くしましょう!と言うお話ではありません。
ここで言うデザインと修正のためのコミュニケーションとは、「途中のデザインを見せる」と言う事です。

途中のデザインと言うのは、「プロトタイプ」「ラフ」「全体像はまだ出来てないけど部分的に出来ている物」などのことです。

いきなり全力で100%の完成品を作って見せるのではなく、20%でも50%の完成度でも良いので、状況に合わせて途中経過を随時プロジェクトメンバーに共有して下さい。
こうする事で結果的に修正の負担を軽減する事が出来ます。

「未完成の物を見せるのは嫌だ…」「作り途中の半端モノなんだから修正しろと言われるに決まってるじゃないか」と抵抗感がある方もいるかもしれません。
どうして完成品ではなく未完成品を見せる事に意味があるかと言うと、修正が発生する原因の1つである「イメージと違う」への対策です。

全力で生み落とした100%の完成品に「イメージと違う」と言わてしまうと、それまで掛けてきた時間や労力が無駄になります。
また、ガチガチに作り込んでしまったが故に、細かい修正が出来なくなってしまいます。最悪の場合1から作り直す…なんて事も少なくありません。
更に、締切直前にこれを言われてしまうと、修正に掛けられる時間がギュッと短くなります。こうなると、とにかく締切に間に合うように作る事になりますので建設的でないです。

極端ではありますが、下記は、「イメージと違う」と言われるパターンの例です。

デザイナーとクライアントの間に「春らしい花」「可愛さ」「シンプルさ」に対する認識のズレが生じた為、このような事が起きてしまいました。
クライアントとしては「花なら何でも春らしいし可愛い」「花のイラストはシンプル(フラット)に」と考えていました。
デザイナーとしては「春らしい花=桜」「可愛らしくなるように、ピンクや淡い雰囲気に統一」「ゴチャゴチャさせずにまとめよう」と考えていました。
途中でこの認識のズレに気が付けてれば、根本から覆るような修正は回避出来たはずです。

これは誰が悪いと言う話ではなくシンプルに、デザイナーがクライアントの求めるイメージを理解しきれなかった、クライアントがデザイナーにイメージを伝えきれなかっただけに過ぎません。
そもそも言葉や、ネットや雑誌から拾ってきた参考画像を数枚見て合わせただけの認識で、デザイナーとクライアントがお互いのイメージをピッタリ合わせる事は難しいです。
人間の想像力には差や偏りがあります。そこを補う為に「途中のデザインを見せる」事が大切なのです。


途中のデザインを見せよう

途中で見せるタイミングはプロジェクトの規模にもよりますが、基本的にデザインする中で「ここはどうしよう」「ここは意見が割れそうだな…」と思ったら、それが見せ時です!
全体の20%の完成度だったとしても、確認したい事や気になった事があればすぐにプロジェクトメンバーに確認してもらいましょう。
大きなプロジェクトほど段階的に細かく途中経過を共有する事が有益ですし、小さ目のプロジェクトであればまずは70%くらいの完成度まで作った方が適切な場合もあります。

20%の完成度と言っても、ある程度キリの良い所までデザインを落ち着かせる必要はあります。
「プロトタイプ」「ラフ」「全体像はまだ出来てないけど部分的に出来ている物」など、確認したい問題点や状況に合わせて作ってみて下さい。
あくまでキリ良くなれば十分ですので、プロトタイプなどを作るのに時間を掛けすぎないでください。どんな要素があるのか、どんな問題点があるのか見てわかるレベルであれば完成度は重要ではありません。

途中でデザインを見せる目的としては、共通のイメージを共有する事で、お互いの認識のズレを早期発見し対処する為です。

この「認識のズレ」とは病気のような物で、発見が遅れると重症化しやすく手遅れのリスクも高まります。認識のズレが重症化した結果が「イメージと違う」です。
認識のズレも病気も、早期発見できた方が対処しやすく完治も早いです。
また、あえて完成度を抑える事でクライアントからの修正や要望に臨機応変に対応する事が出来ますので、100%作り込んだ物を修正するよりタイムロスが少なくなります。

クライアントとしても、想像だけでは考慮出来なかった部分を視覚的に補えるので、「想像では良かったけど、実際に形になると微妙だな…」など問題点に気が付くことが出来ます。
デザインを見ながらだと、「ここはもっとこうして欲しい」と言う具体的な指示も出しやすくなります。

途中のデザインを見せて、修正点があればプロトタイプを20%ほどの完成度で作っていくのも良いですし、比較的軽微な問題であれば打ち合わせの最中にラフをササッと描いてすぐに確認してもらうのも良いです。
このようにコミュニケーションを重ね、細かい部分も認識を刷り合わせてデザインを作って行ければ、最終的に完成した物が「イメージと違う」とはならないと思います。少なくとも致命的な修正は事前に防ぐ事が出来ます。


おわりに

いかがでしたでしょうか?
そもそも何故修正が来るのか。それは、デザイナーもクライアントも良い物を作りたいと考えているからに他ならないと思います。
ですが、タイミングとコミュニケーションによっては熱意が空回ってしまう事もあります。
そうならない為にも、修正を恐れるのではなく、不要な修正を防いで必要な修正に時間を掛けられるように、デザイナーとして出来る事を事前に行う事が大切です。

デザインと修正でお悩みの時は、ぜひ試してみて下さいね。

それではまた!デジマースのコンでした。

プロトタイプ/プロトタイピングの活用

今回は「起案」と同時にプロトタイプをつくる「プロトタイピング」の工程を進めてしまうことで、
より多くのサービスをUXを意識出来るレベルまで具現化して並行提案(開発)出来ないか妄想してみました。


開発コストがリスクだったプロトタイプ

商品開発中に全容認識が容易になるプロトタイプの製作は有意義な作業であることは明確でしたが、
プロトタイプ自体の開発期間/コストが問題でそれを行わず、
本開発を進めてしまう現実がありました。
そんな中、
モバイルwebサービス開発支援を目的とした「プロトタイピングツール」の台頭により状況は大きく変わってきております。
詳しくない方でも名前を良く聞くのは、
「Prott」「Sketch」「Adobe Experience Design」でしょうか。

個人的には以前紹介した「Adobe Animate」でもアプリ寄りなプロトタイピングも出来ると考えております。

プロトタイピングツールによって、
従来専門的なスキルと多くのリソースが必要だったサービス設計のやり方にも変化が起きました。

HTMLやプログラムの知識が無くても全体像の構成サンプルをマウス操作で作ることが出来、
実機確認出来る状態を他者へ共有シェア、遷移図の資料等の自動書き出しまで行えるツールもあります。
つまり、
リスクだったプロトタイプ制作のデメリットが解消されたのですから取り組まない手はありません。


プロトタイピングのメリット

従来からサービスの有効性/ユーザビリティーの検証方法として、
「ユーザビリティー調査(テスト)」が提唱されておりますが、
アジャイル的迅速なサービス開発が求められる現在ではその非効率特性が顕著に表れてきてしまいました。
サービス設計者はスケジュールを考慮すると、
まず「削減」を考えるフェイズになってしまっているのが実情です。

非効率化を解消し、
プロジェクトメンバー間での効率的な共有をする目的で開発されたプロトタイピングツールがあれば、
まずは自身もしくは、プロジェクトメンバー全体での認識として、
満足度の高いイメージ/ビジョンが反映されやすい製品プロトタイプが作れる環境にはなってきているのです。

以前は、長い開発期間を経過するなかで薄れてしまったイメージ/ビジョンがあり、
ユーザビリティー調査で「答え合わせ」するまで良し悪しの判断が出来なかったことが、
ツールの導入により素早くプロトタイプが作成出来、
温度差/感覚差が生まれにくい環境が整ったことが最大の導入メリットと言えます。


従来の開発フローで進めるリスク

効率的なツールを競合他社が使うなか、
従来の手法で確実なサービス設計を進めるリスクを考えてみます。

どんな「ひらめき」や「アイデア」が市場で成功するかの確証は残念ながら得られません。
そんな中進めるサービス設計について、
従来のマス需要に向けていれば十分な成功が得られた時代は終わってしまいました。

生活環境が多用化した現在では、同じ環境/価値観自体が少なくなり、そのリサーチしやすい需要も少なくなってしまいました。
先が暗いマーケティング事情なのか定かではありませんが、
「大衆向けヒット商品」が出にくい時代になったことは判断できます。

そんな中で「確実なサービス設計」で進めることはリスクが大きく、
プロジェクトラインを多く抱えられない企業では大きな機会損失に繋がるので、
多くのアイデアを次々と短い期間で具現化し、
そしてビジネスモデル検証するフローが求められると考えます。
そこで可能性を活かす理想論が、「起案」と同時に「プロトタイプ」まで進めてしまうプロセスです。


「ビックプロジェクト」ではなく「ひらめき」の可能性

多用化した生活環境、多様化した需要は裏を返せば、
起案者自身の個人的な需要でさえも、必要とするニッチな需要層である可能性が考えられます。

都合が良すぎる話ですが、
例えば、起案者自身がプロトタイピングツールを使いUX設計を提案出来れば、
残ったリソースでも多くのプロジェクトラインを同時に立ち上げることも可能なのではないでしょうか。

「数打てば当たる」ではなく、
「数打てなければ可能性が埋もれる」でしょうか。

サービスの提供期間についても短く変化してきている感もありなおさら…ではあります。

プロトタイピングツール「Adobe Experience Design」については、
Adobe Creative Cloudのサブスクリプション契約下であればすぐにでも導入出来ます(Mac/Windows10環境)

まずは無料体験期間のあるツールを使用してみてはいかがでしょうか。

次回も、サービスUX設計の話題をしたいと思います。
以上、サービスデザインに関わっているデジマースのネモトでした。

簡単!ペーパープロトタイピング

こんにちは!
今回のテーマは「簡単!ペーパープロトタイピング」です。
ペーパープロトタイピングとは何なのか、どうやれば良いのかなどを、アプリ開発の観点から説明していきたいと思います。

ディレクターや企画職など、これからペーパープロトタイピングが出来るようになりたい!と言う非デザイナーの方向けの内容になっています。
ぺーパープロトタイピングは誰でも簡単に出来る上、仕事の効率化に有効だったりとメリットが沢山ありますので、ぜひ試してみて下さいね。


ペーパープロトタイピングとは

ペーパープロトタイピングとは、簡単に言うと「紙で試作すること」です。
「こんな感じにしたい」と言うアプリ画面の案を手描きし、完成した時のイメージを視覚化します。
書き出したイメージを元に、遷移や画面の要素を検証し、アプリが使いやすいかの確認を行います。


ペーパープロトタイピングをやるべき3つの理由

ペーパープロトタイピングですが、絶対にやらなければいけない物ではありません。
ですが、これを行うことで得られるメリットは沢山あります。

①素早く作成・修正が出来る
紙とペンさえあれば誰でもすぐ作ることが出来ます。難しいソフトの技術や知識は必要ありません。
イメージを描いては直しを繰り返し、スピード感を持って検証を行う事が出来ます。

「自分は絵が下手だから…」と言う方も大丈夫です!丸や四角などの簡単な図形と文字さえ描ければ出来ます!
遷移や画面の要素の検証に、見た目のクオリティは重要ではありません。何度も検証を行うことが大切ですので、素早く描いたり描き直したりできるペーパープロトタイピングが適しています。

Adobeソフトやパワーポイントを駆使して綺麗に作る必要はありません。
むしろ作成に時間が掛かってしまうので、この段階ではソフトに頼らない方が良いです。
綺麗な線や色合いなど見た目のクオリティが気になって、そこを整えるのに時間が掛かってしまうからです。ここで時間を掛けるべきなのは、描き終わった後の「検証」です。
それに、いくら綺麗に作っても、後々「やっぱりこうしたい」と内外から修正点が沢山出てきます。
ガチガチに作り込むと修正がし辛かったり、大幅な修正になるとそれまでに掛けてきた時間が無駄になってしまいますので、手描きがオススメです。

 

②コミュニケーションツールとして最適
描き出したイメージはすぐプロジェクトメンバーに確認してもらいましょう。そうすることで、メンバー全員が共通のサービスビジョンを持つことに役立ちます。
言葉だけの説明ではイメージすることが難しくても、図として視覚化されている事で認識のズレが軽減されるからです。
また、具体的なイメージを見ることで問題点にも気が付きやすくなり、その場で皆の意見を聞きながらすぐ描き直すことが出来ます。

「思っていたのと実際に見るのとでは違った」と言う、修正の連鎖を軽減することも出来ます。

③後々の手戻りを防ぐ
後々の工程、デザインカンプが完成した、テストアプリが出来た、と言う段階で大きな手戻りが発生しないように防止する為でもあります。
上記の段階まで来て「使いづらいから直したい」と問題が発覚し、解決するには大幅に修正する必要がある…となると、それまでに掛けてきた時間が無駄になるばかりか、更に時間とコストが掛かります。
修正する為に必要なだけ期日や予算の調整が出来れば良いのですが、なかなか難しい場合も多いと思います。
「このアプリは使いやすいか」「要素が足りていて辻褄があっているか」など根本的な問題を確認する為に、ペーパープロトタイピングを行ってください。


ペーパープロトタイピングっていつやるの?

ペーパープロトタイピングを行うタイミングですが、これはそれぞれの開発状況によって異なるかと思います。
今回は例として、「画面遷移図/サイトツリーが完成した後に、ペーパープロトタイピングを行った場合」を想定して進めたいと思います。
この段階でペーパープロトタイピングを行う目的としては、遷移図の整合性の最終確認を行う為です。

絶対にこのタイミングでペーパープロトタイピングをしなければいけない!と言う物ではなく、あくまで弊社の場合はと言う一例なので参考程度に見て下さいね。

「画面遷移図ってそもそもどのタイミングで必要なの?」と言う方は、こちらに詳しく載っていますので、ぜひ読んでみて下さい!


ペーパープロトタイピングに必要な物

ペーパープロトタイピングに必要な物は下記の通りです。

■紙
■ペン
■スマホ

たったこれだけあれば出来てしまいます!
場合によって描く場所は「ホワイトボード」や「ポストイット」などでも良いです。


ペーパープロトタイピングのやり方

①スマホの画面を描く
紙に縦長の長方形を描きましょう。
これはスマホの画面を表しています。手描きでザックリ描いてしまって大丈夫です。

線がぶれるのがどうしても気になる、と言う方は、パワポなどでテンプレートだけ作ってしまっても大丈夫です。
テンプレートは紙に印刷して使ってくださいね。

 


②要素を描く
ヘッダーやフッター、ボタンや画像など、必要な要素をどんどん描いていきましょう。

ここのポイントは「作り込み過ぎないこと」です。
画像は斜線を囲んで表現したり、重要なタイトル以外のテキストは省略して線で表現したり、アイコンは簡素な物や仮の図形を配置する、など。
また、色を付けたり装飾をする必要もありません。ペーパープロトタイピングのメリットである作成スピードが損なわれてしまうからです。

その画面にどんな要素があるのか伝われば十分ですので、細部に時間が掛かり過ぎないようにすることが大切です。


③遷移を確認する
「アプリのTOP画面からどこへ遷移するのか」など、遷移の確認をしましょう。
言葉だけでなく、遷移する順に隣合わせにしたり、線で繋げたり、画面ごとに切り分けて並べたりと、見て伝わるようにするとわかりやすいです。

 


④実機で確認する

紙の上で全体像が掴めたら、実際にスマホで見るとどのようになるか実機確認を行いましょう。
紙に描いたイメージをスマホで撮影して、画像をプロトタイピングアプリ(Prott、Marvel、POPなど)に取り込みましょう。
※プロトタイピングアプリとは、静的な画像に「ボタンを押して遷移する」など動的な効果を付けることが出来るアプリです。
実際にアプリを見る時と同じような画面比率・動作を確認出来るので、より現実的な検証をすることが可能です。

 

紙の上でどんなに考え尽くしても、いざ実機で確認すると思っていたのと違った…なんてことはよく起こります。
「ボタンはこの位置にあるのが適切か」「遷移は適切か」など、実機で検証を行い、ペーパープロトタイピングの段階で問題点を修正出来るようにしましょう。


おわりに

いかがでしたでしょうか?
ペーパープロトタイピングのやり方をまとめてみましたが、思ったより簡単だったのではないでしょうか!
やり方事体は簡単でも、アプリによっては必要な画面要素が多く、物理的に数が多くて大変…と言うのはあるかと思いますが…
ですが、ペーパープロトタイピングをやるのとやらないのとでは、後々の工程のスムーズさに差異が出てきます。

興味を持った方は、ぜひ試してみて下さい!
それではまた!デジマースのコンでした。

注意が必要なカルーセルパネルとユーザビリティーのポイント

カルーセルパネルとは?

カルーセル[carousel]パネルとは、
複数画像を左右にスライドさせることで表示させる展開(回転)構造を持ったWeb/UIコンポーネントです。


スマートフォンが登場した黎明期から、
カルーセルパネルはナレッジと予見が必要な敷居の高い機能であった為、PC/スマフォでの使用には賛否がありました。
特に最終スライドまでの認知は、構造上少なくなっていく傾向は止むを得ません。

実装は「jQuery」で、Webデザイナーでも簡単に組み込めることから広く利用されておりますが、
理想のカルーセルパネルソースに出会えず、適切に運用されていない状況もあるのではないでしょうか。

今回はそんなカルーセルパネルを有効活用するためのポイントを紹介致します。


使いやすさのポイント

単純に単体静止パネルとして素通りされてしまうのが一番の問題なので、気付きのアピールが必要です。

1. ちょい見せ

「単体パネル」ではなく「複数パネル」であることを認識させる表現にする。

2. 手動+時間での切り替え

停止したままではなく、一定時間経過で自動的に動かすことで複数枚を認識させる

3. 全体数の表示

全スライド数を認識させる

4. ポジション

現在のスライドの表示順番を認識させる

5. ループ

最終スライドから先頭へ戻る(ループする)ことを視覚的に伝え、最初のスライドに手早く戻れることを認識させる。

以上に上げたポイントが一つでも十分でない場合、格納されたスライドの全てを認識させるのは難しくなります。


カルーセルパネルの動きをプロトタイピング

「jQuery」などオープンソースから理想の表現が出来ているカルーセルパネルが見つかれば話は終わってしまいますが、探すにも時間がかかるのではないでしょうか。

それでは、カルーセルパネルの内容や動きが確認できるプロトタイピングして具現化してみます。

デザインも出来て、JavaScriptが出来るWebデザイナーなら問題ないのですが、壁がとても高いと思われます。
そんなプログラムに精通していないデザイナーでも作れるツールが、過去の記事紹介している「Adobe Animate CC」です。

グラフィックUIの操作で作れるためデザイナーに相性が良く、
ある程度のJavaScript命令文を項目を選択するだけで記述出来、厳密に構文を覚える必要がありません。
「再生」「停止」「任意のポイントに戻る」「条件分岐」「繰り返し」
以上を組み合わせるだけでも、
プログラマーやプロジェクトメンバーに動きを確認してもらえるプロトタイプを作ることが出来ます。


早速作る

まずは基本的なレイアウトに「ちょい見せ」搭載したプロトタイプです。
クリックでしか動作が出来ておりませんが、回転してグルグルと回るカルーセルパネル本来の動きが確認できるのではないでしょうか。


プロトタイプならではのバリエーション

追加で2種類のデザイン案も作ってみました。

動きの想像が出来、ついつい回してしまいたくなる表現なら有効です。


最後に

いかがでしたでしょうか。
オペレーションソフトやブラウザ速度の向上した現在では、多くの表現がWeb上で可能となっております。
Webデザイナーに求められるスキルも必然と増え、インタラクティブな動的コンテンツが求められてきていると感じています。

それでは次回も、サービスUX設計に関係した話題をします。
以上、デザインに関わっているデジマースのネモトでした。

シンプルゲームをプロトタイプ/プロトタイピングで作ってみる


今回は、
Webサービスのプロトタイプ/プロトタイピング(ゲーム)に挑戦します。
ツールは、以前にプロトタイピングツールの紹介記事のなかで紹介した
『 Adobe Animate CC 』(旧『Adobe Flash Professional』)を使って、
UXのエッセンスを加えていきます。

現在、FlashとFlash制作ツールは過去のものとなっておりますが、
「ActionScript」から「JavaScript」の制御に変更になる点と、
記述方法の独自の縛りを認識して進めれば、
同じオペレーションスキルで『 Adobe Animate CC 』による、
「HTML5 Canvas 」のアウトプットが作れるメリットがあります。


■まずは設計

私のスキルですが、

・Flashツールのオペレーション
・極少々のJavaScript

程度です。

そんな理由もあり、今回は課金等発生するサービスではなく、
「HTML5 Canvas 」を活かしやすい、
簡単UIワンボタンゲームを作りたいと思います。

まずは遷移図がこちら↓

なんと要素の少ないことでしょう;
しかしながら、
これらの内容全てを盛り込める時間もありませんので、
形に出来るように取り組んでまいります。

遷移図を見る限り、単純な「if文分岐」で作れそうです。

「ランキング」機能については、実現は難しそうですが、
今回の目的は、
短い期間でアイデアを展開出来る形に落とし込む「プロトタイプ/プロトタイピング」ですので、
やりたいことのイメージ/ビジョンが、
第三者に伝えられる状態になっていれば問題ありません。
最低限伝えたい雰囲気だけは再現していこうと思います。

時間が限られていますので急いで進めていきます!


■画面イメージを起こす

早速『 Adobe Animate CC 』に組み込む画像を作ります。

遷移図を参考に、各ページを『illustrator』で作ります。

アートボードを画面単位で運用ファイル名をつけて設定してしまえば
ワンアクションで全てのページが書き出し出来て便利です。
したがって、必要な画面のブラッシュアップは適宜おこなえますね。
本当に便利です。

ゲームをプレイするターゲット(今回は1970~80年代の古き良き遊び世代)に好感を持ってもらうため
液晶/LSIゲームの表現を取り入れてます。
ターゲットの懐古UX度上げていきます。

※今回は単純な内容なのですが、
「ユーザー・エクスペリエンス(ユーザー体験)」を重視しています。


■いざ組込み素材の書き出し!

必要な画像が揃ったので書き出しします。

⇒ファイル/書き出し/スクリーン用に書き出し…
です。

今回の作業は「横幅375px」で『illustrator』上で作業をしてますので、
ターゲット端末(iPhone6 サイズ 横幅750px)で使用した場合も必要な解像度が得られるように、
「x1」(倍)から「x2」(倍)に切り替えて書き出しします。
※「iPhone6 Plus サイズ 横幅1242px」がターゲットの場合は横幅414pxで作り「x3」(倍)

それではポチッと書き出し…

…細かい部品も含めてワンアクションで書き出し完了でリネームも必要ありません。
便利です。

さぁ!時間がありません!

『 Adobe Animate CC 』で簡単プロトタイプを製作するために組み込みしましょう!


■『 Adobe Animate CC 』での組込み

※オペレーションは割愛させていただけます。

組込み方はFlash時代と変わりありませんので、
ライブラリに格納した画像を「ムービークリップ」にそれぞれ設定しましょう。

ステージサイズはWeb表示時に一画面に収めたいので375×554(くらい)。

スクリプトのレイヤーを作ってJavaScriptはまとめて記述しましょう。
基本遷移アクションのスクリプトは項目を選ぶと自動である程度書き込まれます。
楽々ですね。

あとはスライドショーをつくる感覚でタイムラインを制御して実装を続けると…

こちらの状態が出来ました。



※あくまで製品雰囲気を伝えるプロトタイプなので、
挙動や当たり判定の完成度には期待しなくて問題ないです。

十分、提案したい内容は伝わるのではないでしょうか。


■UXを意識した調整

今回の目的に「UX」があります。
画面イメージなど意匠でもUXを意識して制作していますが、
最後に、楽しい体験を演出する表現を追加してみます↓



まだまだ足りませんが、
先ほどの状態より背景の草が動いていて、ポジティブな感情になりましたでしょうか。
単調な内容でも、
目的をより良く導く体験要素を組み込むだけで、
感じる体験の内容が変わってくるのではないでしょうか。

今回のプロトタイプでは再現出来ていない「スコア」、
「スコアの違いを生む要素」、共同体験が可能になる「ランキング機能」などは、
より良い体験(UX)に繋がる要素です。

是非、アイデアを形(プロトタイプ)にして、
より具体的な提案をしていきましょう。

次回も、サービスUX設計の話題をしたいと思います。
以上、デザインに関わっているデジマースのネモトでした。