ユーザーエクスペリエンスの実践者は、コードについて心配する必要がありますか？
私にとってこれは簡単な質問です–もちろんそうではありません。しかし、最近いくつかの質問と回答について、私はこの意見のために戦う必要があります。私は間違っているかもしれないので、知っておく必要があります。ユーザーエクスペリエンスの実践者は、設計の選択の実装について心配する必要がありますか。コード]？
ソフトウェアを作成するプロセスは、設計者（または設計に貢献する設計者）が媒体について技術的に十分に理解している場合、はるかに効率的だと思います。たとえば、Webサイトのデザインでは、CSSで実現できることを理解するのに役立ちます。CSSでは表現できないものをデザインし、代わりに画像（またはおそらくJavaScript）が必要な場合、開発時間に影響を与える可能性があるためです。ページ読み込み時間、および異なるデバイス間で異なる外観。
理論的には、UXプラクティショナーはメディアの背後にあるテクノロジーを理解する必要はありません。十分な時間とお金と優れた開発者がデザインを実現できるとしたら、それは最適な運用方法ではありません。
UXプラクティショナーは、効率的なプロセスのために、メディアについての高度な技術的理解を必要とします。そのため、彼/彼女は、関連する言語のいくつかを理解している可能性があります。 UXerは必ずしもこれらの言語の専門家である必要はありませんが、彼/彼女はよりよく理解します。
もちろんする必要があります！
まあ、機能の実装の実際の構文を技術的に理解したり知ったりしていないかもしれませんが、特定の機能の実装にどれだけの労力が費やされるかを理解し、認識しておく必要があります。良いUXは安くはありません。デザインの実現には時間がかかります。
UXの人々は、製品がとるべきルートについて重要な決定を下す原動力の一部です。 UXチームには、IxD、IA、Gdを使用して設計され、後で開発チームによって実現されるアイデアが付属しています。
UXの人々が開発チームを詰まらせるソリューションを使い続ければ、製品は驚異的になります。
したがって、UX担当者は、開発の観点から実際に何ができるかについてある程度の知識を持っている必要がありますが、必ずしも設計の実装方法を知っている必要はありません。
逸話的な視点...
いくつかの場面で、実装について何も知らない「UXエキスパート」と作業したことがあります。これらの場合、私の役割は主にクリエイティブディレクターでしたが、UXの役割を次第に担っています。その理由は、エキスパートには、猫のパッチワークを超えてエクスペリエンスをプッシュするための幅広い知識がありませんでした。問題は時間とともに明らかになり、それに伴って私の役割も拡大しました。
アプリとサイトでは、完全な方向性を提供するために何ができるかを理解する必要があります。コーディングする必要はありませんが（他の人が言ったように）、間違いなくプッシュできる必要があります開発チームは少し。それ以外の場合は、「実行できません」と表示されます;）
簡単な答えは「いいえ」です。コードについての知識がなくても、UXからキャリアを積むことはできます。
しかし...
物事をどのように実装できるか、何が可能で何ができないかについての実用的な知識があると、常に役に立ちます。基本的なレベルで技術プロセスを理解することは、開発チームにアイデアを伝える際に非常に有益です。開発チームは、完全にうまく機能していると思われるものを変更するという考えを好まないことで有名です。彼らは、はるかに大きなプロジェクトに取り組んでいるのです。納得して仕事を進めるのはあなたの仕事です。基本的なレベルの技術知識を持つことは、あなたの議論に多くの重みを加えることができます。
私が言えることは、それは私を大いに助けてくれたということです。
それはあなたの傾斜に依存します。私は研究やIAに焦点を当て、UIやプロトタイピングに関与しないUXの人を知っていますが、HTMLやCSS（またはLess、compass、sassなど）に100％流暢な（私のような）一部の人も知っています。 ）と、プロトタイプを作成し、開発者にメッセージを提供するために必要なものを提供する、jQueryとcoffeescriptのビット。 （私はまた、ピクセルパーフェクトなモックアップも提供しています。）
実際、UXは明らかにコードに重点を置くべきではありません。または、少なくともHTMLとCSSのみを使用してください。しかし、Bootstrap cssボイラープレートやLess.cssなどのようなものを活用する方法を知っている場合、それは本当に全体の要点を得るのに役立ちます。
ライブでプッシュされるコードの本番実装について話している場合-いいえ。フロントエンド開発者またはバックエンドエンジニアは、そのコードを記述して維持する必要があります。問題は、レイアウトとUIデザインの実装にあまり焦点を当てていない可能性があるため、HTML部分を常に信頼できるとは限らないことです。
迅速なプロトタイピングのためにjQueryとcoffeescriptをいじる以外に、実際に本番用コードを書くのはおそらくUXの要件ではありません。
画家は油やキャンバスについて心配する必要がありますか？造園家は排水や土壌の状態について心配する必要がありますか？ファッションデザイナーは、生地の織り方やステッチのパターンについて心配する必要がありますか？
時々、いいえ。彼らは単に審美的な教祖になることができます。しかし、ほとんどはそうです。他の職人のように、媒体が機能していることを理解することは職人の一部です。木目を理解している大工は、そうでない大工よりも良い完成品になるでしょう。
媒体をどのように詳細に理解する必要がありますか？まあ、それはすべて多くの要因に依存します。
補遺：
すべての回答を読むと、2つの一般的なPOVがあるようです。
- UXユーザーは、実用的なものを設計できるようにコードを理解する必要があります
- UXデザイナーはコードを理解すべきではないので、コードに制限はありません。
XプロセスはUIの開発を支援する必要があると記載することで、両方の視点に対応できると思います。
つまり、コードを知っているかどうかは、チームレベルであるため、個人レベルではそれほど問題ではありません。
製品のエクスペリエンスの作成に関わるチーム、つまりUI-は、プレゼンテーションレイヤーの構築に必要なコードを理解する必要があります。
したがって、これは個々のスキルセットの問題ではなく、チーム構造とプロジェクト開発プロセスに関する問題の多くになると思います。
アジャイルはそれを助けるようです。企業の組織図に関係なく、アジャイルプロセスは、大規模なチームが常に互いに同期するように強制する傾向があります。ワイヤーフレームの設計者は、データベーステーブルの設計者と常に連絡を取り合う必要があります。
これを行うと、ウォーターフォールプロセスの方がはるかに困難になります。ウォーターフォールプロセスでは、UIを設計するユーザーは、実装可能な何かを事前に設計する必要があります。そのため、そのような状況では、UXチームにコード担当者を配置するか、UI開発者に連絡してループに参加させる必要があります。
まず第一に、素晴らしい質問です！
私にとっての質問は、「UXプロフェッショナル[〜＃〜] [〜＃〜]のコーディング方法を知っておくべきか」ではありません。
質問された質問は、「UXプロフェッショナル[〜＃〜] [〜＃〜]をコードについて考える」です。
私にとって、前者は違います。後者は圧巻ですYES！
私は最近、 "T"形の人々とは対照的に、 "I"形 人々の概念について読みました。これは本当に私のポイントの核心です：
このアイデアは、人間中心のデザインの初期のパイオニアの1人であるブライアンシャケルの1人である英国人のおかげで、私の頭の中で結晶化しました。私はかつて彼に、他のものと比較して驚くべきことをしている学生を区別する特定の属性に気付いたかどうか尋ねました。彼の答えは洞察に満ちたものであると同時に即刻でした。
彼は言った： "優秀な学生はすべて抽象的な思考のための卓越した能力を持っていましたが、彼らはまた物理的な材料とツールに本当に強い基盤を持っていました。これによって、彼は特定の問題の詳細を超えて、より抽象的な方法で、そしていくつかの方法で、より一般的な方法でそれらについて考えることができることを意味しました。手を汚す同時に、彼らが成長するにつれて、全員が自転車や車の修理などに深く関わっていました。
実際、これがどのように明白であるかは問題ではありませんでした。物理的なマテリアルとツールの乱雑で汚れた魅力的な世界のいくつかの側面において、彼らが「できる」「できる」能力を持っていることが重要でした。つまり、現実にはしっかりと根拠があったのです。
「私は抽象的な世界に住んでいて、それが考えられるなら、私の仕事は終わった」という立場をとるなら、あなたはあなたの開発者との協力的なパートナーではありません。
コードを「心配する」とは、設計と実装の両方で既存の問題を解決する新しい方法を見つけるための扉を開くことです。 「心配しない」とは、線を引いて「私のサンドボックスの外で、それは私の問題ではない」と言うことですが、これは誰にとってもあまり役に立ちません。
優れたデザインとは抽象概念ではなく、ユーザーが操作する生きている/機能するものです。設計の決定が実装（コード）にどのように関係するかを知ることで、抽象的な設計を緩和し、開発者が最善の解決策を見つけるために創造的かつ積極的に取り組むことを促すオープンチャネルを作成できます。
実装の問題が原因で抽象的なデザインが開発から戻ってきた場合、開発者の言語を理解してニーズに関連付けることが、改訂されたデザインを正しく行うために重要になります。
方程式の反対側から同じ質問を見て、UXの実践者は、基本的なUXの概念を欠いている開発者を見つけ、それについて「心配する必要はない」と簡単に作業できると言いますか？そもそも、なぜ「なぜ」コードを書く必要があるのかについて、何の認識も知的好奇心もなく、コードだけに集中している場合、UXプロフェッショナルとしてのあなたの評価は高くなりますか？その開発者とプロジェクトに取り組むことを楽しみにしていますか？
私個人的には、ユーザー中心の共感の設計理念を拡張して、エンドユーザーだけでなく、設計のすべてのユーザー（それらを実装する必要があるユーザーを含む）を包含するようにします。その結果、私はコードについて心配しています。
実用的な例を追加するために編集されました： コンテンツアセンブリの芸術と実践：IAとCMSが出会う場所
情報アーキテクチャとコンテンツ管理が出会うあいまいな空間があります。これは、汚い取引が交渉され、理想主義と純粋さが死ぬ、神に見捨てられた裏通りです。これは、CMSの祭壇でワイヤーフレームが犠牲になった場所です。
最も一般的な死因は？コンテンツアセンブリの管理。これは、コンテンツの複数の項目をグループにまとめるという一見単純な概念です。
上で述べたように、あなたのデザインはあなたと開発者の間の会話です。これは開発者が考えていることです：
ワイヤーフレームはこれに最適です。「ここにこのメニューがあり、ここにこれらのリンクがあり、関連するコンテンツがここにあります...」などです。インフォメーションアーキテクトは、これに夢中になり、本当にそうする必要があります。
悲しいことに、私の仕事はそれらすべてを機能させることです。ワイヤーフレーム上の任意の形式のコンテンツのリストを見ると、「このCMSの機能内のその場所にそのコンテンツを表示するにはどうすればよいのか」と自動的に考えています。
プラットフォームに応じて、そのプラットフォームがコンテンツを構成するさまざまな「方法」があります。その実装を認識することは、設計に通知する必要があります。実装で何が機能し、何が機能しないかを認識していれば、デザインは実際により良くなる可能性があります。 「純粋」な設計ではないかもしれないものは、プラットフォームの実装能力の特定の弱点を回避できれば、より効果的な（「より良い」という）設計になる可能性があります。それは必然的に評判の高いデザインの機能である無形資産の1つです。
あなたはこの質問を好転させることができます。 「優れた開発者はユーザーエクスペリエンスについて知っている必要がありますか？」私たちの多くは、大いにイエスに答えると思います。開発者の同僚がUXの専門家になることを期待しないのと同じように、専門家の開発者である必要はありません。
真実は、開発に取り組むほど、使用するテクニカルメディアの制約について理解を深めることができると思います。しかし、価値ある役割は、上記で指摘された役割であり、現状に疑問を投げかけることは、これらの制約を超えてそれを実行するための有用なステップであると思います。
この関係の多くは、お互いの視点を尊重し、新しいことを学ぶためのオープン性に関係しています。
私は、最高のUXの人が実装、つまりコーディングの面での経験があると信じていますおよび同様に UX。これにより、Webブラウザー、サーバー側の言語、JavaScriptライブラリなどの制限を理解することができます。
UXデザイナは、そこにあると思う制限に縛られないことが重要ですが、完全に実装できる可能性があります。 HTML5/CSS3では、制限がほとんどなく、ほとんど何でも可能です。
私は現在、ルックアンドフィールを設計している2人のUX人がいるパイロットプロジェクトに取り組んでおり、HTML/CSSに実装するために別のプログラマーと協力しています。複雑に見えるかもしれないが実際にはそうでないものもあれば、CSSの問題のために実装するのが少し難しいと簡単に見えるものもあります。
ここでの私の経験は、UXの人々に外観を設計させ、その "実装方法"を、その方法を知っているプログラマーに任せることが最善であるということです。私は実際にそれが見栄えの良いデザインを得るために刺激的であると感じ、それを実装しようとしています。設計者が基本的なhtml/cssの知識に基づいて実装するのは簡単だと考えるものの結果である、退屈な「実装が簡単」な外観ではなく、実装したものが見栄えが良いと感じます。ユーザーエクスペリエンスとグラフィックデザインが非常に得意な人と一緒に仕事をするのが大好きなので、見栄えの良いものを実装できます。
編集：
また、設計者が要求する特定のことを達成することは技術的に困難であることを設計者にフィードバックする可能性もあります。次に、その設計機能の重要性を判断し、実装にかかる時間と労力を費やす必要があるかどうかを判断します。
答えは、優れたUX実践者のCOULDコードですが、プロジェクトにはありません。
プロジェクト中にコーディングすると、結果が変更されます。エンジニアの考え方と建築家の考え方には違いがあります。
実装が困難なユーザーに適したソリューションと、ユーザーに問題のない簡単に実装できるソリューションのどちらかを選択した場合、エンジニアは2番目を選択します。建築家が最初のものを選びます。
実装に関与している場合は、エンジニアリングの考え方が関与しています。これには、コーディングと詳細なビジュアルデザインが含まれます。
つまり、プロジェクトでコードを作成してビジュアルデザインを作成すれば、機能して問題のないものを作成できます。大丈夫というよりも良いものを望むなら、UXプラクティショナーはプロジェクトのコーディングやデザインをしてはならず、UXアーキテクトでなければなりません。
この詳細については、Alan CooperのAbout About Faceを参照してください。
これは実際にはチームと組織の規模に依存します。小規模な開発チーム内では、フロントエンドのコーディング（HTML5/CSS3）についてある程度の知識があると有益だと私は主張します。
これは、設計と開発の間の隔たりを調整するだけでなく、説教したことを実装できることは、スケーラビリティと「可能なこと」からメリットがあります。視点。ただし、美しくシンプルなソリューションを構築するという主な目的を見失わないように注意してください。
このUXマスターの記事 要約すると、これはUXデザイナーのコア機能ではありませんが、確かに「便利です」
考慮すべきもう1つの要素は、デザイナーがこれらの言語を分岐して学習する意思があることです。
実用的な意味では、（技術的または実用的な理由で）構築できないものを設計することは問題があるかもしれません。フロントエンドテクノロジーとバックエンドテクノロジーを十分に理解すると（必ずしもコードレベルの詳細からではない）、これが発生するのを防ぐのに役立ちます。設計者と開発者の間の適切なコミュニケーションプロセスも役立ちます。通常、これが同じ人物であれば、問題になる可能性は低くなります。
反対側からの別の見方：UXの専門家がいない小さなチームのプログラマーとして、私は使いやすさを理解することが非常に重要であると思っています。インターフェイスで作業するときにコードを理解することで、何が可能であるかだけでなく、何が実行可能であるかをすばやく決定できます。また、ユーザビリティを理解することで、ユーザーに「ハァッ」と言わせないソリューションを考え出すことができます。 UXの専門家がコードを理解したり、プログラマがUXを理解したりする必要はないかもしれませんが、チームの規模が縮小するにつれ、その価値はますます重要になっています。