酔いどれデザイン日誌 - Drunken Design Diary -

都内でデザインファームを営む酔っ払いが、UI/UX論やデザイン思考論を書き殴ります。

都内でデザインファームを営む酔っ払いが、UI/UX論やデザイン思考論を書き殴ります。

バッドデザイン賞を勝手にノミネートしてみた-2018年度版-

今年も残すところあと1週間あまりとなりましたね。早いものです。

激動の平成30年間、数々の偉大なグッドデザインプロダクトが世界を激変させてきましたが、一方で「どうしてこうなったの?」というものも世の中にはまだまだ沢山あります。

私は職業柄、日常生活で見かけたそういった好ましくないデザイン事例をストックしておりまして、去年はそれらをまとめて記事にしてみたところ意外と反響が大きくてびっくりしました。皆さんもわざわざ声には出さないけど色々思うところはあったんだなぁと。

しかしながら、未だに公式にバッドデザイン賞を認定する機関は現れていません。去年も書きましたが、グッドデザイン賞のように良いものを良いと評価することも大切ですが、良くない部分を無視し続けていたのでは、いつまで経っても不便なものは不便なままです。

ということで、今年も勝手にやってしまいました。あくまでジョークコンテンツとしてお楽しみください。

本アワードで扱うバッドデザインの定義

  • 誤操作や誤認を誘発する意匠
  • 身体的な危険が伴う意匠
  • 精神的な不快感を誘発する意匠
  • 情報が全く伝わらない意匠
  • 課題とソリューションが大きく乖離した意匠

※なお「ダサい」「カッコ悪い」などの主観的なバッドデザインはノミネート対象外とする。

このアワードを通じて普段当たり前のように享受しているデザイン(DESIGN)の大切さと、プロジェクトにデザイナーを入れることの重要性を感じて頂ければ幸いです。

また、渾身のバッドデザイン事例をお持ちだという方は是非「#バッドデザイン賞2018」でTwitterなりInstagramなりにノミネート(投稿)してみてください。あとでエゴサしてニヤニヤします。

ええ?去年出し尽くしたからもうさすがに無いだろって?無くなってれば良かったんですけどねぇ・・・

バッドデザイン賞ノミネート作品一覧

今回は、2018年に新たに撮影したバッドデザイン事例の中から厳選した6事例を紹介します。街中で撮影する都合上プロダクトの事例が多くなっていますが、特に他意はありません。それでは、メリー・バッドデザイン!

No.1「余計なお世話」

f:id:information_architecture:20181219030132j:plain

【ノミネートコメント】

多くの場合において案内板やテプラなどの後付け情報はバッドデザインを救うが、これは全く逆に作用してしまった残念な事例だ。武蔵小杉にて発見。

今見えている「ここを押す」は、実は出口側のものが半回転して停止している状態なのだ。つまり馬鹿正直に案内を信じてゲートに突っ込むと華麗な前方宙返りをキメる羽目にになる。

案内板をよく見ると、結束バンドでゲートに固定されている。そう、この案内板はゲートの付属品ではなく、誰かの親切心によって後から設置されたものなのだ。無計画な親切心は、時に他人を傷つけるんだなぁ。

そもそも「ここを押す」という案内の意味もよくわからない。バーの上側は押したらダメなのか。というか素直に入口/出口でよかったのではないか。考え始めると疑問が尽きない、堂々の誤認部門ノミネート作品である。

No.2「スパイ専用トイレ」

f:id:information_architecture:20181219030227j:plain

【ノミネートコメント】

これは、世にも珍しいスパイ体験ができる画期的なトイレ型アミューズメント施設だ。渋谷にて発見。

このトイレに入るためには、事前に敵の幹部から盗み出した4桁の英数字に加えて2種類の図形を組み合わせた非常に強固なパスコードを用いる必要があるが、ロックを突破したところで安心してはいけない。ドアノブをよく見て欲しい。ここに示された方向と逆側にノブを回してしまうと、なんとドアが再ロックされてしまう

このラストミステリーに気付かなければ、無慈悲にもブラストビートを刻み続ける膀胱のせいで正常な思考を失っている状態で、正しいパスコードを永遠にリトライさせられ続けるのだ。えげつない。

よく見ると番号の並びも一般的な計算機や電話番号のような横方向配列とは異なる独特なもので、直感的に入力ができない。そもそもなぜ片側にしか回してはいけないドアノブがレバー型ではないのか。というか、たかがトイレのロックにしては厳重すぎやしないか・・・

一般的な形状というものがなぜ一般的として定着しているのかという真理を、体験型アミューズメントを通じて楽しく我々に教えてくれる、見事な誤操作部門・エンターテイメント特別賞ノミネート作品である。

No.3「テプラ待ち」

f:id:information_architecture:20181219030321j:plain

【ノミネートコメント】

トイレ繋がりでもう1事例。日本のトイレは世界最高峰の技術力で排泄体験-エクスペリエンス-を最高なものにするだけでなく、インテリアとしてもハイセンスでスタイリッシュなのが売りだ。

しかしこのトイレは、もうすぐ誰にも流せなくなるだろう。余計なものを極限まで削ぎ落としたシンプルなデザインは、削ぎ落とされてはいけないものまで削ぎ落としてしまった。

恐らくデザイン部門の「素材の風合いを活かしたい」という要望と、技術部門の「機能説明を明記してほしい」という要望が悪魔合体した結果生まれた負の遺産だと思われる。

公共空間に設置される可能性がある時点で摩耗することくらい想定済みだと思うのだが・・・でも大丈夫、日本にはテプラという最強の発明品があるからね!

テプラが生まれた理由を我々に再認識させてくれた、意味が伝わらない部門有力候補のノミネート作品である。

No.4「ペット」

f:id:information_architecture:20181219030416j:plain

【ノミネートコメント】

わけがわからない。某マンション内エレベーターで発見。

あまりにわからなすぎて逆に気になってきたので、このボタンについてGoogle先生に聞いてみた。「あらかじめ押しておくと乗り場でペットランプが点灯し、動物が苦手な人がペットと同乗してしまうトラブルを防ぐ効果があるボタン」らしい。・・・は?

意味がわかったところで納得ができない。これではペットを連れた人が最初に乗っているケースしか想定されておらず、ペットが苦手な人が最初に乗っていてあとからペットを連れた人が乗り込んでくるケースには対応できない。

しかもよく見ると、「ペットボタンは行き先階ボタンを押す前に押してください」と注意書きがある。なんで閉じるボタンより下に設置したのか・・・

インターフェースにおけるラベルの大切さと機能仕様を詰めることの重要性を痛感させられる、文句なしの意味が伝わらない部門・ソリューション乖離部門ダブルノミネート作品である。

No.5「30秒で支度しな」

f:id:information_architecture:20181219030644j:plain

【ノミネートコメント】

前回「世界にはたくさんの〜」と言っておきながら日本の事例ばかりだったので、ここらで海外事例をご紹介。トルコ・イスタンブールで発見。

トルコの公共交通事情は思ったよりも発展していて、日本と同じようにプリペイド式ICカードで乗車することが当たり前だ。しかも日本語表示対応ときたもんだから素晴らしい。トルコ大好き。

しかし日本の券売機と決定的に違う箇所がある。よく見ると「時間:20」と表示されている。実はこの券売機、操作を開始してからお金を投入して発券されるまで30秒のカウントダウンがあり、時間をすぎると強制的に中断→最初からやり直しとなる。せっかちすぎない??ド●ラおばさんでもあと10秒は待ってくれるんだけど・・・

なおこの画面、タッチパネルに見えるがタッチパネルではない。壊れてると勘違いした客が隣のレーンに横入りするせいで券売機周辺のカオスゲージは加速度的に上昇して行く。

さらに追い討ちをかけるようだが、日本の券売機のようにお金を入れてから何円チャージするか選ぶ方式ではない。入れたお金が全額問答無用でチャージされてしまう仕様なのだ。彼らにおつりという概念は無い。私は焦って、この後3回目のやり直しで100TL(約2000円)入れてしまったが、あとで確認すると目的地まで2.5TL。あきらかに買いすぎた。

国民性が違うとシステムの仕様も全然違うという当たり前の事実に気付かせてくれた、遠い異国からの精神不快部門・国際特別賞ノミネート作品である。

No.6「孔明の罠〜アイスバケツチャレンジ編〜」

f:id:information_architecture:20181219030929j:plain

【ノミネートコメント】

これは写真でみると何の変哲も無いただのポットだが、非常に巧妙な罠が潜んでいる。写真左のポットがロックなしで写真右の状態になる。あとはわかるな・・・某旅館の客室で発見。

人間には高度な学習能力と予測能力が備わっている。以前見た形状を記憶し、次回から効率よく物を使えるようになるという大変素晴らしい脳の仕組みだ。

このようなポットは、料理屋などでほぼ毎日見ている。否、見ていたと錯覚していた。私は自分の脳の認知能力に裏切られて、到着早々に1リットルの氷水をパソコンとカメラと財布の上にぶち撒けた

こんな芸当ができるのは、諸葛孔明をおいて他に居ない。いや孔明であってくれ、頼む。

同じ形=同じ振る舞いを期待するシグニファイア(可能性を示唆する意匠)の原則に加えて脳の認知能力の脆弱性までをも逆手に取った、非常に狡猾かつ巧妙な身体危険部門ノミネート作品である。

生活者がフィードバックすることで住みやすい社会を作って行こう

如何だったでしょうか。去年大きな反響を呼んだことで多くのコメントを頂き、その中に「素人なのでプロが作ったデザインにケチを付けるのは恥ずかしいと思っていた。」という意見がいくつかありましたが、そもそもすべてのデザインは『素人である生活者』の皆さんのために作られているはずですので、生活者側が変だ・不便だと思った時点でそれはいくらスタイリッシュで先進的であろうと、バッドデザインです。

オシャレさスタイリッシュさが先行して利用者を無視しているプロダクトはもはやアート作品であり、デザインドプロダクトと呼ばない方が妥当でしょう。アートを否定するわけではありませんが、製品として市場で販売する以上、最低限は利用者を意識すべきだと私は思います。逆に機能的でもダサすぎれば売れないのはわかっているので、何事もバランスですね。

また、最後の事例のように誤操作や誤認は時に身体や資産に大きな損害を与える危険をも孕んでいることは誰かが言い続けていかなければならないと思い、今年も断行しました。

たかがデザイン、されどデザイン。企業のデザイン担当者の皆様におかれましてはこれから新しい時代に変わって行くにあたり、改めてデザインの基本の一つである「正しく伝える」ことを意識する重要性を認識していただければ幸いです。

私は、生活者全員がバッドデザインをフィードバックしていく文化が根付いていくことで、世の中が少しずつでも暮らしやすくなっていくことを願っています。

一応の成果(?)なのか、去年のエントリーNo.4の「乱視案内板」は現在、再施工されて見やすくなっていることを確認しました。このブログか、もしくは他の生活者からのフィードバックが担当者のもとにまで届いたのかもしれませんね。

この記事を読んだ皆さんも、日常生活のなかで不便だと思ったものはどんどん発信してみてください。通常、企業はユーザの声をお金で買っていますので、彼らにとっても不便さのフィードバックは嬉しいはずですので。

それでは皆さま、良いお年を!

UIデザイナーは何にコミットすべきか?どこへ向かうべきか?

はい。前回の記事から1年近く経ってしまいましたね。光陰矢の如しとはこのことかと身を以て感じ候。あまりに更新してなさすぎて、はてブProの課金が切れて一時アクセス不可になっていたのを人から指摘されるまで気づかなかったほどです・・・すみません、ありがとうございました(シェア数とかリセットされちゃいましたが・・・)。

さて、この1年はUIデザイナーとしての立ち回りが一番多く、いろんな現場でいろんな思想をもったいろんな人たちと一緒に仕事をしたりお話したりしてきました。そんな中で、まあ流行りというのもありますが「UIデザイナー」という肩書きの人、増えたなぁというのが興味深くてですね。多分、みんな最初からUIデザイナーでデザイナーのキャリアスタートさせたわけじゃないと思うんですよね。途中のどこかのタイミングで●●デザイナーからUIデザイナーに転生(?)したのかなと。

そういう背景もあってか、結構人によって思想とか重要視するものの順位がまちまちだったりしていて、肩書きこそ同じでも全然違うスキルセットだなっていう人も居たりしまして。それはそれで面白いんですが、一応ここはデザイン系考察ブログ(いま命名した)なので、ここはいっちょ自分なりの「UIデザイナー観」みたいなものを書き残しておこうかなと、思い立った次第でございます。

ということで、「UIデザイナーは何に留意すべきか」というところと、「すでにUIデザイナーだけど、この先どのようにキャリアを積めばよいか」ということについて、自分なりに書き記したいと思います、来年UIデザイナーに転生しようと思っている方、参考にしてみてね。

目次

UIデザイナーは何にコミット(責任を持つ)すべきか?

いきなり核心に迫るスタイル。いまUIデザイナーだよという人もそうでない人も、UIデザイナーは何に最も留意し責任を持つべきか考えてみてください。多分、自分の業界や現在の立場、プロダクトのプラットフォームなんかによって重要視している文脈がだいぶ違うんじゃないかなと思います。

結論だけ先に書くと、私は「情報と価値のロスを可能な限り回避すること」があらゆるジャンルのUIデザイナーにとって最も大切だと、現時点では考えています。地味だと感じますか?では、これが最も大事であると考える理由を以下に示します。

「UIデザイナーは何にコミットすべきか」と質問した時、よく出そうな回答は「使いやすさ」と「綺麗さ(気持ちよさ)」でしょうか。たしかにどちらも大事ですが、私はそれらはUIデザインにおいては最後の1%、職人的な仕上げのこだわりの領域だと思ってます。なぜならば、いくらオシャレで使いやすいUIだったとしても、価値の50%にしかアクセスできなければ、そのUIはインターフェースとしてはクソだからです。どういうことでしょうか。

「インターフェース」は何のために存在するのか考えてみてください。迷わずクリックするためでしょうか?クリック感で気持ちよくなるためでしょうか?違いますよね。クリックをするという行為の前提として、ユーザがそのボタンをクリックする理由が必要です。つまりユーザが何らかのシステム(非電子の機構も含む)を操作して望んだ結果を得るためのものであるはずです。いくら操作がスムーズであっても、いくら綺麗であっても、望んだ結果が望んだ通りに得られないのであれば、それはインターフェースとしては失格ということです。(余談ですが某クッキーゲームはクッキーを増やすことが目的なので、気持ちの良いクリック感こそが最も大事ということでOKです)

f:id:information_architecture:20181211181415j:plain

では、ここでいう「情報」と「価値」の関係性について、もう少し具体的に例を出してイメージしてみましょう。エレベーターの開くボタンがあります。これをシステム仕様書通りに情報表示するとするならば「押している間エレベーターのドアは閉まることがなく開き続け、指を離して1秒後に閉じ始めるが、閉じている最中に再度押すと開くこともできるボタン」となります。長すぎですね。こんなものは誰も読みません。そこでUIデザイナーの出番です。情報をデフォルメ(強調のための簡略化)していくことで、システムエンジニアではない一般の子供からご老人まで、誰でも理解して価値を得られるようにしていく必要があります。その結果、三角形を二つ並べたおなじみのアイコンや、「OPEN」のようなギリギリ大事な情報をロスしない状態まで削ぎ落とされて今皆さんがご存知のあのボタンが生まれました。(なお、おなじみのあのアイコンは誤クリックが多いため最適解ではないという意見も多いですが今回の趣旨とはズレるため無視。)

このようにある一定の状況において、ある目的をもったユーザが目的を達成できるようにするユーザビリティデザインプロセスはISO 9241-11などで定義されているのですが、ここを掘り下げると長くなりすぎるため、ここでは情報をロスせず価値を最大限保った状態でユーザへ伝えるのがユーザインターフェースを作る上で最も大事であることがなんとなくわかりましたよね?という話で締めさせてください。

伝言ゲームで価値はロスする

f:id:information_architecture:20181211175001j:plain

前章では、綺麗さや使いやすさはUIにとって最も重要視すべき要素ではないということを説明したうえで、情報と価値のロスを回避することが最も大事だと述べました。では、「情報と価値のロス」は何故発生してしまうのでしょうか?

最もわかりやすい例が、伝言ゲームです。子供のころやりましたよね。最初はAだった情報が最後にはBになってしまう、あれです。情報というのはどうやっても伝達する媒体が多ければ多いほど、そして媒体の抵抗が大きければ大きいほどロスしていくものです。たとえば簡単な一文の伝言ゲームでも、間に日本語も英語も話せない外国の方を数人並べるだけでロスする情報量は飛躍的に増大するでしょう。実はこれが、UIデザイナーのすぐ近くでもよく起こっています。

UIが必要なプロダクトの開発現場における伝言ゲームの登場人物とは誰でしょうか。趣味でもない限り、まずビジネスゴールが最上位にあり、それを達成するためのシステム要件を設計し、要件を満たすプログラムを書き、プログラムをユーザが使えるようにUIをデザインするといったプロセスを辿ります。つまり、伝言ゲームの登場人物は自分を省いたこれら各ステップのステークホルダー、事業責任者(PO)・システムエンジニア・プログラマです。彼らの言語を理解しないことには、情報のロスは避けることができません。

ここはUIデザイナーが所属する組織体制や、新人かベテランかで大きく認識が異なる点ですが、私はUIデザイナーは下流工程ではなく上流工程にコミットすべきだとずっと言い続けています。何故ならば、それぞれ言語や思想の異なる3人の伝言ゲームを経て降りてきた仕様通りにデザインを起こすと、情報が大幅にロスしてしまっていて、ユーザが本当に達成したい目的と乖離している可能性が高いからです。もちろん、前3工程がすべて有能なトリリンガルばかりなら全く問題はないのですが、多分そこまで恵まれたチームというのはレアケースだと思います。ですので、ユーザに最終的に触れる情報を扱う最終防衛ラインであるところのUIデザイナーがここにコミットできなければ、クオリティが手前の工程の人間に左右されがちという非常に不安定なプロジェクトチームになっていまいます。

ちなみにUIデザイナーだけでなく、もちろん手前3工程の人それぞれが他の工程に対する知見を深めるに越したことはないのですが、現実的な話をすると上流工程側は下流工程の言語を理解する重要性はそこまで高くありません。社長がプログラミング出来なくていいのと同じです。下流工程側に居る人は正確なプロダクトを実装するために自分より上流工程で行われた意思決定や設計の意図を正確に把握しなければならない一方、上流工程側でそのやり方についてマイクロマネジメントしてしまうと、現場がめちゃくちゃになります。マイクロマネジメントがクソな理由はあえて述べません。

まとめると、情報のロスを限りなく少なくするためにはすべてのメンバーが自分よりも上流の工程についての知見を深める必要があり、かつ全行程において最も下流工程に位置するフロントエンドエンジニア/UIデザイナーこそが、最も幅広い知見と視野を持っているに越したことはないということです。

 

UIデザイナーの次のステップは何か

ここまでまじめに読んでいただいた方ならもうなんとなく結論がわかったと思いますが、流し読み勢のために改めてここまでの内容を3行でまとめます。

  • UIデザイナーは使いやすさや綺麗さ以前に「価値の維持」にコミットすべき
  • 「価値」とは、特定のユーザが特定の状況下においてある目的を達成できることを指す
  • 「価値」を維持するためには、自分よりも上流工程の人の言語を正しく理解する必要がある

ということは、上流工程側の言語を理解していくことがUIデザイナーのキャリアにおける次のステップとして適切そうですね。

ここから先は私の業界特性上、デジタルコンテンツに限ったUIデザイナーの話になります。リアルプロダクトのUIデザインはまた考慮すべき項目が異なると思いますので、その道のプロの方、誰か教えてください。

誤解を恐れず言ってしまうと、「形を作れるだけ」というUIデザイナーは、今後どんどん需要が無くなっていくでしょう。なぜならば、UIに奇抜さやオリジナリティは大抵のケースにおいて求められていないから(=すでにあるコンポーネントの組み合わせで十分なことが大多数だから)です。みんな大好きニールセン博士によると、学習効率もユーザビリティの一要素となります。つまり、Webブラウザとかスマホアプリといった同一プラットフォーム上においては、ある程度一定のデザインルールに則ったUIの方が、オリジナリティ溢れるUIよりも使いやすい。ということになります。そしてそれらを誰でも簡単に実現できるMaterial UIコンポーネントをはじめとしたフレームワークが多く充実してきており、「綺麗なボタンをデザインできます」は、徐々に職人的こだわりの領域となってきています。(アミューズメント機器やゲームにおいてはその限りではありませんが、ボタンはボタンであると認識できるギリギリの情報は保ってデフォルメする必要があります。)

ということで、現在sketchをはじめとした描画ツールでモックアップまでしか作っていないUIデザイナーの皆さんは、まずは次のステップとしてフロントエンドエンジニアやサーバサイドエンジニアたちが使っている言葉を勉強してみるといいでしょう。優しいエンジニアの人ほど「デザイナーに余計な負担をかけたくない」という心遣いでモックアップ通りによしなに実装してくれていると思いますが、このUIモックアップがどのように実装されて機能するか知りたい!知った方がスムーズにプロジェクトが進行すると思う!というような事を伝えてみましょう。よほどパツパツでない限り教えてくれるはずですよ(for engineers:実装が難しそうなUIが減りますのでぜひ教えてあげてください!書ける必要はありません。どんな工程があって何をやってるのか理解できれば十分です。)

もうフロントエンド技術もサーバサイドとの連携もある程度理解してるよ!という方は、システム要件定義のほうに首を突っ込んでみましょう。ここを担当している人はプロジェクトによってまちまちだと思いますが、大抵プロダクトオーナーかシステムエンジニアの人が握ってるはずです。いつもは雲の上で何やってるかわからない要件定義かもしれませんが、フタを開けるとなんてことはないビジネスサイドと開発サイドの要望のすり合わせ作業です。どの機能が求められており、どの機能から優先して実装していくかみたいなことを話しています。「どの機能が求められているのか」についてはUIデザイナーであるあなたが最もユーザに近い位置にいるはずですので、あなたの意見はきっと大歓迎のはずです。特定のユーザが特定の状況において目的を達成するためにはどんな機能があればよさそうか、バンバン発言してみましょう!

要件定義もすでに首突っ込んでるよ!というかたは、いよいよビジネスゴールを達成するところまでコミットしてみましょう。ここまでくるともはやUIデザイナーという枠組みではなく、プロダクト/サービス全体のデザイン責任者といったほうが妥当になってくるでしょう。もはやあなたがプロダクト/サービスの良し悪しを決定する要です。正解はありませんので、これまで経験してきた下流工程で行われていることを意識しながら、最高のユーザ体験を作り上げるために最適な選択をして行ってください。

まとめ

想像以上にまじめな内容になってしまいました。2017年・2018年は色々なツールやフレームワークが充実してきたことで、これまでよりも多くの人たちがUIデザインについて触れるキッカケが多くなった年だったかと思います。もともとUIデザイナーだった人も、思い切って肩書きごとUIデザイナーに変えてしまった人も、これから転生しようかなと企んでいる人も、またこれからUIデザイナーを拡充していこうという経営者や人事部の方にとっても、この記事が何かしらの道標になれば幸いです。

余談:プロジェクトマネージャーとプロダクトマネージャーについて

会社によってはデザイナーやプログラマ(スペシャリスト)からプロジェクトマネージャー(管理職)へのステップアップを以って「昇進」としているところもあるように思いますが、私はあの昇進は間違っていると思います。スペシャリストとして技術を深く掘り進め極めていくことが昇進の代わりという会社ももちろんあるでしょうが、少なくともデザイナーやプログラマの上位職があるとすれば、プロジェクトマネージャー(人的リソースの管理)ではなく、プロダクトマネージャー(製品クオリティの管理)であるはずです。

なぜかプロダクトがどう実装されているか知らないディレクター上がりの人がプロダクトマネージャーになり、進行管理なんかやったことないスペシャリストがプロジェクトマネージャーにされるのをみていてモヤモヤしたので、書き残させていただきました。プロダクトにずっと向き合ってきた人がいきなりスケジュールを統括しろと言われるのは、スキルの連続性が失われており不自然ですよね。どっちも英語略称にするとPMなのがややこしいんだと思います。

バッドデザイン賞を勝手にノミネートしてみた-2017年度版-

忙しい年の瀬ですが、皆さま如何お過ごしでしょうか。

さて、皆さんは「グッドデザイン賞はあるのにバッドデザイン賞が無いのはおかしい」という風に思ったことはありませんか?私は職業柄、日常生活で見かけた良いデザイン事例と悪いデザイン事例を写真に撮ってストックしているのですが、その中には「本当にこれギャグじゃないの?」というレベルのバッドデザインがあったりするんですよね。

良いものを良いと評価することも大切ですが、良くないものを無視するのは人類の進歩に大きな影を落としているような気さえします。ということで、勝手にアワード化してしまいました。2017と付いてますが、私が見つけたのが2017年だったというだけで製造年度などとの相関性はなく、特に意味はないです。あくまでジョークコンテンツとしてお楽しみください。

【追記】Twitterの方で一部画像が自分で撮影したものではないのでは?とご指摘頂きました。確認調査してみましたが、No.3にネット上で拾ってきた事例の画像が混じってしまったようです。お詫び申し上げると共に、来年度版を実施する場合は、掲載写真の管理を徹底するよう注意致します。すみません。

本アワードで扱うバッドデザインの定義

  • 誤操作や誤認を誘発する意匠
  • 身体的な危険が伴う意匠
  • 精神的な不快感を誘発する意匠
  • 情報が全く伝わらない意匠
  • 課題とソリューションが大きく乖離した意匠

※なお「ダサい」「カッコ悪い」などの主観的なバッドデザインはノミネート対象外とする。

このアワードを通じて普段当たり前のように享受しているデザイン(DESIGN)の大切さと、プロジェクトにデザイナーを入れることの重要性を感じて頂ければ幸いです。

また、自分も渾身のバッドデザイン事例をお持ちだという方は是非「#バッドデザイン賞2017」でTwitterなりInstagramなりにノミネート(投稿)してみてください。あとでエゴサしてニヤニヤします。

バッドデザイン賞ノミネート作品一覧

今回は2017年に撮影したバッドデザイン事例の中でも、選りすぐりのレジェンド級バッドデザインたちを部門別にノミネートさせて頂きました。街中で撮影する都合上プロダクトの事例が多くなっていますが、特に他意はありません。それでは行ってみましょう!

No.1「危険そうなボタン」

f:id:information_architecture:20171206165121j:plain

【ノミネートコメント】

巨大な筐体に1つだけ搭載されたボタン。押したらヤバそうなカラーリング。ダメ押しで注意の表記。このいかにも危険そうなボタン、実は「エレベーターの呼び出しボタン」である。誰が押すんだこのデザイン・・・金沢の地下通路で発見。

良く見ると下の方に車椅子専用のボタンが付いているが、多分車椅子の人も赤色と注意書きしか目に入らないんじゃないかな。 どう見ても非常ベルが鳴りそうな、見事な誤認デザイン部門ノミネート作品である。

【追記】「注意」のところに何て書いてあるか読めねーよというご意見が多かったので追記します。「戸に触れないこと。けがをする恐れがあります。」と書かれています。なぜ戸に貼らなかった・・・

No.2「フェイクボタンonテプラ」

f:id:information_architecture:20171206165141j:plain

【ノミネートコメント】

エレベーターつながりでもう1事例。私はこの時生まれて初めてボタンに「ボタン」というテプラが貼られているのを見た。

どう見ても光っている部分の階数が書いてあるブロックがボタンにしか見えない。というか実際テプラがあってもそちらを押してしまった。

シグニファイア(可能性を示唆する意匠)が完全に逆に作用した錯視効果の極致であり、人間は本能的に一番出っ張っているところを押したくなるものなのだという事を再確認させてくれる悟りプロダクト。

何故ボタンと階数表記を並べなかったのか。というかボタンを光らせるのではダメだったのか。考え始めると疑問が尽きない、見事な誤操作デザイン部門ノミネート作品である。

No.3「デュアルテプラ」

f:id:information_architecture:20171206165201j:plain

【追記】こちらの写真は、Twitterで静岡茶さまが公開されたツイートからの転載になります。

【ノミネートコメント】

テプラと言えば貼られたらデザイナーの負けでおなじみだが、これは滅多にお目にかかれない1つのアイコンに2つのテプラが貼られてしまった事例だ。

アイコンだけでは意味が伝わりきらない問題は遥か昔から言われ続けているが、アイコンが何の絵なのかまで併記されたのはこれが歴史上初ではないだろうか。

恐らくスタイリッシュにしようと曲線を極力排除した結果、注射器にしか見えなくなって救護室と間違えて入ってくる人が多かったのだと推測される。

無駄にスタイリッシュにしてもロクなことにならないという教訓を我々に与えてくれる、見事な意味が伝わらない部門ノミネート作品である。

No.4「乱視案内板」

f:id:information_architecture:20171206165217j:plain

【ノミネートコメント】

もう、見たまんまである。新木場で発見。案内板としての意味を全く成していないので、都は今すぐ撤去して再施工すべきだと思う。

この案内板がどうなっているかというと、古い案内板の上に(前の案内板を剥がさずに)新しい案内板が張られているのでバックライトで透け透けになっているのだ。雑施工極まりない。

なおこの状態になるのは夜間のみであり、昼間は普通に読める。バックライトが付いてる事を確認して施工すればこんな面白いことにはならなかっただろうと思うと、ある意味公共工事の怠慢が生んだ奇跡の産物と言える。

仕様の確認とチェックフローは怠らないようにしようという戒めを我々に教えてくれる、見事な意味が伝わらない部門/イージーミス特別賞ノミネート作品である。

No.5「ふれあえない灯」

f:id:information_architecture:20171219230615j:plain

【ノミネートコメント】

「ふれあい灯」と称されたこの装置は、ボタン押すと上に搭載されたランプが光り、けたたましい音が鳴って周囲の人の視線を集めることで困った人を助けることができるのだそうだ。・・・え?

取り扱い説明には「(中略)外国人の方で、お手伝いを必要とされる方のための〜」とあるが、英語表記は一切無い。ゆえに外国人が困ってもこれを押すことは絶対に無い。

また下段には「このランプが点滅していたら、お手数ですが近くの社員をお呼び止め〜」とあるが、なぜ他の客にそれをやらせるのか理解が及ばない。ランプも音も無くして社員の持ってる端末に直接通知が飛ぶとかではダメだったのか・・・というか困ってる人が直接社員を呼び止めるではダメだったのか・・・

そもそも困っている時にわざわざボタンのところまで移動する人が居るのだろうか。人は大抵、困ったことが起こったその場所で人を呼び止めるものである。ソリューションとしても入り口で「要介助/need help」と書かれた名札を配った方がはるかに効果的で安上がりな気がする。

360°あらゆる方向にツッコミどころ満載な、見事なソリューション乖離部門ノミネート作品である。

No.6「孔明の罠」

f:id:information_architecture:20171206165254j:plain

【ノミネートコメント】

写真では分かりにくいと思うが、全く同じデザインの2枚の連続したドアがあり、手前側がスライド式の自動ドア、奥側が観音開きの手動ドアになっている。これは本当に危ない。

タチの悪いことに手前(1枚目)が自動なので、2枚目も自動と誤認させ高確率でガラスに衝突するような巧妙なトラップになっている。実際撮影中にサラリーマンが何人か激突していた。これはきっと諸葛孔明の仕業に違いない。もし手動と自動が逆の順番ならここまで危険にはなっていなかっただろう。

このビルを設計した人は、カッコよくて美しいエントランスの設計図を引くより先に、人間工学と認知心理学の基本をきっちり勉強してきた方が良いと思う。

同じ形=同じ振る舞いを期待するシグニファイア(可能性を示唆する意匠)の原則を逆手に取った、非常に狡猾かつ巧妙な身体危険部門ノミネート作品である。

生活者がフィードバックすることで住みやすい社会を作って行こう

如何だったでしょうか。人様のつくったものを気安くバッド呼ばわりするのは正直気がひけるのですが、誤操作や誤認は時に身体や資産に大きな損害を与える危険をも孕んでいることが理解できたかと思います。

たかがデザイン、されどデザイン。目先の格好良さや目新しいソリューションを採用しようとする前に一度立ち止まり、デザインの基本の一つである「正しく伝える」ことを意識することの重要性を改めて認識していただければ幸いです。

これからも引き続き街中のグッドデザインとバッドデザインを勝手に収集していくつもりなので、気が向いたら2018年版もやるかもしれません。

なお、今回はあくまで私のバッドデザイン事例ストックの中からのノミネートなので、世界全体に無数にあるバッドデザインのほんの一部にすぎません。

私は生活者全員がバッドデザインをフィードバックしていくことで、世の中が少しずつでも暮らしやすくなっていくことを望んでいます。

ユーザーが正しくフィードバックを行える習慣が根付けば、企業が高いお金と長い時間をかけてユーザー調査などする必要がなくなるのです。せっかくのインターネット社会なのですから、どんどん活用していきましょう。

皆さんも普段疑問に思っていたバッドデザインをどんどん発信してみてください。いつかそれが設計者の目に留まり、改善されていくかもしれませんよ。

Amazonプライムフォト(AmazonDrive)で写真を一括削除する時に見る記事

皆さんは写真を撮りますか?一眼ユーザーでもスマホフォトグラファーでも膨大な写真データの置き場所やバックアップ、困りますよね。そんなあなたには断然Amazonプライム・フォトをオススメします。なんたって無圧縮で容量無制限な上にRAWデータまで無制限に保存できて、Amazonプライムの年会費の中に含まれている基本サービスなのですから度肝を抜かれます。無圧縮かつRAWデータOKの時点で対抗馬のGoogleフォトが霞んで見えます。もうFlashAirとか使わなくても良いんだ!やったー!などとつい浮かれてしまいました。

しかしこのAmazonプライムフォト(AmazonDrive)、思わぬ落とし穴があります。スマホアプリの利用開始時に自動保存をさらりと促してくるのですが、ここで十分に注意しないと取り返しのつかない事になってしまうので、私のように1万枚の写真を手動削除して無駄な半日を使う人がこれ以上出ないようにここに警告文と正しい一括削除の手順を置いておきます。もしもう自動保存をオンにしてしまったよーという方もご安心ください。救いはあります。

目次

Amazonプライムフォト(AmazonDrive)のクソ仕様について

まず最初にAmazonプライムフォト(AmazonDrive)の挙動について確認しておきましょう。ぶっちゃけこの章の仕様さえ把握していれば1万枚の画像を手動削除するとかいう地獄をみなくて済みます。

フォルダで分けてもアプリ側では表示が混ざる

AmazonのPrime Photosをダウンロードした方は気付いたと思われますが、このアプリで表示されているのは「AmazonDriveに保存されているすべての写真」になります。AmazonDriveのwebアプリ側ではフォルダ分けができるのですが、アプリ側から見ると全部一緒くたに混ざってしまいます。スマホのバックアップだけをしている方なら気にならないかもしれませんが、私のようにデジタル一眼で撮った写真もバックアップしていると、スマホの写真および画像が一覧に混ざるのは非常に気持ちが悪いです。一眼で撮った写真だけがクラウドサーバを介していつでもスマホでプレビューできるのが最高だったのに・・・。という事でスマホのバックアップはGoogleフォトに移そうと思ってすべての写真を削除した時に悲劇は起こりました。

フォルダを消しても中身の写真は消えない

はい、これです。THE・クソ仕様。webアプリ版の「すべてのファイル」タブからスマホ自動保存をオンにしたとき自動で作られる「Pictures」フォルダを選択して削除してみましょう。一見消えたように見えますが、スマホアプリから見ると中身の写真がすべて消えずに残っています。どういうことかな?と思って再びwebアプリ版の「写真&ビデオ」のタブに移動してみました。すると写真データは全て残っていて、ダウンロードも可能ではないですか。つまりフォルダの削除操作で消えるのはフォルダの外側だけで中身は何故か全て取り残されます。普段WindowsやMacなどのOSに慣れた身からするとフォルダを削除するとその中身が消えることを期待するのは当然なので、これでは期待する挙動と違いすぎてトラップ以外の何物でもありません。ちなみにこの件についてカスタマーサポートに問い合わせたところ「フォルダのみが消えてしまうのは仕様」だそうです。なんじゃその仕様。

ファイルの全件一括削除はできない

はい、さらにクソにクソを重ねてくるスタイル。容量無制限だぜー!やったー!などと言って何万枚も写真をアップロードしているとあとで地獄を見ることになります。先ほどの操作でフォルダを削除しても意味がないと気付いたあなたは一度リセットして再度アップロードをやり直すため「写真&ビデオ」タブからファイルの全件削除を目論むでしょう。しかしそのような操作は現時点(2017年4月時点)ではサポートされていません。

f:id:information_architecture:20170418000503j:plain

唯一認められている一括操作は「すべてのファイル」タブから画像で示した部分をクリックして、ファイルを1,000件まで同時に選択しての一括操作です。なんだ、一括削除できるじゃないか。と思ったあなた、まさかゴミ箱に入れたフォルダを完全に削除してませんよね?まだ削除していない方はセーフです。次の章でスパッと解決します。もし消してしまったあなたは、残念ながら地獄確定です・・・

フォルダを消してしまった場合の対処法

ここからは実用的なTIPSです。うっかりスマホアプリで自動保存をオンにしてしまって、スマホからの写真を全部消したいと思ってwebアプリから「Pictures」フォルダをゴミ箱にぶち込んだ時点でこの記事にたどり着けていたのであれば、まだ間に合います。よかったですね。

f:id:information_architecture:20170418000732j:plain

この場合にやることは単純明解です。「すべてのファイル」タブ内メニューから「ゴミ箱」を選択し、先ほどぶち込んだフォルダを選択してから下部より「復元する」をクリックしてください。これで「すべて」メニューに先ほど消したフォルダが内包されたファイルとの親子関係を保ったまま復活します。あとは「Pictures > 端末の名前のフォルダ」と掘り進んで行き、最下層になった段階で1,000件ずつ一括選択して一括削除して行ってください。そして中身の写真を全部削除したあとに、親フォルダを削除します。これでAmazonDrive上からスマホの写真を確実に削除することができます。

ちなみにフォルダの中身のファイルを全て削除した後、そのフォルダを消してから復元しても中身のファイルは復元されません。あくまでフォルダはフォルダとして独立して削除や復元操作が行われます。

フォルダを消してからゴミ箱で完全に削除してしまった場合の対処法

おめでとうございます。私と同じ状況です。フォルダを削除したあと「ゴミ箱」メニューで完全に削除をしてしまった場合、そのフォルダに内包されたファイルを一括操作する機会を永久に失うことになります。なんという即死トラップ。どうしようもないです。仕様ですから。

ちなみにカスタマーサポートに「構わないからアカウントに紐づく全ファイルを消してしまってくれ」とお願いしてみましたが、セキュリティ上の理由で無理と断られました。無駄にしっかりしやがって・・・

1,000枚やそこらならまだしも、私のように1万枚以上も同期してしまった後ですと1万連続クリックという高橋名人もびっくりの指先トレーニングをする羽目になります。

諦めて名人になれというのも酷なので、1万クリックトレーニングを微妙に効率化するTIPSを伝授します。

f:id:information_architecture:20170418001227j:plain

まずAmazonPrimePhotosのスマホアプリ(確認したのはiPhone版のみ)を立ち上げます。次に左上のチェックマークアイコンをクリックします。これで複数選択ができるようになるのですが、この時日付単位でまとめて選択できるようになっていますので、あとはひたすら日付をタップしまくるだけです。私の場合1万枚を3年とちょっとで撮っていたようですので、タップ回数は最大でも1,000回くらいまで圧縮されました。やったね・・・

なお、この技が使えるのはPrimePhotosのアプリだけですので、AmazonDriveのスマホアプリでは出来ないです。ご注意ください。

正しい一括削除の方法をおさらい

これ以上野生の高橋名人が増えてしまわないように、AmazonDriveにおける正しいファイルの一括削除方法をあらためておさらいしておきましょう。

1、「すべてのファイル」タブを開く

2、フォルダを最下層まで掘り進む

3、画像で示した部分で1,000件ずつ選択して削除

流石にクソ仕様すぎるので、全ファイル一括削除かフォルダに内包されたファイルの削除のどちらかが今後実装されると思います。それまではうっかりいつもの癖でフォルダを削除してしまわないように十分注意しましょう。

というかせっかく無圧縮+RAWの無制限保存可能というデジタル一眼ユーザーのための夢のストレージなのに、何でスマホで保存したただの画像やスクショなんかと混ぜて表示するような設計にしたんだろう・・・普通に考えて一眼の写真とスマホの画像を同じ画面で見たいと思う人居ないと思うんだけどなぁ。

もっと効率よくファイルをまとめて削除する方法があれば誰か教えてください。

日本製UIデザインツール「STUDIO」は従来のツールと何が違うのか

先日、私の古巣である株式会社オハコからスピンオフしたオハコプロダクツ社から、UIデザインツール「 STUDIO」のクローズドβ版がリリースされました。

国産のUIデザインツールといえばグッドパッチ社が提供するProttなどが有名ですが、β版を触ってみた感想と合わせて STUDIOの何がすごいのか?従来のUIデザインツールとは何が違うのか?ということを紹介してみたいと思います。

目次

これはプロトタイピングツールではない

まず、最初にSTUDIOを「UIプロトタイピングツール」ではなく「UIデザインツール」と記載したのには訳があります。近年はプロトタイピングの重要性が多方面で説かれているのに呼応するように、冒頭で紹介したProttをはじめ国内外からたくさんのプロトタイピングツールが登場しました。何の事前情報もなしにSTUDIOを開いてみると、確かにそれらのプロトタイピングツールの派生系に見えるでしょう。しかし、すこし触ってみるとこれが従来のプロトタイピングツールと設計思想からして全く異なるということがすぐに体感できます。実際にSTUDIOのUIに触らないで理解するのはなかなか難しいのですが、できる限りどういうことか説明してみます。

まず、アプリやWebサービスにおけるUIデザインは大まかに分けて4つのステップに分かれています。

  1. ワイヤーフレーム
  2. プロトタイピング
  3. グラフィックデザイン
  4. プログラミング

このうちプロトタイピングとグラフィックデザインは順序が前後する可能性もありますが、主だったポイントはこんなかんじではないでしょうか。これまで世の中に登場してきた代表的なツールに当てはめると、Prottはワイヤーフレームとプロタイピング。Sketchはグラフィックデザインの領域を得意としており、互いのツールを連携することで優れたUIをデザインすることを補助しています。

ではSTUDIOはこれらのステップのうちどこを得意としているかというと、私が触った印象としては1〜4の全ての工程をSTUDIOひとつで完結させようとしていると感じました。馬鹿げていると思いますか?しかしこれが事実であることは、STUDIOのサービスコンセプトが物語っています。STUDIOが目指している世界は「コードを書かずにサービスが作れる世界」すなわち、GUIでプログラミングまで含めたアプリ制作が完結する世界なのです。

これに気付いたとき、ワクワクせずにはいられませんでした。かつてGUIによってOS操作を実現したように、画面上でグラフィカルかつ直感的に要素を配置するだけでアプリやサービスが出来上がる世界がもうすぐそこまで来ているのだと。

具体的にどのような部分でそれを感じるかというと、まずXcode(アップル公式の統合開発環境)ではおなじみAuto Layoutが、しれっとGUIで実装可能になっています。この時点で結構な驚きです。まだβ版なのにAuto Layoutを優先して実装してくる時点でSTUDIOがXcodeに頼らず開発する未来を目指していることがよく分かります。

f:id:information_architecture:20170323175646g:plain

そのほかにも、Sketch等グラフィックデザイン支援ツールではお馴染みのレイヤー表示順の概念とグループ化がSTUDIOでは(おそらく)意図的に実装されていません。これは、最終的にアプリとして出力(β版では出力機能はありませんが)される際にデータ構造を正常に保つためだと思われます。ちなみに、わざわざ自分でグループ化やレイヤー順変更しようと思わなくても見た目上でブロックの中に配置されたオブジェクトは自動的に正しい順序が保たれた入れ子のツリーのような状態になるため、コンポーネントの区切りを意識することなく想像以上に快適に操作することが可能になっています。

なにより決定的なのが、要素に対してGUI上でAPI接続させる機能が標準で備わっていることです。ここまでで紹介した特徴だけではちょっと変わったプロトタイピングツールという認識になってしまいますが、β版の時点でAPI接続までサポートしようとしている時点でSTUDIOが本気でアプリ制作の全工程をカバーする気だということがひしひしと伝わって来ます。とりあえず、サンプルでspotifyのAPIを叩いてビートルズの名盤のジャケット写真を表示してみました。すげえ。

f:id:information_architecture:20170323180207j:plain

f:id:information_architecture:20170323180222j:plain

ここまでの紹介を読んで皆さんに誤解して頂きたくないのは、コードを書かなくてもサービスが作れる=エンジニアが不要になるということではないということです。プログラミングはデザインと同じく非常にクリエイティブな作業であり、ツールがあるからといってエンジニアの思考無しには成り立ちません。あくまでコードベースではなくGUIベースで組めるようになる点が革命的ということです。

コードベースでなくなることの何が良いかというと、ビジネスメンバーやデザインメンバーがエンジニアと同じ目線でサービスを作ることができるということでしょう。ビジネスメンバーやデザインメンバーはエンジニアの書いたコードを理解することができませんので、デザイナーが形にしないといけないわけなのですが、デザイナーもエンジニアの実現したいことが100%理解できるかというと、そううまく行くことばかりではないと思います。

つまり、エンジニアが素晴らしいアイデアを持っていたとしても誰にでも理解できる形にする手段が無いため誰にも理解されないまま埋もれてしまっているのです。その点において、GUIで機能と見た目を同時に作れることは非常に有効であると言えるでしょう。従来のプロトタイピングツールは、サービスづくりの「デザイン」の領域についてビジネスチームやエンジニアチームを巻き込んだ開発を可能にしてきました。STUDIOは、それらの特徴に加えて世界で初めてサービスづくりの「プログラミング」の領域についてエンジニア以外のメンバーを巻きもうとしているのかもしれませんね。

特筆すべきはシームレスな操作感

ここまでSTUDIOのコンセプチュアルな部分を紹介してきましたが、ここからはSTUDIOのUI/UXにフォーカスして紹介していきたいと思います。STUDIOを開発するオハコプロダクツ社はUI/UXデザイン会社であるオハコからスピンオフしたということもあって、こちらのプロダクトもインターフェース、特にインタラクションの部分について非常に細部までこだわって使用感が作り込まれています。

まず最初に気付くのは、ブロックを配置しようとしたときの挙動の面白さでしょう。こればかりは文章で説明するのが難しいので、STUDIOの公式サイトの「やってみよう」から体験して頂きたいです。左右上下辺からの距離によって要素の座標と大きさを決定するこのUIはプレスリリースによると特許出願中のようで、これまでのどのツールにも無かった独自の操作感を提供しています。実際に触ってみると非常に直感的かつスピーディに要素の配置をすることが出来ることに驚きます。これからドラッグ&ドロップで要素を配置する系のツールのデファクトスタンダードUIになりそうな予感がしますね。

f:id:information_architecture:20170323175736g:plain

β版ではまだLPで紹介されているスマートフォン同期プレビューは実装されていませんでしたが、それでも通常プレビューのシームレスさには驚きます。画像の再読み込みなどが極力走らないように工夫されているのか、一切の途切れなくまさにシームレスにプレビュー状態に移行します。画面遷移を行なっても画像の読み込みはほとんど感じられません。というより通常編集モードですでにプレビューと同等の操作(横スクロールなど)ができるので、プレビューの概念が揺らぎます。

他にも、要素をグリグリ動かすとalignがよしなに調整されてくれたり、画面上で順序を入れ替えるとレイヤー(ツリー)側の順序も入れ替わったり、色んな操作がシームレスに繋がっている感覚が新鮮でした。操作しているというよりもデュエットしているような感覚に陥ります。なんだその恥ずかしい表現。

これだけ色々なことができるツールでありながら、テキストによる説明一切なしで直感的に使えるのはすごいと思いました。ユーザーに学習させてから使わせるのではなく、触りながら学習するというのはUIにおける理想の状態だと思っているので、もっとこういう説明に頼らないUIが増えると良いなぁと思ったのでした。各UIの操作感については、β版を終えて改善が進んだ製品版の方が出た段階で改めてレビューさせていただこうと思ってます。

全員がMVPまで作れる時代

STUDIOがプロトタイピングツールではないことと、誰でも直感的に扱えるツールであることを紹介してきましたが、ではSTUDIOによってアウトプットされるものは一体何なのか?というと、MVP(Minimum Viable Product)であると考えられます。MVPについて改めて説明はしませんが、ここではプロトタイプとMVPとの明確な違いは何かということについて考えてみたいと思います。

MVPもプロトタイプも本開発に入る前のテスト段階でユーザー検証のために用意するもの、という漠然とした認識だと思うのですが、私はこの2つで明確に違う点があると考えています。それは、MVPは「最小限の価値」を確認するための試作品であり、プロトタイプは最終形も含む「状態」を確認するための試作品であるという点です。MVPは最小限という制約があるため、作り込むことに重点を置いていません。一方、プロトタイプは複雑に入り組んだサービスの後期段階でも用いられることから分かるように、最小限にすることに重点を置いていません。両者は包括関係にあるといっても良いでしょう。というより、Prott等のトランジション再現型のプロトタイピングツールもプロトタイプという大きな枠の中のごく一部分(画面遷移)しか試作できないため、厳密にはプロトタイピングツールと呼ぶのは相応しくないのかもしれませんね。MVPにはプロダクトと名がつくくらいなので、基本的な画面遷移に加えて最小限の価値を得られる「機能」が必要であり、機能が入って初めてユーザーは画面から「価値」を体験することができます。『ここで音が出ます』とか書いてあっても、それは本来のユーザー体験ではないですよね?音が出ると決めたらちゃんと音を出すことが、MVPにおいては重要になってくるのです。そして、MVPを作ることはサービスのスタート地点に立つことと同義です。こう考えると、STUDIOは最速でサービス開発のスタートを切らせてくれるツールと言えるかもしれませんね。STUDIOによって、非エンジニアも含めてメンバー全員がMVPまでは爆速で作り上げられる世界が作られることを期待しています。

まとめ

以上、一通りβ版STUDIOを触り倒してみて感じた率直な感想ですが、画面遷移の整合性チェックなどを素早くチェックするのが目的なら私はProttを使うなという印象でした。なんと華麗な手の平返し!やはりプロトタイピングという目的に特化したツールにはそれなりに工夫が詰まっており、使いやすいです。また、ビジュアルデザインについてもSketchの方がやはり出来ることが多く使いやすいと感じます。しかし、これらのツールはUIデザインの特定ステップに限定した場合に使いやすいのが特徴であるため、最終的なMVPの出力まで一気にやるようなケースではSTUDIOで作った方が総合的には早く形になるのだろうなということを強く感じました。STUDIOはまだβ版なのでこれから改善を繰り返していく段階であり、これからの動向が非常に楽しみなツールだと思います。

ところでわざわざこんな長文レビューを書いている理由ですが、古巣のプロダクトということは実は全く関係なく「コードを書かずにサービスが作れる世界」というコンセプトに純粋に惚れ込んでいるためです。私自身が何度かプログラミングに挑戦しようとして言語を覚える段階で挫折を繰り返している身なので、GUIベースのアプリ統合開発環境を切望しているのです。

もしこの記事を読んでSTUDIOにすこしでも興味を持っていただけたのであれば、一度触ってみてください。触ればこのコンセプトとすごさが実感できます!そして、思ったことは良いことも悪いこともバシバシフィードバックしてあげてください!ユーザーとして一緒に作りましょう、コードが必要でなくなる世界を。