web-dev-qa-db-ja.com

私はドメインの専門家であり、プログラマーです。 UX、UI、HTML / CSSデザイナーとどのように連携しますか?

長い間、自白のため申し訳ありませんでしたが、私は本当にここで少し迷っています。

私はドメインの専門家であり、経験豊富なプログラマーです。過去4年間、私は熱狂的なユーザーを抱え、急速に成長している成功した非常に具体的な企業間Webアプリケーションの開発を管理してきました。

この重要な時点で、ユーザーエクスペリエンスの向上が最も重要な問題の1つだと思います。私は過去4年間にわたってユーザーと一緒に座っており、ユーザーを混乱させるもの、意味をなさないもの、そして単に私たちの設計上の不適切な決定であったものを正確に伝えることができます。

CookieカッターUI(Java Swing)に明確に触発されたjavascriptコンポーネントで構築)を見るたびに、アプリが「プログラマーによって明確に設計された」とユーザーが冗談を言うのを聞いたとき、私はうんざりし、再びうんざりします。 。" (そうだった)

再設計を始めるにあたり、私は論理的で直感的で美しいアプリを求めています。私はビデオコースを廃止し、人々にアプリをポイントするだけで十分です。これは説明が要らないので、コンテキストをヘルプサイトに切り替える必要はありません。

私のメンタルモデルの重要な部分を修正し、イメージを再作成するのに非常に非常に役立つフリーランスの「UXデザイナー」を雇いました。アプリ。

しかし、私のチーム(基本的に色覚障害の開発者)と私が実際に使用できる実際のHTML/CSSに移行しようとすると、少し迷っています。私はUXデザイナーに、高レベルの会話をHTMLレイアウトに入れるように依頼しました。彼は私が共有した広範なサンプルデータを見ることに関心がなく、見苦しいだけでなく、私たちが直面しているユースケースの範囲を実際にはカバーしていない何かを思いつきました。

「私はすべての詳細を理解している」ので、自分でワイヤーフレームを作成し、HTML/CSS設計を実行できるデザイナーを見つけるよう提案されました。

ええと、私はスクエアワンに戻りました。

私は自分のドメインの専門知識には自信がありますが、プログラマーとしては、プログラマーのチームでしか働いたことはありません。 (私の最初の仕事は、一連の計算幾何ルーチンの開発でした!)

責任と成果物をどのように分けますか

  • 要件を理解しているドメインエキスパート
  • ユーザーの考え方(または何か)を知っているux guy
  • 視覚的に表現できるデザイナーは?
  • 私たちは色覚異常で、音が聞こえず、とにかくコマンドラインを好むので、htmlマークアップ/ cssをスプーンで供給する必要があるプログラマー。

「適切な」ソフトウェア会社はどのように機能しますか?

助けてください!

UXデザイナーを雇うことは最初の移動として最適です。単にWebサイトuserとしてだけでなく、ユーザーの側面、彼のニーズ、彼の行動、彼の期待に焦点を当てますウェブサイトviewer。それは良い決断です。あなたは間違いなくスクエアワンに戻っていません。

Xデザイナーは、インターフェイスに抽象化のレベルを導入する必要があることを示しました。ユーザーは、データベースや、データがバックエンドでどのように表現されるかを気にしません。彼らはデータが彼らにとって何を意味するか、それが彼ら自身の心の中で何を表すかを気にします。

この抽象化は、言葉を通じて、概念を通じて伝えられますが、主にインターフェースを通じて伝えられます。この時点で、UXデザイナは、アプリの各ページに含める必要があるものの大まかなモックアップを提供し、一般的なフローがどうあるべきかを説明できるはずです。彼はいくつかの典型的なユーザーシナリオを説明する必要があります:ユーザーはここに来て、これを実行したいので、ここをクリックして、これらのフィールドが特定の順序で表示されるこのページに到達し、ユーザーはいくつかのアクションを実行し、目的を達成しました。 (アプリの機能がわからないため、例を示すのは難しいです)。

フロントエンド開発者は、これらのモックアップを機能するHTML/CSSテンプレートに変換する必要がある人物です。それはきれいである必要はありません。 aliveになるには、動作する必要があります。それは基本的に要素を配置することであり、まともな外観です。 Bootstrapはこれに最適なツールです。使いやすく、視覚的に理解できます。

I Designerはプロセスの最後のステップです。彼は、物事をきれいに見せるために、あなたのアプリに視覚的なアイデンティティを与えるためにここにいます。いくつかの例が必要な場合は、 ドリブル を確認してください。しかし、最初はそれほど必要ではありません。しばらくはユーザーを満足させるかもしれませんが、長期的には、UX部分とフロントエンド部分が優先されます。

質問に正確に答えられるかどうかわかりませんので、お気軽に質問してください。

9
jgthms

一般に、UXの進化のこの時点では、analysis/user-research/design/UX/front-endコードは、同じ人物またはチームがすべて処理するのが最適です。特定のシナリオで実際に何が起こっているのかを知ることは常に困難ですが、UX担当者が他の人にワイヤーフレームやHTML/CSSを行うよう提案している場合は、他の誰かを見つける必要があると思います。

1
grover5

あなたの問題は、ウェブサイトのフロントエンド部分の作成をどのように整理するかです。

Web開発プロジェクトは、「従来の」ソフトウェアエンジニアリングと同じ原則に基づいている必要があります。その考えを念頭に置いて、まず要件を作り直して、考えられるすべてのユースケースや例外などを決定する必要があります。私は、要件開発が最も重要であると同時に、Web開発で最も過小評価されている部分だと思います。

コーダーにどの色を使用するかなどを決めるのではなく、最初に設計を担当する人を雇うことを強くお勧めします。これは、製品を開発する効果的な方法ではないためです。デザイナーは、UXエキスパートのワイヤーフレーム(要件の完全なリストでワイヤーフレームを作成するのに役立つはずです。自分で作成しないでください)、CI、アイコン、グラフィックスに従ってレイアウトを作成し、色のスタイルガイドを提供します。フォント、サイトで考えられるすべての要素(ボタン、フォームなど)

デザイン/スタイルガイドの準備ができていれば、開発者はデザインや概念の心配をすることなく、クリーンなHTMLマークアップとCSSコードを(プリプロセッサとOOを使用して、コードと呼びます...)作成できます。 。

1
Plutonik

私の経験では、あなたが今いる段階は、UX担当者、製品の所有者、およびフロントエンド開発者が要点を明らかにするところです。

あなたがアップスレッドを提示したケースを取るために:ユーザーが入力したテキストは、UX担当者が作成したきちんとした理想化されたボックスをオーバーフローします。これには可能な技術的解決策があります(表示をx文字と楕円に制限する、「もっと見る」リンクで表示を制限する、全文を表示するがボックスを横に拡大して合わせるなど)。それぞれにユーザーエクスペリエンスと一部のドメインは指定できない場合があります(つまり、多くの場合、タックオンされた識別子を使用して複数の列を入力するため、切り捨てることができません:「ウィジェット1230-Aのパーツ番号」、「ウィジェット1230-Bのパーツ番号」...) 。

このチームは一緒に、どのようなソリューションが可能か、どのような妥協が可能か、そして一般にエンドユーザーにどのように最善のサービスを提供できるかを理解できます。このすべてを処理することは、UXラバーがUXロードと出会うところです。 Edgeケースと幅広いコンテンツの管理は、優れたUX担当者があなたのためにできることの大きな部分です。

高レベルのワイヤーフレームがどんなものか知りたいです。追加したボタンやチェックボックスが多すぎるとのことですが、今では雑然として見えます。ワイヤーフレームはボタンとチェックボックスを考慮していませんか?

また、UX担当者から貴重な洞察が得られたことを嬉しく思いますが、これは次のとおりです。

彼は私が共有した広範なサンプルデータを見ることに関心がなく、見苦しいだけでなく、私たちが直面しているユースケースの範囲を実際にはカバーしていない何かを思いつきました。

...は素晴らしいUXの人ではありません。少なくとも、彼は今あなたが必要としているものではありません。

1
Drew Beck

私はタスクを分割することに焦点を当てるのではなく、単に良いチームをまとめるだけに焦点を当てます。

理想的なUXチーム(IMO)には役割が区分されていませんが、ビジネスオーナーや開発チームと連携します。

それで、必要なタスクは何ですか?私の頭の上から、おそらく:

  • ビジュアルデザイン/ブランディング
  • uiデザイン/インタラクションデザイン
  • IA /フロー/ワイヤーフレーム
  • コンテンツのオーサリング(および見落とされがちなアイテム)
  • 分析/テスト/研究
  • フロントエンド開発

それは6人かもしれません。それは1人かもしれません。おそらく2人か3人でしょう。

できる限り、それらの人々が独立して、または段階的なアプローチではなく、一緒に作業するようにしてください。

直面する可能性のあるもう1つの課題は、質の高いフロントエンドを作成する能力と能力の両方を備えた開発チームを持つことです。私はそれが少しステレオタイプ化していることを知っていますが、私の経験では、ほとんどのJava開発者はHTMLやCSSのようなものにまったく興味がなく、JavaScriptを許可します。彼らは後ろと前の範囲に焦点を当てています最終作業は、IDEが提供するすべてのドラッグアンドドロップコントロールで構成されます。

これはしばしば最大のハードルです。解決策は、バックエンドチームとの作業に快適で関心があるのと同じくらい快適で、UXに関心がある、熟練したフロントエンド開発者を見つけることです。

幸運を!

1
DA01

Tl; dr:あなたが尋ねたすべてに対する私の答えは「それをテストする」ことです。

インターフェイスをやり直す必要がある場合は、色や単語だけでなく、ユーザーエクスペリエンス全体を再評価する必要があります。

まず、ターゲットオーディエンスに文化的に一致する既存の成功した製品を検討します。それが簿記システムの場合は、おそらくQuickBooksを検討します。製品が別の既存のフレームワークのプラグインである場合は、そのフレームワークから始めます。あなたの聴衆への製品の魅力を理解するように努めるべきです。あなたの典型的なユーザーはどの性別ですか?彼らはあなたとは異なる方法で教育または訓練されていますか?彼らはあなたと同じ文化の出身ですか、それとも最近の移民ですか?ユーザーはおそらく、あなたが理解できない、または完全に理解できないさまざまな設定を持ち、少なくともそれを受け入れる必要があります。そうしないと、ユーザーを疎外することになります。

次に、気に入ったインターフェイスを含むポートフォリオを持ち、成功した製品に似ていると思うデザイナーを選びます。視覚的に魅力的であるだけでなく、機能的であると個人的に感じるものでなければなりません。あなたの関係がどのように機能しているかを説明し、彼または彼女に何をさせるつもりかを説明します。彼らは最初の青空のビジョンを実現しますが、それをあなたの指示の下で既存の製品と統合する必要があります。失望を避けるために、事前に契約の条件を確立します。UIに対する最終的な権限があり、中間作業成果物に対してXを支払います。

設計者にユースケースから始めてもらいます。彼または彼女にあなたの製品を手渡すだけでなく、「それを改善する」と言うのではなく、ビジョンを思い付く最初の機会を彼らに与えてください。

ここで、設計者が最初の解釈をデモする時が来ました。設計者に、いくつかのユースケースを満たすいくつかの画面フローのモックアップを作成してもらいます。この段階で批判的であることを控えることが重要です。既存の画面で同じユースケースをモックアップすることもできます。両方をユーザビリティラボに持ち込み(ドアが閉まっている会議室とWebカメラが機能します)、慎重に選ばれた数人の被験者に評価してもらいます。テスターに​​は少なくとも3人の参加者が必要です(6人の方がよいでしょう)。少なくとも1つは製品の経験がなく、1つは初心者の経験があり、1人は経験のある人を含めます。一般的なユーザーの文化を代表する人々を選びます。彼らの半分に最初に新しいインターフェースを試してもらい、残りの半分に最初に古いインターフェースを試してもらいます。それらをインタビューし、両方の彼らの観察を書き留めます。彼らが好むインターフェースとその理由を尋ねます。彼らのどちらかの面が不快または不快であるかどうかを尋ねます。また、問題が発生した場合は、それぞれに報酬を与えるようにしてください。まともなレストランへの2食(およびドリンク)相当のギフト券は、数時間の努力にふさわしい場合が多く、口コミは後でボランティアを増やすのに役立ちます。

この時点で、あなたはあなたのデザイナーのアイデアが探求する価値があるかどうかについてかなり良い考えを持つはずです。ここで重要なことは、テスターからのフィードバックを聞くことです。彼らはあなたの実際の顧客とユーザーを代表しているので、好みの問題に関する彼らの意見はあなたのものよりも重要であることを覚えておいてください。

(もちろん、新しいデザインがこれまでのところあなたの製品とあなたの好みに反対していることに気づくかもしれません。そうでなければ、これはあなたが友好的に離れている場所かもしれません。)

ここで、「より機能する」プロトタイプを作成し、設計者が既存のデータをユースケースに組み込む必要があります。プロトタイプは機能的である必要はありませんが、画面を適切にナビゲートする必要があります。

この次のステップは、製品がビジネスアプリケーションか「楽しい」アプリケーションかによって異なります。一般的なユーザーに時間単位で支払いが行われるビジネスアプリの場合は、別のユーザビリティテストを実行することを検討してください。ユーザーがユースケースを完了するのにかかる平均時間を測定し、システム処理の遅延をシミュレートしたセットアップが必要です。現在のシステムのユーザーが同じ使用例を完了するのにかかる時間と比較してください。これをビジネスに売り込む場合は、生産性に悪影響を及ぼさないことが重要です。データ入力担当者の速度を低下させるアップグレードにお金をかけたくない顧客はほとんどいません。

0
John Deters