web-dev-qa-db-ja.com

リーンUXとは何ですか？どこで詳細を確認できますか？

Lean UXと呼ばれる新しいトレンドがあり、これは明らかにLean Start-upアプローチに由来します。その主な原則は何ですか？それについて学ぶための良いまたは推奨される参照、情報源、または教育は何ですか？

design-processlean-ux
27
Dvir Adler

個人的に言えば、リーンUXはUX戦略の一種ではなく、基本的なUXの原則に対応するビジネス戦略に似ています。 UXデザインでは、デザイン->プロトタイプ->検証をそのまま行いますが、これを組織内の他の開発ユニットと同期して行うと、無駄がなくなりますUX。

とにかく、ここにいくつかのリンク/本/あなたが持っているものがあります。

リーンUXモデル：

enter image description here

原則：

  • 設計+製品管理+開発= 1チーム
  • 外部化！
  • 目標主導＆結果重視
  • 再現性とルーチン化
  • フロー：考える->作成->チェック
  • 適切な問題の解決に集中する
  • 多くのオプションを生成する
  • 何を追求し、何を保持するかをすばやく決定する
  • 仮説を認識して検証する
  • ユーザーとの調査は、情報とインスピレーションの最高の情報源です
26
rk.

この概念については、もっと明確にする必要があると思います。これまでのコメントのいくつかを読んでも、アジャイル内のUXがリーンUXと同等であると混乱します。主題に関するほとんどのコンテンツで実際に対処されていないギャップがあります。そしてそれは、それが一般的な課題であり、魔法の答えが1つあるかどうかわからないからだと思います。

リーンUXは、Jeff Gothelfによって説明されているように、アジャイルUXの問題に対する1つの解決策です。これは必ずしも「アジャイルUX」に対する最終的な回答ではなく、「アジャイルUX」そのものではありません。前述のリーンスタートアップコンセプトに基づいて開発されましたが、アジャイルに基づいていません。

これは重要な違いだと思います。このテーマに関する多くの記事では、リーンUXがアジャイルの質問内のUXに対する非常に明確な答えのように見えるためです。リーンUXをやっているので、どういうわけかこれをすべて管理する方法を知っていると思われることを私が見ると、私はちょっと混乱します。多分それは私だけかもしれませんが、それはそのようではありません。

Gothelfでさえ、彼のプレゼンテーションや執筆のいずれにおいても2つを同一視しているようには見えません。彼はアジャイル内でリーンUXについてプレゼンテーションを行いますが、それはまったく別の獣です。あなたは確かにリーンUXの原則を採用していますが、直面する新しい課題と回答する新しい質問があります。

リーンUXの概念とリーンUXの概念をアジャイル内で分離する必要があります。リーンUX自体は、開発プロセスに関係なく使用できる個別の方法です。アジャイルに役立ちますか？もちろん。しかし、それは私にとって追加のトピックです。

アジャイル内のリーンUXは完全に別の状況であり、私がよくカバーしていないと思う状況もしばしばあります。アジャイルのタイトな開発反復の制約の中で突然UXを実行する方法についての主要な手がかりを与えるこのトピックについて一般的に提供されているグラフや記事には、たとえあったとしてもほとんどありません。

リーンUXをアジャイルに統合して、ある種の新しいハイブリッドアジャイルUX方法論を考案するという課題はまだ残っています。私の意見では、2人を平等にすると混乱を招くだけのようです。多くの記事は、たとえそうだとしても、その平凡さのギャップにのみ触れています。これのリーンUXとアジャイルUXの間に残るギャップに対処する方法はあると思います（開発者やQAメンバーのようにチームでUXを等しくする-おそらく、他の作業と同じように、その作業をポイントに含める必要があります）。しかし、それは一種の追加概念です。

リーンUXについては、まったく反対です。リーンUXを採用し、開発者とQAを備えたアジャイルに明確かつ簡単に組み込むことができると想定する場合は注意が必要だと思います。それほど簡単ではありません。ただし、リーンUXは、アジャイルに似ている（したがってより適している）考え方とアプローチを形成しており、一般的にはそれが適切な方法だと思います。

私はリーンUXを全般的に成功させ、大きな成功を収めてきたチームで働いてきました。しかし、私たちは常に開発の先を行っていました。また、同じ2週間のイテレーションでチームと一緒に設計および開発したイテレーションも試してみました。これはまったく異なるシナリオです。リーンUXの原則は両方の状況で使用されましたが、私はそれらを「同じ」と呼ぶことはありませんでした。

そのすべてを超えて、私はあなたのUXチームにとって一般的にリーンUXを支持することを強く主張します。それは単なる「流行語」ではなく、その教義には実際の実用的な目的があります。

私の最後の仕事では、ビジネスニーズを取り入れ、ユーザーと状況を問い合せ、必要なペルソナを形成し、ユーザーが実際にやりたいことを実現する現実的なタスクを書くことができるプロジェクトがありました。その過程で、開発者、ビジネス、マーケティングに参加させ、テストに参加させ、取得した情報に没頭させました。次に、これらのタスクを中心に紙のプロトタイプを作成し、実際のユーザーを使用してこれらのデザインをテストしました。そして、それが紙だったので、私たちはテスト間を繰り返していました-時にはテスト中ですら。

タスクアプローチは良いものです。なぜなら、次の一連のタスクに取り掛かっている間に、開発に移すことができるサイトのチャンクを使い果たしたからです。他の場所では違ったやり方をしていると思いますが、これは私たち全体としてはかなりうまくいきました。

私たちは「垣根を越えて」という考え方を排除し、開発に至る前に製品を常に改善していました。そして（最も重要なことに）関係者全員が、ユーザーが必要としているものとそのニーズへの取り組み方について共有された理解を持っていました。ウォーターフォールプロジェクトでよく見られるように、これをすべて直線的に行うと、そのすべてが減少します。

9
softserve

私は2年前にLuxrコースを受講しました-彼らのブログは素晴らしいリソースです http://blog.luxr.co/

enter image description here

1
Max