blog

アプリ開発者へのいくつかの提案

アプリを成功させるには、従うべき方法論があります。例えば、ユーザーにレビューを依頼することは、ギャップがないかをチェックするタイムリーな方法です。その他、関連する経験はありますか? ...\n...

Jun 14, 2016 · 3 min. read
シェア

最近、Dzoneウェブサイトは、アプリ開発者が開発経験を共有するための記事「アプリ開発者への提案」をリリースしました。

特定のプラットフォーム向けのアプリケーション開発を何年も続けていると、多くの経験を積んでいるはずです。これらの経験は、この分野に入ったばかりの開発者にとって、とても役に立つことでしょう。この記事では、私のWindows Phoneプラットフォームでの開発経験をいくつか紹介します。

[]

[]

審査は重要です。

入念にレビューされたアプリは、本質的には優れているがあまりレビューされていないアプリよりも優れている傾向があります。

レビューに参加するユーザーを招待

この時点で、あなたはこの方法があまりにも「攻撃的」だと感じるかもしれません。レビューに参加したくないのであれば、参加する必要はありませんが、それでも効果はあります。レビューの数は指数関数的に増加し、数週間のうちに100件から200件、400件と増えました。以前は100件のレビューを集めるのに1年かかっていたのです。

特徴の広がりに注目

製品が成長するにつれ、ユーザーからもっと機能を追加したいというフィードバックを受けることがあります。最初のステップは、アプリに追加する必要があるかどうか、機能の重さを量ることです。例えば、天気予報インジケーターは、ポッドキャストプレーヤーに追加する必要が本当にあるのでしょうか?アプリが対処しようとしている問題の助けになりそうな機能でも、プログラムが肥大化する原因になる場合は、さらに危険です。ドキュメントエディターに、あらゆるクラウドストレージサービスを追加する必要が本当にあるのでしょうか?おそらく必要ないでしょう。Box、Dropbox、Amazon EC2、Google Driveを統合したいユーザーもいるかもしれませんが、このアプリはWidows Phoneプラットフォームをターゲットにしており、Windows Phoneユーザーは全員Microsoftアカウントを持っているため、彼らが自分で入手する必要があるのはSkyDriveだけです。-これがおそらく目的でしょう。

単純化、単純化、そしてまた単純化

ユーザーがアプリを使うのにチュートリアルに頼る必要があるなら、その製品は失敗しています。デスクトップでは、ユーザーが製品に慣れる時間があると想定できますが、モバイルデバイスでは不可能です。あなた自身の視点で考えてみてください。アプリの学習にどれくらいの時間を費やしたいと思いますか?おそらく1分もかからないでしょう。ゲームやアプリが複雑すぎると、そのアプリは閉じられてアクセスできなくなる確率が高くなります。これを防ぐには、いくつか注意すべき点があります:

  • プラットフォームデザインの法則に従い、ユーザーは意図的にアプリに適応する必要はありません。
  • 小さなフォントは使わないでください。モバイルデバイスの画面サイズは限られています。ユーザーが製品を使うのに苦労しているように見せてはいけません。
  • 各ページはアプリケーションに関連する限られた機能を含むべきです。

ユーザーとの連絡の維持

迅速な反復

リリース時に完璧な製品はありません。フィードバックに素早く対応し、できるだけ早く変更や機能追加を行うようにしましょう。メンテナンスが行き届いた製品であれば、ユーザーからの信頼も高まり、同時にユーザーエクスペリエンスも向上します。

スターバックスコーヒーの誤謬

私はよく、ユーザーがアプリに0.99ドル使うよりも、コーヒー1杯のために1日5ドル送る方がいい理由について、開発者が文句を言っているのに気づきます。核心的な問題は、スターバックスでカプチーノを買うと、別のスターバックスカフェで別のカプチーノを買うことになりますが、アプリの場合はそうではないということです。開発者として、あなたは「アプリは素晴らしい、きっと気に入る」と言うかもしれませんが、ユーザーがそうでなかったらどうなるでしょうか?たとえ値段が高くなくても、一度購入したアプリはずっとユーザーのものです。一度愛着を持ってしまうと、次にそのような商品やアイテムを購入するとき、ユーザーは考え込んでしまいます。そこで、より多くの新規顧客に投資してもらうためにレビューが必要なのです。

Read next

ETLプロジェクトで数百のSSISパッケージを管理するためのログとパッケージ設定のフレームワーク

SSISのロギングシステムについての記事を書く準備をしていましたが、完全な記事を書くのは難しいことがわかりました。というのも、この記事の内容はあまりに拡張できるため、拡張の部分が増えるたびに、コードや例、理論的なサポートが増えることになるからです。そのため、より一般的だと思われるLOGの部分を選択し、ここで共有することで、ETLロギングシステムを設計する際のインスピレーションと助けになることを願っています。

Jun 14, 2016 · 33 min read