インターフェースの設計における現実モデル、またはプロセスの効率を数回高める方法

今日の多くはプロトタイプ作成を使用しており、プロジェクトの最初の段階でインターフェースのプロトタイプを開発しています。 この段階で間違いを修正することは、後の段階よりも数倍安くなることはよく知られています。



ただし、開発には別の段階があり、非常に大きな役割を果たしますが、十分な注意を払う人はほとんどいません。 そして、この段階は、インターフェースを含む頭の中のプロジェクトのモデルです。 そして、他のすべての段階でエラーが表示され、簡単に検出できる場合、プロジェクトとそのインターフェイスを介して考えるプロセスにおける思考プロセスのエラーは、プロジェクトが戦闘状態で既にテストされている最後の最後でのみ理解可能になります。



この種のエラーを見つけて対処する方法、および実際のプラクティスの例については、こちらをご覧ください。



エラーの本質は簡単です。 人は世界のあらゆる側面の考えを心に留めており、現実にはそうなると信じています。 実際、頭の中の写真と現実の違いは、どこにも行かないさまざまな専門家による数十万ルーブルと数十時間の仕事に変わります。



最初に、エラー自体が存在することを認識する必要があります。 通常、人は、インターフェースを最後にあるように正確に設計し、「すべてを正しく」行い、「考え直す」ことができると確信しています。 しかし、そう考えることは誤りです。



まず、すべてが変わります-これは、あらゆる製品の開発に関する法律です。 したがって、プロセスが簡単に変更されるほど、より良い結果が得られます。 したがって、ルール-ある段階で必要最小限のボリュームを作成する、たとえば1日で反復する-間違ったことが行われた場合、それを捨てて最初に行うのは残念ではありません。



同時に、製品のエンドユーザーに対して忠実度または不忠実度の検証を行う必要があり、製品にはライブ（テストではなく）データが必要であり、すべてが本物でなければなりません。



第二に、初期段階では100％考えることはできません。 それは公理と見なすことができます-インターフェイスデザイナーまたはプロジェクトコンセプトの開発者がプロ​​ジェクト分野で深い経験を持っているまれなケースではない場合、99％のケースですべての複雑なチップが渡されます。



唯一の可能なオプションは、エンドユーザーの役割に慣れることです（会計士用のソフトウェアを作成します-会計士になり、ソフトウェアを会計士として見て、会計士の観点から問題を解決する方法など）。 しかし、これには多くの経験と優れたスキル、そして多くの場合時間を必要としますが、これは常に可能ではありません。



したがって、特定のユーザーの唇から反復のための主要なタスクを特定するよう努力することは合理的です（同時に、問題自体をユーザーがソリューションを見る方法から分離します-結局、ユーザーはプロジェクト開発においてあなたとは異なり専門家ではありません）。



そして、イテレーション自体は、ライブデータを部分的にしか使用しない場合でも、できるだけ短く、ライブユーザーとの作業にできるだけ近づけてプロジェクトに提供し、フィードバックを慎重に収集して観察する必要があります。



例として、人事部の自動化を考えてみましょう。私は現在、ある会社で働いており、優秀な専門家のチームと協力しています。 毎日リリースが行われるプロセスを構築し、毎日1つまたは別の機能が導入され、ライブユーザーと実際のデータでテストされています。 このような改良のペースと本当に必要なチップのために、翌日には到着します。



したがって、履歴書の自動化を行ったとき（すべての履歴書をメールなどで検索し、それらを手で追加し、サイトから追加した少女から受信しました）、ステータスによって分類されました（視覚的に、タブは確認されず、送信されたと思いました）テスト、拒否、拒否など）、そこで、あるタブから別のタブに履歴書を転送するプロセスで、ポップアップが表示されました-転送先。



転送後、その人は最後のタブに投げられました（例えば、彼は「レビューされていない」、彼を選んでクリックして「拒否」に移動し、拒否の理由を入力しました-そして彼は「拒否されました」に投げられました）。 起動時に、人事部のスタッフが数百の履歴書をソートしたとき、現在のタブに留まる方が便利でした-最終タブに移動した後、履歴書リストをソートした場所に戻る必要があるため、判明しました



デザイナーが実際の問題を解決するのに、12人ではなく100人の履歴書を扱っていれば、彼はこの間違いを犯さなかったでしょう。 彼女の修正には数時間のプログラマー作業がかかりましたが、そうではなかったかもしれません。 また、名前によるフィルターを使用すると、1000人の履歴書を処理しようとした場合、名前によるフィルターが非常に必要であることを理解できます。



実際、多くのスタートアップは人々が考えるので不必要です

それ自体はユーザーよりも賢く、不必要なインターフェース、エンジン、プロジェクトを作成し、時間とお金を費やします（そしてしばしば自分自身だけでなく）。



このアプローチは広義のパターンであることに注意してください。 これは、どのフィールドにも適用できることを意味します。 たとえば、プログラミングの場合-顧客から技術仕様を取得し、ロジックの観点からは正しいが、コードは「より高速」なプロトタイプをスケッチします。 メインロジックが完了するまで、すぐに表示し、改善点のリストを取得します。 次に、リファクタリングして、確実に実行します。 このアプローチにより、時間と顧客時間を100％から1000％節約できます。



あなたのプロジェクトで、必要な機能の割合が100％になるよう努力してください。