カテゴリー: 未分類

目の見えないユーザはiPhoneをどう操作するか

本日、アクセシビリティの専門家である中根雅文さんに会ってきた!

中根さん自身も全盲であり、目の見えないユーザがどのようにiPhoneを使うか、アクセシビリティとはなんぞやなど、いろいろと教えてもらったので、それについて書いてみる。

と、本題に入る前に、まず、ここまでのいきさつを書いてみる。なんで、お前いきなりアクセシビリティの話するのよ?という疑問もあるだろう。

僕はLisgoという読み上げアプリをリリースしたおかげで、視覚障害者の方から使っているよというお褒めの声が届いた事があるのです。

その時は「アプリ作っててよかったな」と開発者冥利につきて幸せ気分だったわけだが、もともと自分が移動中にWeb記事を聞きたくて作ったアプリ。特に視覚障害者向けにカスタマイズとかはしてなかったのですね。

まあ、当初からそういうニーズがあるだろうと、ある程度は予測していた。しかし、ターゲットを絞るのが重要だという思いから、まずは自分専用、もしくは自分みたいな用途のユーザ向けに絞って開発をしていた。

そんな時、去年の夏頃だっただろうか、Instapaper作者のMarcoさんのPodcast、Build&Analyzeで、ひょんなことからVoiceOver対応の話が出てきたんです。

実演しながら、「VoiceOver対応するのは簡単だから、iPhone作っているなら対応しといて損はないぞ」という話だった。

いてもたっても言われなかった僕はすぐにPhoneのVoiceOver設定をONにしてみてました。

「なんだこれは!どうやって戻すんだ!おい!」と思いながら、こんな機能あったんだなと初めて知りました。

※試したい人は、設定➡一般➡アクセシビリティ➡一番下までスクロールしてホームをトリプルクリックをVoiceOverに。アクセシビリティ項目の一番上のVoiceOverをオンにすると、元に戻しにくくなって混乱するのでトリプルでやるように!

実は、iOSのコーディングも一行。UIButtonとかBarButtonのプロパティに付け足すだけ。

helpButton.accessibilityLabel = @"ヘルプボタン"

いやあ、アップルってこういうところ凄いなと思いながら、カスタムしたボタンとかをVoiceOver対応しておいた。ちなみに、デフォのUIボタン使っていたら大抵は自動で対応されるから、デフォルトのシンプルなアプリがVoiceOverには使いやすい事が多いらしい。

それからしばらく立ったある日の事、アクセシビリティ・ビギナーズを石橋さんにTwitter上で「You、君のアプリに関係あるYO!」と薦められ、先日ほいほい行ってきた。

そしたら、もう、全然知らない事がたくさん知れて、もの凄くよかったですね。

最近、まだ知らないと自分が分っている事を知るより、自分が知らないと分らなかった事を発見するのを意識したいと考えていたのだが、まさに後者がいっぱいありました。

目が見えなくてもVoiceOver使ってPerlのプログラミングするとか、慣れると音声読み上げを爆速で使うとか、驚きの連続であった。

他にも、中根さんに、「PocketもDropboxも使っているよ、あれ凄くいいね!」とか言われた。自分のアプリはGoogleReaderに対応したら使いやすいかなと思っていたけど、まさかPocketを既に使っているとは。

アクセシビリティとはなんぞや

勉強会では、Webアクセシビリティ専門家である植木真さんも語ってくれてたけど、アクセシビリティって視覚障害者だけのものじゃなくて、あらゆる人に言える概念なんですね。

いろいろな状況でも製品が使いやすく、アクセスしやすくする。

htmlを正しく書いて機械がアクセスしやすくするとか、様々な用途で使う人間がいろいろな条件でアクセスしやすくするとか。

そういう意味で考えると、僕がiPhoneで読み上げアプリを作り始めたのも、読書のアクセシビリティを高めたいからだった。

他にも、海外の映画に字幕がついて理解しやすくなったり、英文読む時に辞書調べるのがめんどいからタップだけで辞書が出るとか、アクセシビリティを高めるのにITは大きな力を発揮している。

ITっていろいろ負の側面もあるかもしれないけど、素晴らしいな。人間が出来る事の可能性を拡張してくれる。

余談だけど、自分の専門から離れたイベントとかをたまに行くと、思っても見なかった発見とかをする。これから意識的にそういうランダム性を作ろうと思う。

これは、今読んでいるタレブのAntifragileって本の影響で、昔から影響を受けやすいので、最近そんな事ばっかりしったかしているわけなんだけど、その話はまた今度ブログで書きたい。

ちなみに、VoiceOver機能自体あまり知らない人が多いと思うので、iPhoneのTwitterアプリを操作している解説動画を撮影させてもらいました。


*家計簿読み上げのアプリ作ってます。自己紹介と過去ログはこちら

アップストアの審査リスクを最小化する

ここ2,3ヶ月、精魂込めて開発していた“通勤中に聞ける太宰治”がアップストアでリジェクトされた。泣ける。

原因は「ブックアプリだからiBookStoreで出してね!」だった。。

もちろん、「いやいや、これは読み上げ機能とかあって、聞く事と読む事を繋げるアプリで、iBookStoreじゃできない」とか、いろいろごねて何回かアピールしたけど、無理だった。最後には、「そんなに言うならアピールボードがあるよ」と言われたけど、なかなか厳しそう。

アプリのコード自体は、次のDropboxのテキストファイル連携する本命アプリに流用するので無駄にはならないけど、それでも、結構な時間を太宰アプリのリリースに費やしたのでつらい。

アイコンだけは手を抜けないと思って、太宰のイラストとかもイラストレーターの方から購入して作成したし。アプリに入れる太宰作品の紹介文とかも書いたし。

調べてみると、最近は書籍アプリは基本的にリジェクトされる運命にあるらしい。ついつい、アップストアに並んでいる類似アプリを眺めながら、大丈夫だろうと思い込んでしまっていた。まあ、確かに書籍関連はそうなるのもしょうがないか。

そもそも、アップストアのガイドラインなんて刻々と変わるもんだし、アップストアで並んでいる類似アプリがあったからといってOKとは限らない。数日前に承認された類似アプリと同じような内容でもリジェクトされるリスクもある。

僕は反省しました。

もっと早くサブミットして、アプリがリジェクト対象になるかどうか確認しておけばよかった。

Webサービスを作る上での最大のリスクは、ユーザが欲しがらないものを作る事なので、最低限の機能でリリースするのは重要なんだけど、iOSアプリに関して言えば、なによりも、ストアリジェクトが最大のリスクなのに。。

可能な限り最低限の機能だけに絞って、できるだけ早くリリースすることを教訓としていたのに。今思えば、もっと省略できた。

フォントサイズ変更、ナイトモード、ランドスケープロック、カスタムUI、文字検索も、あれもこれも省略できた。「この機能やこの機能は必須だな!」と思い、サブミットするのを遅らせてしまっていた。

全部すっとばして、とりあえずサブミットしていたら、一ヶ月以上は早くリジェクトリスクを確認できた。

ちなみに、アプリ開発者なら大抵知っているけど、ストアにサブミットして承認される=ストアでリリースされるではないのです。

例えば、5月10日にストアにサブミットして、5月17日に承認されたとしても、iTunesConnectのアプリのAvailable時期を一年後とかに最初から設定しておけば、ストアにリリースされる事はない。

もちろん、承認されれば、いつでもリリースできるようになる。だいたい数時間以内に反映される。さらに、アップストアに承認された時点で、TestFlightのような面倒なサービス使わずとも、プロモコード配布でβテスターにカンタンにアプリも試してもらう事ができる。

これは、アップストアのリリース時期は一年後にしてても、承認さえされればプロモコード経由でストアからダウンロードできるから。

ああ、なんてバカだったのだろうか。

これからは、もっともっと、「この機能は後回しにできるんじゃないか」と自問自答して、いかにやらないかを考え、まずはリジェクトリスクを確認する。ついでにリリースを早める事を徹底したい。

リリースする事で、いろんな事が分るし、使ってもらえる人の反応もわかるし。最初から大々的に宣伝して初動で回収するアプリを作ってるわけでもないし、最初は評価低くなっても、こつこつよくする予定だったらそこまで関係ないし。

とにかく、これからはもっと早くサブミットするよう気をつけよう。だって、アップストアって、すごい些細なメタデータ入力不足とかでリジェクトされて、速攻で修正してサブミットしても、平気で数日返事待たされたりするからなあ。

ちなみに、太宰アプリのティザーサイトに登録してくれた方は、次のアプリ「読み上げさん(仮)」が出た時お知らせしようと思います。これも、もうサブミットしたけど、今審査中。


*家計簿読み上げのアプリ作ってます。自己紹介と過去ログはこちら

サービスにハマる過程とは

最近、以前は理解できなかった利便性に、どういう風に自分は気づき始めるかというのを凄く考えている。

もう、本当にこれは、切実に考えている。

なんでかというと、LisgoやVoicepaperで広めようとしている、”目で読んでいる読書の続きを、立ち上がった後に耳で聞く”という新しい読書体験が、とても理解されにくいからです。

一度理解してもらうと凄く刺さるし、この体験は読書好きじゃない人でも読書に親しむようになるぐらい大きな事だと思っているけど、そこまで理解してもらうのはとても難しい。

でも、これは、至極当たり前のことで、自分もいろいろなことにおいて、あるサービスや、製品の機能について、最初はさっぱり理解できなかったことが、それはもう、本当にたくさん、しょっちゅうあることに気づいた。

自分に最近起こった変化、さらには、自分がサービスを広める側なら、どうやってその変化まで持って行けばいいかを書いてみたい。

最初、理解できなかったもの

最近の例でいうと、iOSのフリック入力。

僕はキーボードでの入力に慣れ切っていたので、iPhoneを始めて買った数年前、携帯で文字を打つのを頑なに拒否してた。

いやいや、キーボードで打つほうが遥かに早いし、打ちやすい。こんな小さい画面でチマチマ打つなんて非効率すぎるわ。その時間は違うことしたほうが有益だな。とか思ってた。

でも、フリック入力に慣れてくると、キーボードほど速くも正確でもないけと、モバイルで文字を打てるメリットがありありと理解できてきた。

それは、もう、薄々理解してたつもりだったけれども、実際に習慣になるまで、本当の意味でしっくりきてなかったアハ体験。

外でもいろんな状況で打てるし、寝転びながらでもブログが書ける。なんで、長文書く時は、絶対キーボードじゃないと嫌だと、あそこまで、頑なに拒んでいたのでありましょうか。

もうひとつは、マニアックな開発ネタで申し訳ないのだど、CocoapodsというiOS開発のリーサルウエポン的なシステム。

これは、いろんなオープンソースライブラリを超絶簡単に入れたり出したりできる神ツールなんだけど、使い始めるまで設定とかめんどくさいし、今までのやり方で別に不満ないからなーと思ってた。

この、今までのやり方で満足してるからなーというのが結構重要なポイントだと思う。

やはり、別に満足してるもののを、面倒なコストかけて新しいことを覚えるのは疲れる。だから、はっきりとしたメリットを自分がイメージできないと、人間なかなか以前の習慣から移ることができない。

しかし、恐ろしい事に、一度使い始めて、最初は、「まあ、便利だけど、別に以前のやり方でもいいかな」とも思ってた。

そんな自分が、cocoaPodsをしばらく使っていると、「あれ、これないと俺もう死んじゃうぐらい便利だわ、これなしではオープンソースの管理めんどすぎ。もう戻れない。」とまでなってきた。

新しいサービスを提供する側になった時は、どうやって、この状態まで持っていくか、出来る事はなにかを考えてみたい。

利便性に気付くプロセス

自分が新しいものの利便性に気付くまでは、いくつかのプロセスを辿っていると思う。

まず、誰かがそれについて薦めてくる。気付く。気になる。使い始める。まだよくわからない。でも、とりあえず続ける。慣れて来て、利便性にはっきり気付き始める。習慣になる。

例えば、フリック入力なら、だいぶ前にどこかのブログでフリック入力が絶賛されていて、出来るだけ使うように努力し始めた。とりあえず、使い続けてたら、慣れて来た。だんだんとツイッターとか、長文のブログでも使い始めた。

CocoaPodsなら、iOSTokyoMeetupで絶賛されてたから、これは時代に乗り遅れそうだぞと思い使い始めた。で、あまりよさが理解できないまま使い続けてたら、離れられなくなった。

さて、サービスを提供したい側なら、どうやってこのプロセスを促進できるんだろうといつも悩んでいる。

まず、サービス自体に価値があって素晴らしいものだという前提で話を進めてみる。

どう持っていくか

もっとも重要なのは2つの部分だと思う。

1つ目は導入がいかにカンタンか、2つ目は、まだよくわからないけど、とりあえず使い続けてもらうこと。

1つ目はとても、とても難しい。特に、なかなか利便性が理解されないようなサービスであるほど難しい。

ParseとかCrashlyticsのようなサービスは、導入でいかにつまづかないか、本当に細かいところまで気を配って手順が設計されていると思う。

モバイルアプリなら、開いた後に、いかに離脱せずに、らくらく前に進めてもらえるか。

2つ目の、とりあえず続けてもらうという部分も結構難しい。

一度使ってみて、ああ、これいいなと思っても、しばらく使ってなかったら忘れられるというのがよくある。

これに対処するには、Webサービスだと、メールアドレスを登録してもらえるようなインセンティブを作って、忘れないように定期的にお知らせを送るのがよくある。

スパムにならないように、ユーザが開きたくなるようなものがいい。

モバイルアプリだと、定番なのが、Push通知。家計簿アプリのZaimはしばらく使ってないと、「お金の入力最近してませんよ」というような通知がいくらしい。これはユーザも納得の通知だし、上手いなと思う。

他に思いつくのは、ゲーミフィケーションで、利便性がまだよくわからない段階でも、なんか気持ちいいから続ける仕掛けを作るとか。

気持ちいいからなんとなく続けるという意味では、効果音とか、アニメーション自体が気持ちいいというのもある。

とにかく、考えだしたら本当に細かい部分までいろいろある。

ちなみに、まずは、誰か製品を欲しがる人がいるかどうか、これを確認できた後に優先度を上げる項目なので、どのタイミングでこれらの事柄に力をいれるかも難しい。


*家計簿読み上げのアプリ作ってます。自己紹介と過去ログはこちら

一番リスクの高い部分から始める

僕は、新しいアプリを作る時は、一番リスクの高い部分をまず考えるようにしてます。

これは、一番不確実な部分をまず確かめるという意味です。

でも、一番リスクの高い部分を確認するための方法は、一番簡単に、速くわかる方法を探すようにしている。

アプリやサービスのアイデアでも、プログラミングでも、全部そういうふうに考えるようにしている。

Continue reading


*家計簿読み上げのアプリ作ってます。自己紹介と過去ログはこちら

iPhoneの月額課金はツール系で使えるか

※追記 2013/06/15

これはだいぶ前の記事だけど、結局、Auto-Renewing Subscriptionsは今まで通りの気配。。最近、アップルの課金関係のエバンジェリストにメールで聞いたら、「最終的に決めるのはReveiw Teamだからわからないけど、基本的に機能にたいしてはAuto-Renewableは使えないよ。」みたいな返信をもらった。残念すぎる。

どこまでが機能で、どこまでがMediaと認識されるかという線引きはよくわからないけど、特に今までとルール適用の方針は変わらないのだろうか。

 

 —— ここから以前の記事

知り合いに教えてもらったんだけど、ちょっと前にApp Store Review Guidelinesが変更されてたみたい。これ読む限りでは新聞とか雑誌系のアプリ以外でも自動継続課金(auto-renewable subscriptions)が使えるようになったのかも。まだわからないけど、これは期待!

Continue reading


*家計簿読み上げのアプリ作ってます。自己紹介と過去ログはこちら

未来を待てないからプログラミングする

最近プログラミングを初めて楽しそうな友達とお茶漬け専門店でメシ食いながら、「本当はコードなんて書かずにモノが出来上がるぐらい簡単になればいいのに」という話をした。

一緒にお茶漬け食いにいったJ君は最近iPhone開発を始め、自分が旅行中に必要だったニーズを満たすものを実際に作って嬉しそうだったのですが、iPhone開発する時の不便さに怒り心頭らしい。

僕は、「プログラミングって奥が深くて、綺麗な設計ができるようになるたび楽しいなあ」とか、「プログラミング始めたのは人生で最良の決断だったなあ」とかいきって真夜中にTwitterで呟いたりしちゃうんですが、確かにもっと簡単になればいいとは思う。

プログラミングの面倒さに怒り浸透のJ君

まあ、NavigationControllerとかいろいろと細かいプログラミング用語をここで羅列してもなんのこっちゃわからなくなるので、簡単にまとめると、「なんでこんなカンタンな事が、カンタンに実装できないの!」という愚痴を延々と僕に浴びせかけていた。

J君「もっと直感的に、画面上で操作できるようになってほしいんだよ!」

俺 「まあ、一応、iPhone開発もストーリーボードとか最近は出来て、楽になったよ。」

J君「ストーリーボードは結局細かい事ができないからコードで書かないといけないじゃないか!」

俺 「まあまあ、エクセルのショートカットみたいなもんだよ。なれるとコマンドのほうが便利になるのは万有引力の法則と同じぐらい自明なんだよ。」

J君「その最終的にはコマンドで打つのが楽というのがおかしい。結局、作業なんだから、簡単にわかりやすくできるようにならないと。。」

まあ、数年前に比べてARCとかできてiPhone開発はだいぶ楽になったから、やろうぜ、楽しいよと周りに言いまくっている自分ですが、実のところ、結局プログラミングは面倒な事のオンパレードです。

本来ならば、こういうものを作りたい、こういう順番でUIを見せて、こういうデザインで、こういうわかりやすくする心理的しかけがあってと言ったような人間様がやるべき仕事に集中したいんですよね。

最近は、「デザイナーもプログラミング覚えるべきだ」とか、「テクノロジ系スタートアップのファウンダはコードが書けないといけない」とか、なににつけてもプログラミング重要といった風潮です。

僕も、プログラミングできるとUIデザインに凄く役立つよみたいな記事を最近書いたばかりだ。

※デザイナーはプログラミングも覚えないといけない時代なのか

人間、なにか新しいことをちょっとかじったら、これは○○にも役立つとか、○○できないやつはダメ!とか言いたくなっちゃうんですよね。

たぶん、僕が統計学を本気で勉強したら、統計学は最強の学問だとか言うと思うし、歴史学だったら、歴史に学べないやつはクズだとか言いそう。

最近、なんかみんなコードを習うべきだみたいなカッコいい動画も海外で作られてもいたし。

これに対してJ君いわく、いやまてよと。現状でそうなるのはしょうがないし、プログラミング行為自体の楽しさは認めるけれど、進むべき方向としては、プログラミングなんて不要になるぐらいカンタンにモノが作れる世界だろと。

確かに、僕もプログラミングがもっと簡単になって、全部直感的な操作で自分が欲しいものを作れる世の中になったらいいなあとよく思う。

今でも、子供でも簡単にプログラミングが出来るようなものが出来つつあるけど、まだまだ教育用の枠組みだ。

理想を言えば、GUI操作さえもいらなくなって、「こんな感じに操作できて、データはこう記録されて、画面のアニメーションはしゅっとこんな感じ!」といったように、長嶋監督もびっくりの身振り手振りでコンピュータに要求すれば、「こんな感じでしょうか?」と提案された実装がすぐに出来上がるのがいいな。

こういう未来の話をしても、現実世界ではテクノロジーが追いついてないんだからしょうがないんだけど、こういう視点を忘れないようにするのは意味があるとは思うんですよ。

つまり、なにかを実現したくて、それにむかっていろいろな作業に没頭していると、本来の作業自体の効率化に目が行ってしまうというか。

僕は見た目が綺麗で分りやすいコードの書き方とか、綺麗な設計とか、メソッド名は何がいいかとか、プログラミングの奥の深さが好きなんですが。

ちなみに、文系人間だからプログラミングなんて無理無理と思っていて僕に、「プログラミングは手に職つくし、論理的思考が高まると思うからお勧めだ。それになんか楽しそうじゃん。」と数年前にプログラミングを勉強するよう薦めて来たのもJ君であったりする(笑)

未来を待ってられないから手を動かす

ただ、現実にはコードを書かずにモノが簡単にできるほどテクノロジーは進化してないんですよね。

簡単になるまで待つという選択肢もあるけれど、それが待てないなら、実際に手を動かして作るか、作ってくれる人を探すしかない。

今、このブログもキーボードで打っているけど、出来れば自分の思った事をそのまま入力してくれる技術ができればいいとは思う。

でも、そういう未来は待ってられないし、とりあえずキーボード打つのはそれほど難しい事じゃないから、ぺちぺちとマックでブログを書いている。

プログラミングに関しても、すげえ適当に書いても勝手に綺麗に整理してくれたり、マシンパワーで非効率な設計も補えるようになるかもしれない。

でも、現時点では綺麗な設計で効率的なコードを書くのはもの凄く重要だし、このことはそんな簡単に変わらないと思う。

もちろん、数十年後にプログラマーという職業の需要が今程あるかどうかは定かではなくて、その時々に要求されるスキルってそういうもんだし、ずっと続くものなんてないからなあ。

これはスキルだけじゃなくて、サービスの市場もビジネスモデルも、ずっと現状と同じように続くものなんてないし。

現実世界の制約を忘れて未来の事を想像するのが重要だから、SFとか読むのって大事なんでしょうね。

ちなみに、文系の人向けのプログラミング勉強方法を昔書いたので、紹介。

※挫折確率を下げるプログラミングの覚え方


*家計簿読み上げのアプリ作ってます。自己紹介と過去ログはこちら

動かしながらデザインする

UI・UXデザイン方面だと”動く”モックアップが作れると大きいなあと以下の記事を読んで思った。


翻訳:Railsを学んだことで私はより良いデザイナーになった

インターフェイスは、動かない画面に貼り付けられた書類の束では決してなく、それは、インプットとアウトプットのフローなのだ。それが本当によいインターフェイスなのかどうかは、自分で使ってみるまで評価は下せないし、使ってみるにはまず作ってみないといけない。正確な評価・判断をしたかったら、実物に勝るものはない。

それまで私たちデザイナーは、動かないモックアップと、いくつかの動く部品を作って、それからプログラマの助けを呼んでいたが、この時の私達は、およそ2ヶ月もの長い期間を、プログラマの手を煩わせることなく、コンセプトの検証や新しいアイデアを実験するためのプロトタイプフェーズに費やすことができた。プログラミングの基礎知識は、私達デザイナーに dance without a partner のための手段を授けてくれる。

動かないモックアップ、例えば、パワポとかペーパープロトの段階で分ることと、シンプルでも実際に動いて機能するモックアップで分ることってもの凄く情報量が違うからのう。

特にiPhoneやiPadのようなモバイルデバイスだと、情報量の違いが100倍ぐらい大きくなるんじゃないだろうか。いや、100倍は言い過ぎかもしれないから、そこは突っ込まないで頂きたいけど。

動くモックアップでわかる情報量の多さ

僕がCakePHPでWebサービスを作ってた時は、まず紙でさささっとUIやら全体のイメージを書いて、その後はパワポに落とし込み、リンクをクリックしたら次の画面に動くようなモックアップを作っていた。

その後、htmlとcssで画面を作り、あとからバックエンドの動きを実装していた。コードを書く前に”実際に動いているような”デモをパワポで確認できて、今でも有効な手法だと思う。

そんなにこった動きとかはしてなかったし、ちょっとJQueryとか使う程度だったので、「うーん、ここの動きが使ってみると使いにくいなあ。」と言って後戻りするようなことはあまり多くなかった。

ところが、iPhoneとかiPadなどのモバイルデバイス向けに作るアプリになってくると、”動くものを実際に触ってみないとわからない”という部分がめちゃくちゃ多い。

最近はだいぶ過去の経験とか、いろんなUIの動きを脳みそにインストールしてきたおかげで、そこそこ実装前でも先が見えるようになってきたかなと思ったりもするけど、それでも触ってみないとわからないことだらけ。

Webサービスでも最近ではJavaScriptガリガリ使って動きを工夫したりするし、HTML5とかでモバイル対応したりしてきたら、もう大変だと思う。

モバイルアプリは使う事でわかることが特に多い

iPhone開発では、iPhoneシミュレーターというPC上で動きを確認できる便利な機能があるんだけど、最近あまり使わなくなった。Xcodeの実機へのBuildが高速になったというのがでかいけど、実機で触らないとわからないことが多い。

まず、手で握って触った時に、ボタンの位置が押しにくいかとか。

アクションボタンをタップしてにょきっと画面が下から出て来て、それを閉じる時に左上、もしくは右上のボタンを押す時に届きづらいから、たまにiPhone落としちゃうとか。

移動中にポケットからiPhoneを取り出し、ネットワークが不安定になった時にどういう動きをするかとか。

寝る前に寝転んで、画面が横画面になった時に、縦画面の時、どういう握り方で持つか、その時の使いやすさとか。

こういう事を検証するには、デザインは全部デフォルトでいいから動くものをささっと作るのが一番。

僕が新しいアプリのUIを検証する時は、アイデアだしの段階で、まずは紙に簡単に書いて、その後コード書いて動かして検証してます。

Lisgoペーパープロト

自分しか理解できないかもしれないLIsgoのUIを考えてた時のメモ書き。

そこから、もうちょっと突き詰めて、自分を第三者の視点で観察するとか、ユーザを観察するとかの話はこちら。

使いやすいiPhoneのUIを作るために気をつけていること

でも、プログラミング覚えるのは大変でしょう?

これは悩むところです。人間の時間は有限だから、各自で一番最適だと思うことに時間を使うしかない。

これができたらいいよー、これもできたらいいよー、この知識があるとないとでは全然違うよーというのは、どれも正論であることが多いですよね。

でも、自分が今やる価値はあるかとか、これから覚える意味はあるかとか、必要になった時に勉強したほうがいいか、他人に任せて自分が得意な事に集中するかは人それぞれの状況に応じて違ってくる。

結局、”これからは英語勉強するべき”とか、”○○もコードが書けないといけない”とか、そういうのは自分でやりたいと思ったらやればいいし、必要でなければやらなくていいと思うのです。

だから、この記事も、そんなもんかと思って読んでくれたらこれ幸いです。

余談ですが、最近はデザイナの定義が広すぎて、デザイナーですと言ってもどれが専門か聞かないとよくわからない。


*家計簿読み上げのアプリ作ってます。自己紹介と過去ログはこちら

ユーザがそれを選ぶ理由

この前たまたま夜中にプログラミングに疲れ果てて死にそうだったんですよ。そして、ちょっと気晴らしでもするかと思ってネットを徘徊していたところ、ちきりんさんがはてなのオフィスを訪れたという話を読んだ。

はてな訪問 – ちきりんの日記

これがサービス提供者とユーザ視点という観点でみると非常に面白いなあと思いまして、いつものごとくサービス開発にどう生かせばいいかとうんうん考えた事を書いてみたい。

この記事のなにが興味深かったかを説明すると、ちきりんさんがはてなダイアリーを使い続けている最も重要な理由が、”日付が分りやすい”という理由らしい。

これには「そんなことが理由なんですか?」みたいな顔をされましたが、私に言わせると、「それ以外にはてなでブログを書く理由って何があるんですか?」って感じです。

もちろんはてなダイアリーはブログとして最低限の水準をクリアしてたんだろうけど、ちきりんさんにとっては”日付が分りやすい”という部分が何よりも大切で、これが決定的な部分だったらしい。

こういう、サービス提供者側が想像してない理由、使い方などで、ユーザがそのサービスを選んでいるという事は本当によくあることだと思う。

サービス作っている側からすると、”他の競合サービスにはないこの機能でユーザに選ばれてるのだろう”とか、”うちのアプリを使ってもらっている理由はUIデザイン”だろうとか、こう思ってていても、実際のユーザ側としてはまったく違う理由だったりする事がある。

自分がなにかの商品を使い続けている理由も、結構ささいな部分が多かったりするもんな。

もちろん、どのターゲット層に最適化するかでニーズに答えるかどうかは変わってくるから、ちきりんさんがこういっているからそこを重視しろっていう事が言いたいわけではなくて、そういう理由で選ばれているのかと知るだけでもすごく参考になると思う。

ユーザが商品を買う理由

このはてな訪問の記事を読んで、37SignalsのJasonFriedが2012年で一番影響を受けたとTwitterで呟いていた、クリステンセンのビデオを思い出した。

※クリステンセンって誰よ?っていう人に説明すると、イノベーションのジレンマを書いた有名なハーバードの教授で、ジョブズも非常に影響を受けた人

簡単に内容を紹介してみるとこんな感じ。

あるミルクシェイクの会社が商品を良くしようと思って、ユーザーインタビューを実施した。”フレイバーはどれがいいか、チョコレートの配合はどうするといいか”とかいろいろなユーザーフィードバックをもらい、その調査を参考にミルクシェイクの味を改善したらしい。

しかし、まったく売り上げには影響がなかった。

そこで、ミルクシェイクの会社は、実際に商品売り場に調査に行き、お客がどういう時間帯に商品を買っているか、どの時間帯に売れているか、どういう人達が買っているかを一日中調査することにした。

すると、ミルクシェイクの売り上げの半分は午前8時前に売れていた不思議な事実が判明。

ミルクシェイクを購入した人達はみんな一人で、ミルクシェイクだけを購入し、みんなが車に乗っている人達だった。

そこで、その人達に”不思議なのですが、なんでミルクシェイクを選んだんですか”といったような質問をしてみた。

“もしミルクシェイクを買わなければ、どういう理由でなにを選んでいましたか?”といったような質問もすると、それぞれがみんな、退屈な長い通勤時間を我慢しなければならないことがわかった。

片手でハンドルを握り、空いている片手で退屈な通勤時間になにか気晴らしになるものが必要だった。

朝早いからまだお腹は減っていないけど、10時頃にはお腹が減り始めるから、ちょっとだけお腹を満たしてくれるものが最適だった。

お客さんが言うには、”バナナはダメだった。バナナはすぐ食べ終わる。ドーナツも試したけど、ドーナツは手が汚れて運転中には向かない。ベーグルも味がなくて退屈でダメだ。”

“ミルクシェイクはこんな時ぴったりで、手も汚れないし、持ちやすい。空腹も解消される。”

お客がその商品になにを期待しているかを理解できれば、商品を改善するのは非常に楽になる。(終わり)

いやあ、これは言われてみるとそうかそうかと思うんだけど、開発側はついつい近視眼的になってしまうから、常に意識しないと忘れちゃうなあ。

この機能を完成させれば、競合製品と差別化できるからユーザが増えるはずだ!とか思ってても、今のユーザにとってはそれはたいして重要な部分ではなく、もっと違う部分を良くして欲しいと思っているとか。

むしろ、どうでもいい機能が増えたら、それを特に重要視してないユーザにとっては複雑さがまして逆にマイナスになったり。

ユーザのフィードバックをもらう時は、”使い続けている理由で一番重要な部分はなにか”、または、”使うのを止めてしまった理由の決定的な要素はどこか”。とか知りたいんですよね。

UXの専門家とかだったら”当たり前の話だね、うん。”ってなるかもしれないけど、ついついこういう視点を忘れちゃう事って多いからなあ。

こういう事を答えてもらえるようにはどういう聞き方がいいかとか、いろいろと悩ましい。


*家計簿読み上げのアプリ作ってます。自己紹介と過去ログはこちら

Copyright © 2025 うめのんブログ

Theme by Anders NorenUp ↑