小さなことを後回しにするのは意外と難しい
僕はアプリを作っている時、小さなことは後回しにしながら作ることを意識しています。これは、数年前からずっと意識しているけど、常に頭の中で何回も自分に言い聞かせながら作らないと、ついつい忘れてしまう。 いや、忘れている感覚とは違うかもしれない。小さなことなのに、実際にやっている最中には、「これは細かい事だけどとても重要なことなんだ」と勝手に思い込む力が働いてくるんです。これは、人間たるもの、現在やっている作業は大切なんだというバイアスがかかるからだと思う。 でも、しばらく時間がたった後になると、「あれ、なんであんな小さなことにこだわろうとしていたんだろう。。今振り返ると、別にそこまで時間かけなくてもいいや。。」と振り返って思うことが多い。 しかし、これ難しいんですよ。しばらく時間がたって冷静になるとできるんだけど、その時は難しい。 しばらく時間がたつと、その時には考えてなかったいろいろな情報や
アプリのUIテストは専門家と素人、どちらに聞くのが正解なのか
アプリのUIをつめていきたい時、よくある悩みの一つに、「UI・UXの専門家の意見を参考にするか、完全に素人を対象にテストするのはどっちがいいか」という悩みがあると思う。 結論からいうと、どっちも必要なんだけど、実際にどういう順番で進めていけばいいかを考えてみた。 専門家の罠問題について まず、よく言われる事として、専門家は素人視点にどうしても立てないんじゃないかという問題がある。それならば、最初からおかんとかアプリに詳しくない人に触らせて、それを参考にUIを煮詰めていけばいいんじゃないかという考え。 でも、これをするのは、順番としては最後がいい。一番最初はUIに詳しい人に相談するのがよい。 例えば、iOSだとAppleのヒューマンインターフェイスガイドライン、Androidだとマテリアルデザインなど、そのプラットフォームのUIに詳しい人は、基本的なスタンダードなUIとしての正解を知っている
AppStoreの自動継続定額課金の新ルールについて (Auto-Renewable-Subscriptions)
今日、仕事終わってUnderTheRadorっていうポッドキャスト聴いてたら、AppStoreの定額課金のルールが変わるとかいう話題になり、「いやいや、またまた。。聞き間違いだろ。。」と思って調べたら、本当だった。 僕は、Lisgoで月額課金しようと思って、メディア系ではないからという理由でリジェクトされた過去がありまして、その時のいろいろ調べたら、AppStoreでの自動継続課金は雑誌とかメディア系じゃないと使えないという不可思議なルールがあることを知りました。 その時の記事がこちら。(今はあまり読む価値はないので飛ばしてもOK。) iPhoneの月額課金で直面するマニュアルにないルール かいつまんで説明すると、メディア系でないサービスは、AppStoreのIDを使った自動継続課金は使えず、自分でIDを管理する仕組みをサーバ側で用意して、わざわざユーザにログインしてもらって、なおかつ自動
面倒なユーザーサポートは孤独な開発のエネルギー源だった
最近ふと気づいたことがあって、アプリのユーザからの質問や要望に返信することが、実は大切なエネルギー源になっているのでは、ということです。 今まで、ユーザフィードバックから得られる、プロダクト開発に直接役立つメリットを色々とブログで書いてきたけど、モチベーションという要素はそこまで考えてなかった。 というのも、少し前、すごく絵が上手い売れっ子のエロ漫画家が、担当編集者としかコミュニケーション取ってなくて、本当に孤独で辛い作業だという魂の叫びを吐露していたツギャッターを読んだのがきっかけ。 作者によると、読者と交流するようなことはほぼなく、職業柄あまり人と会う機会もなく、編集者のために書いているような精神状態になってしまったりするらしい。 特にファンの人と直接交流する機会もないし、評判を聞く場もあまりないので、自分の作品は誰かを喜ばせているのだろうかという辛さが堪えるのだとか。 これはエロ漫画
�新しい便利なモノは新しい問題も作る
最近、Dモーニングっていうのを購読したんですよ。モーニングっていう雑誌がiPhoneやiPadで読み放題、一ヶ月に500円っていう値付けのやつ。 これ、モーニング系の漫画好きな人ならモトが取れるし、きっかけは友達に熱烈に勧められて、「た、たしかにそれはいいかも。。」と思って一週間まえから始めてみた。 使ってみた感想はなかなかいい！雑誌買ったらゴミになるけど、スマホならいつでもどこでも、気軽に読めるし、バックナンバーも自由にダウンロードできる。 僕は毎週木曜日にチャンピオンの刃牙を立ち読みするのが一週間の楽しみだったんだけど、毎週の楽しみがまたひとつ増えました。 と、こういう普通の日記を書こうと思ったんじゃなくて、このDモーニングの重要な設計について書きたい。 漫画の掲載順が重要になる この、Dモーニング、�雑誌版に比べて、漫画の掲載順が死ぬほど重要になるんです。それぞれの漫画のページビュー
アプリ操作の解説動画はコスパ高い
最近はもう動画の時代ですね。Twitter作ったジャックドーシーも、「ユーザに読ませるな。動画を見せろ。」と言ってます。 これ、直感的にまったくもって正しいというのはよくわかる。自分が新しい製品を調べる時も、説明文とか読むのがだるいからとにかく動画でまずはザックリ概要を掴みたい。 プログラミング学習も、かんたんな部分であれば、Youtubeで解説している動画をざっと見た方が参考書読むよりはるかに高速道路なんですよね。これは、アプリに初めて触れるユーザでも同じだと思う。 いくらスクショと解説記事が充実していても、アニメーションの連続でどの部分をタップして、どの画面でどう操作するかは、もうこれ、圧倒的に動画がわかりやすいんですよ。文字と動画では越えられない壁がある。 立派な動画作成は面倒 でも、動画って作るのが相当めんどいのです。 特にプロフェッショナルな動画となると、脚本、音声、編集など、も
ユーザヘルプの投資対効果
最近、Yコンビネーターがやっている、How to start a startupっていう動画授業が良質コンテンツなので暇な時に見てる。 その中でも、How to Build Products Users Loveが特に素晴らしかった！個人的ににすごく刺さった２つの事があって、その２つは繋がっている。この２つを聞いただけでこの授業は自分にとって価値があって素晴らしかった。 KevinさんはWufooというサービスを作って、今はYCのパートナー。Wufooは最初にYCに投資されたあと、ほぼ増資などもせず、黒字経営でそのまま進んで最終的に会社を売却したらしい。なので、お金を使わずどう製品をよくするかの話がてんこ盛り。 ユーザーヘルプは投資対効果が凄く高い まず１つ目に、マーケティングに力を入れる前に、ユーザに製品の使い方を知ってもらうように改善するほうが遥かに投資対効果が高いと力説していた。 こ
誰かいいエンジニアいませんかの話 | うめのんブログ
スタートアップをやってたり、これからやろうとしている知り合いの人から、いいエンジニアさんいませんかね？とよく聞かれる。 スキルの高いエンジニアさんは大抵忙しかったり、引っ張りだこだったりするのでどこも常に探し続けているんだと思う。 求人サイト使ってもよい人なかなかこないという悩みをよく聞く。あまりにもよく聞く質問なので、僕もどうすればよいエンジニアが入る可能性が高まるかを考えてみました。 結論からいうと、情報公開が効果的じゃないかと。ドラえもんで例えてみる。 例えば、ジャイアンがスタートアップを起業してエンジニアを探していて、知り合いのエンジニアのび太に相談したとする。 第一段階 ジャイアン「今エンジニア探しているんだけど、誰かいい人いませんかね？こんな、こんなことやってるんだけど。」 のび太「うーん、誰かいるかなあ。今は思いつかないけど、誰かいたら紹介しますね。」 こんな感じの状況が多い
片手操作特化のToDoアプリ JetDo
最近はZenyやListTimerなど、シンプルで使いやすいUIを突き詰めたアプリを作ってたけど、ついにToDoアプリまで作ってしまいました。 JetDoの無料ダウンロードはこちら 正直、ToDoアプリなんてありふれたものは絶対作るまいと思ってたんです。Storeにはありとあらゆる代用品があるし。そういうものはいいだろと。 じゃあ、なんで作ったか？ これは僕が人気ToDoアプリをたくさん試してどれも続かなかったからで、そもそも、それはなぜだろうかと疑問に思ったのが原点でした。 何度も何度も考えると、重要な要素が３つありました。 画面上部は片手で押しにくい ジェスチャーはタップと比べ疲れる タスク削除のサクサク感が重要 この３つの要素を解決して、余計な機能を削ぎ落とし、文字やボタンをでかくして生まれたのがJetDoです。ちょっと説明してみます。 画面上部は片手で押しにくい 僕はiPhoneを
動画学習の効率性
最近、ちょっとAndroidかRailsでも勉強でもするかなーと思って、ジュンク堂に行ったんですよ。昔から、新しいものを勉強する時は10冊ぐらい初心者用の本を買って勉強するのが効率的だっていう経験から。 ジュンク堂って座って読めるんですね。立ち読みならぬ座り読みです。そこで、ふんふんって読んでいると、「ああ、なんか新しいもの覚えるのってめんどくせえな。。」っていう怠け心が出てきまして。 ダメですね、これは。CakePHPからiPhoneアプリに移動する時もこの怠け心が相当強くて踏ん切りがつかなかったのを覚えてます。新しい事に挑戦しないプチイノベーションのジレンマです。 で、参考書って初心者の頃ってどれが自分にあってるかわからないから、何冊か買わないとダメなんですよ。そしたら参考書って一冊3000円近くしたりするんです。まだ本気でやるかわからない段階なのに3000円を何冊も(笑)。 これは、
動かしながらデザインする
UI・UXデザイン方面だと”動く”モックアップが作れると大きいなあと以下の記事を読んで思った。 翻訳：Railsを学んだことで私はより良いデザイナーになった インターフェイスは、動かない画面に貼り付けられた書類の束では決してなく、それは、インプットとアウトプットのフローなのだ。それが本当によいインターフェイスなのかどうかは、自分で使ってみるまで評価は下せないし、使ってみるにはまず作ってみないといけない。正確な評価・判断をしたかったら、実物に勝るものはない。 それまで私たちデザイナーは、動かないモックアップと、いくつかの動く部品を作って、それからプログラマの助けを呼んでいたが、この時の私達は、およそ2ヶ月もの長い期間を、プログラマの手を煩わせることなく、コンセプトの検証や新しいアイデアを実験するためのプロトタイプフェーズに費やすことができた。プログラミングの基礎知識は、私達デザイナーに da
フィードバックしやすい状況を作るHelpshift
Helpshiftというモバイルアプリ用のサービスが凄い。ユーザのフィードバックを出来る限り欲しいアプリ開発者やスタートアップはぜひオススメ。iOSとAndroidにネイティブSDKで組み込む。 こういうサービスをずっと探してたんだけど、なぜか今までよいのがなかった。やっと出てきて嬉しい。 なぜ欲しかったか 製品開発ではユーザの意見を詳しく聞いたり、ユーザがいかに低コストでフィードバックしやすい状況を作るかが凄く重要。 Webサービスだとユーザがすぐにサービス提供者側とチャットできるoLarkとか、素晴らしいサービスがいっぱいあるんですよ。 ただ、ネイティブアプリには似たようなサービスがなかった。 iPhoneアプリでよくあるのは、アプリ内にフィードバックボタンがあって、それを押すとメールで送信するモーダルが立ち上がるもの。 ただ、メール設定してなかったら動かないし、メール送るのって思った
要望にNOと言う時の伝え方が難しい
よく、製品開発には、ユーザの意見を聞くのがとても大切だ！ユーザの意見を聞け！とよく言われる。 でも、実際にやると、いろいろな事情が入り組んできて、とても奥が深く、難しくて、訓練が必要だと思う。そこで、ああでもないこうでもないと普段考えている事を書いてみたい。 ちなみに、僕のアプリのユーザはこの記事を読むとフィードバックのパンチ力が弱まって遠慮しちゃう可能性もあるので、読まないで欲しい。もしくは、これ読んでも遠慮しないで欲しい。 NOと言うのが精神的につらい この前見た動画で、アップルのアイブさんがこんな事を言っていた。 「僕たちは素晴らしいアイデアに数えきれないほどNOと言ってきて、その却下したアイデアの数こそを誇りに思っている。」 これはアプリ開発では大切な事だと思っていて、そもそも、提案される機能やアイデアの一つ一つは合理的で納得のいくものばかり。 ただ、すべての素晴らしいアイデアを採
認知リソースを削ると離脱率が高まる
以前、カーネマン先生のファスト&スローを読んだのですが、この本は素晴らしいので、アプリのUI設計やマーケティングに関わる人にぜひオススメです。 本で学んだ事は多岐にわたるけど、とりあえずUI設計に役立つ事を書いてみたい。 認知リソースのHP 以前から気にしてたけど、この本を読んでさらに気をつけるようにしているのが、アプリのUIを考える時の、認知リソースです。 僕は認知リソースのHP（ヒットポイント）と勝手に呼んでる。 ようは、認知リソースのHPが100あるとしたら、アプリを操作する時にだんだんと無意識にそのHPゲージが削られていくことを意識してます。 例えば、モバイルアプリ使っている時は、ノートパソコンを使っている時と違い、外出中で周りに騒音があったり、近くに魅力的な姉ちゃんのポスターが貼ってあったりと、認知HPがどんどん削られる機会が多い。 アプリをダウンロードするまでの、スクショでも削
UXのバグと治し方
最近よく考えていることに、UXのバグというものがあります。名前は勝手につけてみた。 ようは、アプリを使っていて、ユーザが混乱したり、分からない部分が発見されたら、UXのバグが発見されたと考えてる。 このUXのバグとフィードバックループは密接に関わっていて、Aという機能がすでにあるのに、ユーザから「Aという機能をつけてください！」とか問い合わせがあると、UXのバグがあるとなります。 問い合わせ以外に、データ分析で使われていない機能を計る事でも分かる。 このバグの治し方として一番いいのが、UIをパッと見て分かりやすくする、ボタンの名前を変える、メッセージやイラストで分かりやすくする形だと思う。 そして、ヘルプページのFAQに書くという最終手段もあります。 この最終手段は、多くの事をUI上のメッセージで書くと、情報過多でノイズが増えすぎてどうしようもないとか、ごくまれなケースとかに使います。 ヘ
開発を短い時間で集中して毎日やる
今年に入ってから毎日の開発時間を去年の半分にしてみた。 すると、毎日凄く集中できて、空いた時間に頭にスペースが出来てアイデアもわきやすく、効率もよくなったのでこれはいいかも。 タレブとDHHの話がきっかけ 最初のきっかけは、Rails作ったDHHが「開発なんて長時間やっても逆効果だから毎日の仕事時間を減らせ。8時間じゃなくて5時間、4時間だけにしろ。それだけ短かったらSNSなんて見てる暇はない。」とスタートアップスクールで話してたこと。 あと、去年タレブのAntifragileという本を読んで、短い仕事時間を毎日やるのが長期に渡っていいパフォーマンスを出す秘訣だというような事を言ってた。 アップストアでアプリを出すのは、結果が出なければ開発時間をいくらかけても価値が０となる世知辛い世界。でもこれは完全成果主義でなかなか面白い。 毎日の開発時間の成果をいかに上げるかっていうのを考えていると、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
