フリーランスのUXデザイン会社の新しいウェブサイトに取り組んでいます。これまでのところ、ユーザビリティテスターで非常にうまく機能している機能の1つは、私の設計プロセスを説明するサイトの新しいセクションです。テスターは、これが実際に私の会社を他のデザイン会社と一線を画し、他のほとんどのデザイナーよりもクライアントプロジェクトが少ないという懸念を和らげるのに役立つと述べました。
私のプロセスは、過去1年半に複数のクライアントのために行ったプロジェクトに基づいており、次のようになります。
平均的なユーザーが私の会社の新しいサイトで残りのテストを行っているので、もう1人の上級UXデザイナーにテストしてもらいました。 (これは意図的なものでした。私は大規模なUXチームに参加したことがないので、デザインレビューを探していました。)彼のフィードバックは非常に役に立ちました。彼の質問のうちの2つは、私のプロセスについて本当に考えさせられました。
私のクライアントにとって、テーマのカスタマイズはこれまでうまくいきました。しかし、私の業界では、クライアントのサイズ、予算、およびカスタマイズのニーズはかなり大きく異なります。開発者のチーム、または少なくとも1人の開発者がフルスタックの開発作業を行う必要がある人もいます。自分でフルスタックの開発作業を行うことは私にとって選択肢ではなく、費用効果が高いとは思えません。
現在、開発者を雇う予算がありません。おそらくさらに1〜2年先の大きなチームを含む長期プロジェクトを含む潜在的な将来のプロジェクトは、請負業者を雇う機会を与えてくれるかもしれません。しかし、これが間違いなく必要になると思われるプロジェクトが地平線上にない限り、開発ステップが確実にどのように処理されるかはまだ言えません。
この状況で、会社のWebサイトでプロセスの各ステップについて書いている場合、開発ステップにどのように対処しますか?
編集-一部のテーマカスタマイズプロジェクトでは、クライアントの社内ウェブマスター/バックエンド開発者と協力しました。
私たちはあなたではなく、あなたが何をどのように行うのかわからないので、この質問に答えるのは難しいので、投稿した手順が従う手順と順序だとすると、それが正しい答えです。
ただし、クライアントとのコミュニケーションのその側面を変更したいと思うことはあまりありません。必ずしも変更を加える必要はありませんが、少し変更を加えればすばらしいと思います。
最初に、あなたが投稿したものの問題に取り組みましょう。
ステップ3から5では、何を質問しますか?文法的には、ユーザーの視点から既存のサイトをテストおよび調査して、個人の専門家の意見を補完していると言いますが、そうですか?もしそうなら、もう少し長い説明が良いので、誤解の可能性はありません。次に、新しいサイトのワイヤーフレームを使用してこれらの手順を繰り返す必要があります。そうでない場合、元のデザインには問題があるかもしれないが問題はなく、ユーザーや関係者が望んでいることは傲慢に聞こえると述べています。または無責任。
ステップ6、その位置では多くのレベルで間違っています。 1つ目は、設計していないこと、2つ目は(基本設計としても)コピーしたこと、3つ目は、ワイヤーフレームとプロトタイプの関連性と使用法がわからないことを明確に述べています。あなたはそれらに言及しているので、それからあなたがそれらをあなたが理解していない流行語として単に使用していると見ることもでき、それが間違った順序でそれらを置いた理由です、ゼロ理解のユーザーにとってはそれは大丈夫かもしれません、しかし、少し知識があるクライアントにとっては、それは悪いように聞こえるかもしれませんし、あなたに対する彼らの自信を減らすかもしれません。
サイトの美学とデザインの作成がクライアントに関連させたいものである場合は、それを行いますが、ワイヤーフレームを作成してテストした後、適切な位置にあります。使いやすさ、アクセシビリティ、UXに重点を置いているために関係がない場合は、リストから除外して、後で説明します。たとえば、情報をセクションに分けます。1つのセクションはサイトの情報アーキテクチャ用で、もう1つはデザイン用です。
手順7と8はテーマを選択した後ではなく、テーマはサイトのニーズに適応する必要があり、サイトはユーザーと利害関係者のニーズに適応する必要があります。
ステップ9と10は問題ありませんが、ローンチ後の分析については言及していませんが、何もしていなくても、正直です。その場合は、それを開始する必要があります。それを行う場合は、リストから除外しないでください。クライアントがサイトを適切に機能させるためにそこにいることをクライアントに思い出させるための最も重要な側面の1つであり、すぐにサイトを放棄するわけではありません。することができますように。
ステップを深く分析しましたが、それほど深くはありませんが、これらのステップをどのように調整してユーザーをよりよく支援できるかを見てみましょう。私はあなたがすでにウェブサイトのための良い最初のデザインが何であるかを決定するのに十分な経験があり、それをあなたのクライアントと彼のユーザーのニーズに適応させるのに十分な柔軟性があると考えています。
これらの手順はすべてを網羅しているわけではなく、テキストは最終的なものではありませんが、UXの観点からプロセスを作成する方法についてのアイデアを提供します。オリジナルのデザインを行うが、最終ユーザーの利益のために物事を選択してテストするための適切な重みを与える。これは開発段階でも同様のプロセスです。あなたは彼らのチームと協力できることを言及できます。しかし、開発や設計の能力があまりないことを明確にする必要があります。それは、領域を知らないからではなく、別の領域に焦点を当てているからです。
もちろん、各ステップはサイトで必要なだけ詳細に説明できるため、クライアントは各ステップがどのように機能し、プロセス全体とどのように関連しているかを実際に理解することができます。
また、支払い、コミュニケーションの方法、クライアントからの入力の期待、成果物のタイミングなど、大げさなプロセスのどこかに言及する必要がありますが、それはサイトの別のセクションにある場合があります。それはあなたとあなたのクライアントにとっても良いことだと私は確信しています。
上記のすべては、私たちが社内で使用するものと似ていますが、新しいデザインに移行する間、オンラインではその説明はありません。プロセスの進化を示すタイムラインのようなクライアントとの相互作用に関するページ、設計の詳細について説明するページ、分析とテストについて説明するページ、およびコンテンツの関連性を説明するページがありましたユーザーは書き込み/配信する必要があります。
あなたはフリーランスの人なので。開発者は、各段階の計画段階に関与します:1、3、5、6、8、9、10。
開発者がデザインをコードに実装する前に、クライアントはデザインを承認する必要があります。計画プロセス中に、開発者は、クライアントが設計を承認してから開発が行われる期間を見積もることができます。
あなたの質問は少しあいまいです。
最初に「dev.stepの記述方法」を尋ね、次にourプロセスについて尋ねます。その上、あなたはあなたの背景の説明の間にいくつかの問題を提起します。
役立つコメント、回答、質問があります。
あなたのプロセスを説明したい場合、これは履歴書、求人、または試験の解答ではないことを理解する必要があります。これを見込み顧客に説明しています。したがって、彼らが何を知りたいのか、彼らが必要なものについて考える必要があります)知りたいこと、彼らが知りたいこと。
これは本当に重要です!
上級UXデザイナーをテストに投入しました。ワイヤーフレームについて知っている「仲間のデザイナー」や、「テーマを選択する」という意味の顧客はいますか?
または、顧客は自分のコーヒーバーや自分のリサイクルショップを経営している「エンドユーザー」ですか。そこが大きな違いです。レジ係は「テーマ」をサイトの視覚的なトーン(レトロ、モダン、フラワーパワー、プリンセス、海賊)であると見なすかもしれませんが、同僚のデザイナーはWordPress=テーマについて考えます。
ほとんどのお客様が作業の全体的なコストを懸念していることを保証できます。 weは「適切なジョブを実行する必要がある」と主張しますが、エンドユーザーは、心に留めておく必要のある予算または制限があります。彼らがあなたが説明するプロセスを見るとき、彼らはおそらくあなたが各ステップにどれだけの時間を費やすかについて大まかな感覚を得たいと思うでしょう、そして彼らはおそらくこれを使って進歩を追跡するでしょう。
お客様は、プロセスのどこにtheyが関係しているか、またプロセスのどこに結果が表示されるかを知りたいと考えています。
あなたのために、プロセスの説明をユーザーに示すことができるのは素晴らしいことです。プロセスで何をする必要があるかについていくつかの引数を入力しないように、エンドユーザーが何をするかを明確にします。
これは、暗黙の状態および進捗レポートとしても機能します。
ウォーターフォールモデルはシンプルなので気に入っています。厳密なウォーターフォールプロセスがプロジェクトの実行に適していない場合でも、簡単な説明としては非常に便利です。
何作成すべきか->How作成する必要があります->Createit ->テストそれ
お客様がこの手順を外部委託しているかどうかを知る必要はないと思います。彼らはそれが正しく行われたことを知りたいだけです。
一般に、「開発」はそれ自体が説明的なものだと思いますが、次のような用語を使用できます。
最終行:
顧客の考え方に足を踏み入れ、理解する
知りたいことと
彼らが知っておくべきこと...説明が顧客の言語であることを確認してください。
開発について説明することに関するあなたの質問の一部についてお話ししたいと思います。
それは常に'Bringing the desired to life'です。その一連の考えに従うと、それを'機能と美学をコードに変換する'と表現できます。このステートメントは、私の経験の中で最も特異な解釈を得ています。これは、プロセスのステップ8を置き換えることを目的としています。テーマはまさにそれを行い、将来の開発者や請負業者のスタックもそうです。
「デザインをコードに変換する」とは言いたくありません。デザインプロセスの結果である美学と機能性について言及したいと思います。
テーマを使用していても、ビジネスが成長するにつれて、開発スタックの育成への道筋をたどる場合は、おそらくそうなることはありません。そしていずれにしても、近い将来、設計の実装が容易になれば、開発段階に入っても「美学と機能をコードに変換する」ことになります。
すべてをまとめるには、ステップ6を「ビジュアルデザイン」として説明することを検討してください。この質問に答えた他の人が示唆したように。
使用する言語は、規模の大小にかかわらず、運用の規模に合わせてメッセージを配信する能力が動的である必要があります。