開発者はコードを「所有」しているので、設計者はエクスペリエンスを「所有」すべきではありませんか？
公開: 2022-03-10私たちは皆そこにいました。 あなたは何ヶ月もかけてビジネス要件を収集し、複雑なユーザージャーニーを作成し、高精度のインターフェイス要素を作成し、ユーザーの代表的なサンプルでそれらをテストしましたが、目的のエクスペリエンスにほとんど似ていない最終製品を確認しました。
組織の準備ができていないと信じていたにもかかわらず、もっと力強く、アジャイルなアプローチを主張すべきだったのではないでしょうか。 おそらく、パターンポートフォリオでより良い仕事をして、開発者がカルーセルの5つの異なるバリエーションを作成するのではなく、モジュラーコードライブラリを使用するようにする必要があります。 あるいは、開発チームの隣に毎日座って、設計したものが実際に実現することを確認する必要があるかもしれません。
SmashingMagの詳細：
- 開発者を設計プロセスに含める必要がある理由
- レスポンシブデザインにおけるチームコラボレーションとクロージング効率のギャップ
- 素敵なプレーをしているデザイナーと開発者
- 開発者と効果的にコミュニケーションする方法
代わりに、UI要素がごちゃ混ぜになっていて、すべての微妙な点が取り除かれています。 彼らは、あなたがトランジションを正しく取得するために何日も働いたのを見ることができませんでしたが、デフォルトのアニメーションライブラリにドロップするだけでしたか？ そして、その追加のチェックアウト手順はいったいどこから来たのでしょうか。 私はマーケティングが土壇場でそれを投げ込んだに違いない。 統合が難しく、妥協する必要があることはご存知でしたが、技術チームではなく、ここでユーザーの生活を楽にすることになっています。
もちろん、サイトがこのようになっている理由はたくさんあります。 プロジェクトのさまざまな部分に取り組むさまざまなレベルのスキルを持つさまざまなチーム、開発サイクルを短縮する土壇場での一連の変更、および多くの技術的課題。 それでも、開発チームが来て、UIの変更についてアドバイスを求めることができなかったのはなぜですか？ あなたは彼らのコードを台無しにしないのに、なぜ彼らはあなたのデザインを変えなければならないのですか？ 特にビジネスへの影響が大きい場合は！ あなたは角を曲がったところにいるだけで、彼らがちょうど尋ねていたら喜んで助けてくれたでしょう。
上記の話は架空のものかもしれませんが、社内であれ代理店であれ、デザイン界の隅々から聞いている感情です。 重労働の開発チームによって台無しにされた慎重に作られた経験。
この経験は、数年前に米国のローカルニュースチャンネルで見たニュース記事を思い出させます。 郡の見本市では、ピックアップトラックに手を置いた最後の人が賞を獲得する耐久コンテストが開催されていました。 デザインは「トラックに触れる」という大規模なゲームのようなものだとよく思います。コンテストの最後には、開発チームが常に鍵を持って立ち去ります。 議論の最後の言葉のように、サイトと接触する最後の人はすべての力を持っており、それがどのように機能するか、またはどのように見えるかを指示することができます。 特に、特定のターゲットエクスペリエンスが「技術的に可能」ではないと主張する場合は、「本当に難しい」、「そのようにするのは面倒ではない」、「もっと良い方法があると思う」の省略形であることがよくあります。だから、開発カードを引っ張るつもりです。」
今、私はここで開発者について不当に厳しいことを知っています、そして私はそうするつもりはありません。 本当に使いやすさを気にし、ユーザーのために最善を尽くしたいと思っている驚くほど才能のある技術者がいます。 しかし、デザインは簡単で、誰もが意見を述べることができるという信念のために、分野間に非対称のレベルの敬意があるように感じることがよくありますが、開発は難しく、特別に開始された人だけが対象です。 そのため、設計者は設計プロセスに全員を参加させることが推奨されますが（場合によっては期待されます）、同じ贅沢を与えられないことがよくあります。
正直なところ、私は彼らを責めません。 結局のところ、私は危険なほどの開発を知っているので、データベース構造とコードのパフォーマンスについての私の意見が必要な場合はばかになるでしょう（パフォーマンスは良いことだと思う以外は）。 それからまた、開発者がいつ物事を混乱させているかを知るのに十分なことを知っています。彼らが不可能だと言ったものの実用的なプロトタイプを持って戻ってくるのはいつも楽しいです。
問題は、多くの開発者がデザインに関して同じ立場にあると思います—彼らはそれを理解していないだけです。 そのため、数年前の会議で聞いたことに基づいてインターフェイス要素に変更を加えると、重要なコンテキストが不足している可能性があります。 パフォーマンスが悪いため、これはすでにテストして割引したものだったのかもしれません。 おそらく、アクセシビリティなどの特定の理由で、この要素を別の要素よりも選択しましたか？ あるいは、開発者の意見は、平均的なJoではなくスーパーユーザーとしてWebをどのように体験しているかに基づいて、間違っていたのかもしれません。
さて、ここで何かをまっすぐにしましょう。 開発者がデザインに興味を示したり、デザインプロセスに入力したりするべきではないと言っているのではありません。 私は部門の枠を超えたペアリングを固く信じており、最高のユーザビリティソリューションのいくつかは技術チームから生まれていると思います。 また、多くの分野にまたがる才能のある人々がたくさんいます。 ただし、ある時点でエクスペリエンスを所有する必要があり、HTMLファイルを開いて「トラックに触れる」最後の人がエクスペリエンスを所有する必要はないと思います。
それで、優れた設計者が優れた開発者がテーブルにもたらすスキルと経験を尊重するのであれば、少しの同等性はどうでしょうか？ 設計者が開発者に「コードを所有する」ことを喜んでいる場合は、同様の敬意を示して、設計者に「エクスペリエンスを所有する」ようにしてみませんか？
これを行うのはかなり簡単です。 何かが特定の方法で設計された理由がわからず、もっとうまくできると思う状況に陥った場合は、ただ飛び込んで変更を加えないでください。 同様に、技術的な障害にぶつかり、別の方法で何かを設計することがあなたの生活を楽にするだろうと思う場合は、設計者に相談してください。 彼らはあなたの提案した変更で完全にうまくいくかもしれません、あるいは彼らは立ち去って同じ問題を解決する他のいくつかの方法を考えたいかもしれません。
結局のところ、コラボレーションは双方向に行きます。 したがって、バージョン管理プロセスの外部で、設計者がライブサーバーでコードの「最適化」を開始したくない場合は、設計に対して同じことをやめてください。