モバイルアプリケーションの設計について(開発者の目、心、心を通して)

ネットワークの広大さから、モバイルアプリケーションの設計に関する膨大な量のさまざまな情報を見つけることができます。基本的な原理、傾向、新鮮なアイデア、ロールモデルなどです。 したがって、この出版物はそれに関するものではありません。



モバイルアプリケーションの設計は実際のところそれほど重要ではないとよく耳にします。 プロジェクトの機能、コード品質、および一般的なアーキテクチャ、およびその他の技術的なニュアンスは重要であり、デザインは最終的にはそれほど重要ではなく、アプリケーションの外観にすぎず、これには同意しません。 私の意見では、デザインも同様に重要です。



この出版物では、この問題についての私の意見と、私の意見では、開発チームと設計チームの間の相互作用をどのように構築するかを共有したいと思います。



私の意見では、デザインはすべてではないにしても、アプリケーションの他の多くの側面に影響を及ぼし、最終的には開発中の製品の品質に影響します。 そして、読者を許してください、私はこれを引用せざるを得ません:

設計は製品の外観や認識方法ではありません。 デザインは、その仕組みです。 スティーブ・ジョブズ


アプリケーションのいくつかの側面を一緒に検討し、デザインがどのように影響するかを考えることをお勧めします。



機能性



では、なぜソフトウェア製品を一般的に使用し、特にモバイルアプリケーションを使用するのですか? 答えは簡単です-これまたはそのアプリケーションのいくつかの機能が必要だからです。

デザインがどのように機能を決定できるかはよく思えますか? まさか! すべてのアプリケーション機能は、要件、TK、または仕様で説明する必要があります。



しかし、急いで反対側から見てはいけません。 アプリケーションにいくつかの素晴らしい機能があるとします(たとえば、アグリゲーターアプリケーションで受信したサービスに関するフィードバックを送信します)が、これを行うことができるアプリケーションのセクションが見つかりません。 しかし、結局のところ、ユーザーがアプリケーションで見つけられなかったアプリケーションの機能は、実際には、このユーザーのこのアプリケーションにはない機会です。 しかし、そのようなユーザーが1人ではなく5人または10%である場合はどうでしょうか。



もう一度考えてみましょう。 同様の機能を備えた2つのアプリケーション(マップまたはナビゲーター)があり、1つのアプリケーションにはスケーリングとユーザーの位置に戻るためのボタンが配置されているため、スマートフォンを保持している親指でのみ簡単に使用できます。これらのボタンはあまり便利ではありません。 ユーザーはどのアプリケーションを選択しますか? 結局のところ、人々があなたのアプリケーションを特に使用することはあなたにとって重要ですか?



建築



開発プロセスに何らかの形で参加するほとんどの人は、アプリケーションアーキテクチャを正しく考えることが非常に重要であることに同意します。 このアーキテクチャは、開発中のいくつかの問題を予測して防止するのに役立つ一種のフレームワークまたは基盤になります。 もちろん、すべてではありませんが、これにより優れたアーキテクチャがそれほど重要になることはありません。 また、思慮深いアーキテクチャが非常に重要であることにも同意します。



設計はそれと何の関係がありますか? したがって、これらは直接接続されています。 アプリケーション自体の基礎となるもの:下のタブまたはセクションのあるサイドバー? サーバー部分はどのようなデータを送信しますか? また、特定のデータをどのような形式で送信しますか?



どのセクションでユーザーに何を表示するかを知ることは、アーキテクチャの設計を担当する人にとって役立つと確信しています。 そしてもちろん、彼はすぐにデザイン全体を見て、クリック可能なレイアウトを評価することをお勧めします。さもないと、何か小さなものが感情の爆発を引き起こし、ほとんど既製のアーキテクチャで大きな編集の必要性を引き起こす可能性があります。

そして、これを将来どのように拡張するのでしょうか?



その他多数...



正直なところ、高品質のデザインの重要性をまだ疑っている人にそれを表現したり伝えたりする方法がわかりません。 プロジェクトが成功するかどうかは、このプロジェクトのコードがどれだけきれいであるかだけでなく、含まれているバグの数にも依存します。 はい、もちろん、注文によってアプリケーションを開発した場合、これは重要です。 ただし、この場合、顧客は、自分のために開発するアプリケーションの将来のユーザーが、このプロジェクトのコードがどれだけクリーンであるかを気にしないことを理解する必要があります。 はい、重大なエラーはユーザーを混乱させますが、便利で機能的であれば、ユーザーはおそらく最も不快な間違いを修正するまで待つでしょう。 また、アプリケーションが完全に記述されており、コードにエラーが1つもない場合でも、ユーザーが使い方を理解できない場合は、すぐに削除します。



これらの理由から、デザインはアプリケーションの半分だと思います。



これに対処する方法は?



私の意見では、開発者と設計者の間の最大の相互作用のおかげで、上記のエラーを回避することができます。



デザインを作成する最初のステップは何ですか?



デザイナーは、新しいプロジェクトの作業を開始するときに何をすべきですか? 私の意見では、これらはワイヤーフレームではありません。 まず、設計者は、レイアウトを描画するように指示されたプラットフォーム/デバイスのユーザーである必要があります。 たとえば、これがiPhone用のアプリケーションである場合、デザイナーは日常生活でこのデバイスを使用することをお勧めします。



素晴らしい、デザイナーはこのプラットフォームのユーザーです。 次は?



デザイナーは最終的にワイヤーフレームの作成を開始できますか? いいえ、できません。 まず、設計者はこのガジェットを使用して、いくつかの最新のアプリケーションを見つけてインストールし、設計を検討する必要があります。 最初に、いくつかのアイデアを見つける必要があります。どんなに些細なことでも、インスピレーションを得る必要があります。



ワイヤーフレームの作成を開始します



私の意見では、設計者と開発者は、プロジェクトの完成まで、アプリケーションのこの段階の作業から始めて、常に連絡を取り合い、相互関係を保つ必要があります。 デザイナーが自分のアイデアやドラフトについて常に質問をする場合、開発者はプロジェクトの構造を早期に考え始めるのに役立つフィードバックを早い段階で受け取ります。これはコードの品質にとって重要です。



ワイヤーフレームを承認しました。



素晴らしい、デザイン自体を始めることができます。 ここで、デザイナーは間違いなく開発者と絶えず対話して相談する必要があります。 チームで相互支援が不要になることはありませんか? 開発者は、自身の経験から、潜在的な設計上の欠陥、または非常に重要な場所や開発の困難を予測できます。 さらに、開発者は、クールなアプリケーションを作成するのに役立つ興味深いツール(もちろん、UIを作成するためのツールを意味します)を認識しており、この知識をデザイナーと共有する必要があります。



開発者とデザイナーは、アプリケーションの各セクションについて一緒に考える必要があります。 デザイナーがリストのドラフトを用意したとしましょう。 表示するデータがない場合はどうなりますか? または、あまりにも多くのデータをダイヤルしますか? 画面上でどのように大きく/小さく見えますか?



デザインの準備ができました



次は? 私の意見では、このプロジェクトに関与する開発者は、レイアウトのレビューを実施する必要があります。 いくつかの間違いは、デザイナーが作成したすべてのものを注意深く検討し、考えることで回避できます。 設計者と開発者が互いに愚かなことをしないように助け合ったので、既製のレイアウトを承認のために提出することができます。



承認された設計



素晴らしい。 私の意見では、今だけでプロジェクトの開発を始めることができます。 一部のニュアンスは開発プロセス中にのみ表示されるため、デザインをわずかに編集する必要がある場合があります。 繰り返しますが、開発者は常にデザイナーと対話する必要があります。 はい、もちろん、開発者は自分で標準のソリューションを使用してこれらの変更を自分で行うことができます。 しかし、お互いの仕事を尊重しましょう。 確かにデザイナーは、アプリケーションの一般的な外観について、ある種のグローバルなアイデアや概念を持っています。 このアイデアのフレームワーク内での不適切な編集はすべて、アプリケーションの外観を台無しにする可能性があります。 そして確かに、開発者は単にこれに気付かないかもしれません;彼の頭は別の人によって占有されています。 このような変更は、すべての小さな変更が最初に選択されたアイデアまたはコンセプトのフレームワーク内に収まるように、設計チームによって承認される必要があります。 これは、アプリケーションに関するユーザーの第一印象にとって非常に重要です。



結論の代わりに



これらは、モバイル開発における設計の重要性についての考えであり、さまざまなアプリケーションを作成する経験が発達したために私に形成されました。 どのような場合でも、設計と開発に対するこのアプローチこそが正しいと主張することはありません。 それにもかかわらず、すべての結論は1つまたは別の開発経験の結果であるため、私の結論は誰かがいくつかの間違いを回避するのに役立つ可能性があります。



All Articles