コンストラクターのためにコンストラクターを作成しないでください
あなたはマイクロファイバーのかぎ針編みのテーブルクロスのファンキーな（あなたのように）デザイナーを作りましたが、何らかの理由で誰もあなたの素晴らしい製品を買っていません。 そしてすべては、買い手が注文の製造を1か月待つことも、カスタマイズのために過剰に支払うことも望まないためです。 完成したテーブルクロスを購入する方が簡単で安価です。 「コンストラクターは合成例にのみ適していることが判明する場合があります。コンストラクターがなければ、実際のタスクは安価で完了しやすくなります」とClevernessの CEOであるSergey Bazhenov氏は言います。 価格、インターフェイスの複雑さ、製品の製造速度などの要因が競争上の優位性を低下させないようにする必要があります。
衣料品デザイナーAveevaの創設者であるAnastasia Andrizhinevskayaは、彼女のプロジェクトが競合他社を背景にどのように勝つことができるかについて語っています。 そして、私たちの競争上の優位性は、私たちのプロジェクトが、衣服を注文するための既存のアプローチのすべての肯定的な側面を統合し、不便さを平準化したことです。 すべてが高速、シンプル、高品質であり、大衆市場の価格です。」 服のデザイナーは、図に従って服をフィットさせ、クライアントの特定の好みに合わせるという問題を解決しますが、同時にクライアントにとって重要な他のパラメーターに従って「行き過ぎ」ません。
「新しいデザイナーを作成するには、スタートアップと同じステップを踏む。市場、競合他社のニーズを分析し、視聴者と協力し、そこから支払う価値を理解しようとする。 しかし、理解しておくべき重要なことは、人々がデザイナーを使用するためではなく、よりシンプルで費用対効果の高い方法で特定の結果を得るためにデザイナーに来るということです」とuCalc計算デザイナーのプロダクトマネージャー、Dmitry Molchanov氏
「 コンストラクターなしで同じ問題を解決しようとするとき、主な問題を構成するものを知る必要があります。 理想的には、最初に「ペン」を使用して同じタスクを解決するビジネスに参加し、どこを掘るかを知る必要があります」と、Sergey Bazhenovは要約します。
一晩でコンストラクターを作成しないでください
何かのデザイナーは、Tシャツのプリントを選択するのに役立つアプリケーションではなく、高品質で便利で複雑な製品について話している場合、長い時間を費やしています。 ユーザーとデザイナーとのすべての可能な相互作用を慎重に検討し、必要に応じて、プロジェクトを彼のニーズに適合させる必要があります。
WBの Kirill Grishanin –技術パートナーは、開発に関して次のように説明しています。「何かを開発する前に、何かを設計し、考えられるすべての状況を書き留める必要があります（ユーザーアクションに対するプログラムの応答はテストケースです）。 コンストラクターの場合、ユーザースクリプトの数が非常に多いため、それらを計画するのは面倒です。」
シリルは、成功したスタートアップの例としてReadymagを引用し、プロジェクトが数年間作成されたことを強調します。 別の最も成功したのはティルダです。 両方のプロジェクトは非常に徐々に開発され、現在の機能ほど多くの機能をすぐにはリリースしませんでした。
パターンと一般的なソリューションを追加する
特にインターフェイスが複雑な場合、設計者は一般的なソリューションを使用せずに締める必要があります。 「ウェブサイトビルダーには、空気のような既製のウェブサイトテンプレートが必要です。 アプリケーションデザイナー-一般的なタスク用の既製のアプリケーション。 などなど。 さらに、最初に開発する必要があります」とSergey Bazhenov氏は言います。
「チップ」で無理をしないでください
「機会の範囲」でクライアントを攻撃する必要はありません。あなたは彼を混乱させる可能性が高いです。 人にとって、どこで、何を、どのように行うかを素早く理解することが重要です。
「 黄金のルールがあります。最も重要な設定をすべて最初の画面に移動し、それらを適切に分類します。 ソーシャルコンストラクターデザイナーのプロダクトマネージャーであるOleg Lisovenko氏は次のように述べています。 uSocialサイトのウィジェット。
ヒントを追加
ユーザーを助けてください。さもなければ、彼は去るか、間違いを犯します。 「ユーザーはシステムに取り残されており、何かを理解しておらず、テクニカルサポートを書く意欲がない場合（お問い合わせフォームまたはオンラインチャットへのリンクを目立つ場所に配置するようにしてください）、デザイナーの仕事を辞めます。 ヒント-彼をターゲットアクションに導くもの。
最初は、一部のフィールドにヒントを追加しないことで、この間違いを犯しました。 たとえば、サイトのソーシャルメディアボタンのセットを作成する場合、人は自分のリソースのアドレスを示す必要があります。 「サイトアドレス」フィールドにヒントを紹介する前に、人々はそこに無効なデータを定期的に入力しました（たとえば、サイトではなくソーシャルネットワークへのリンクを提供しました）。 フィールドに何をどの形式で挿入するかについて明確なヒントを追加することで、入力エラーの数を1％に減らしました」とOleg Lisovenko氏は言います。
あなたがすでにテストしたものをテストし、テストし、もう一度テストする
uKitプロダクトディレクターのイリーナチェレパノバは 、長くて有益なストーリーを共有しています。「私たちにとって重要な教訓の1つは、収益化モデルの実験です。 2年前、私たちはトライアルモデル（テストに時間をかけ、特定の日からシステムの料金を支払わなければならない）と単一の関税を設定したサイトビルダーとしてスタートしました。 中小企業や民間の専門家がサイトに数ドルを支払う用意があるという仮説は確認されましたが、並行して、新しいユーザーの一部に異なる条件を示す分割テストを実施しました。
いくつかの分割テストの後、私たちは事実に遭遇しました：ユーザーはしばしば私たちの所に留まり、フリーミアムの支払いに良く変換されました。 シェアウェア版はより多くのお金を生み出したので、2016年1月にそれに切り替えました。
同時に、製品、市場、経済、または数十の要因がありますが、それらのいくつかは常に確実ではありません（たとえば、天候が支払いスケジュールにどのように影響するかがすぐにはわかりませんでしたが、つながりがあります）。 調査結果を再確認することにしました。 定期的に「frimumumに対するトライアル」テストに戻りました。 2年目には、ベースをスピードダイヤルするという重要な効果をもたらしたシェアウェアモデル（1年目の終わりまでに30万人、2番目-すでに130万人）が遠く離れた場所で収益性が低いことがわかりました。
テストの結果、製品の開発に伴い、人々はより多くの価値を見出し、それを使った作業の成果に対するリターンを感じるようになりました（コンストラクタを販売するのではなく、結果を販売する）。 今年の7月以降、新しいユーザー向けの試用モデルに戻り、会議で選択したユーザー向けにフリーミアムを保持しています。 しかし、これは、現在の調査結果をさらに再確認しないという意味ではありません。」