ソフトウェアハウスでUX/UIデザイナーとして働いて1年目に学んだ11のこと

ソフトウェアハウスでUX/UIデザイナーとして最初の仕事を始めてから、実際には1年以上が経ちました。プロジェクトの種類が豊富で独立性が求められるため、UX/UI エクスペリエンスを開始するのに最適な場所ではないと考える人もいますが、私はそれほど問題はありませんでした。私はかなり大きなスタジオで建築アシスタントとして働きながら、学生団体で広報とグラフィックデザインの「フリーランス」として働いていました。

ただし、太陽と虹ばかりではありませんでした。ブランド変更を決定してから最初の仕事を始めるまでに 4 か月もかかりませんでした。その結果、そのポジションに必要なすべての領域を学習して理解することができませんでした。一般に、若手は企業内のさまざまなチーム、主にプロジェクトのビジネスおよび販売部分間の協力の重要性についてあまり教えられていません。

UX/UI デザインの最初の 1 年に私が遭遇した問題をいくつか紹介します。

1.MVPとKPI

これらは、私が最初のプロジェクトに取り組んでいるときに遭遇した、ほぼまったく異質な概念でした。確かに社内プロジェクトではありましたが、仕事内容はカジュアルで、プロジェクト参加者全員に色々なことを聞​​くことができました。そのとき、私はビジネス アナリストとそのプロジェクトにおける彼らの役割を知りました。私は製品のビジネス面について学びましたが、それはソフトウェア ハウスにおいて製品の最も重要な部分であることが判明しました。以前の業界での経験があるので、MVP や KPI は別の名前で隠れて存在していたかもしれませんが、クライアントとのワークショップでそれらを実際に判断することは、私がここで経験したことです。

2.業務要件、要件の収集、顧客への確認、確認

これがプロダクトデザイナーの仕事の最も本質的な部分だと私は考えています。会社では、私は部分的または全体的に要件を収集し、クライアントに確認する責任を負っていました。場合によっては、クライアントの構造に優しく侵入してビジネス要件を収集するビジネス アナリストと協力して行いました。この段階では、クライアントの業界とプロセスについて学び、（クライアントが知らない場合は）なぜこれを行うのかを説明し、実際に設計中の製品に関する情報を一貫して収集することが重要です。私はこれを、ユーザーストーリー、受け入れ基準、潜在的なリスクを書き留めることによって行いました。クライアントにとって、当社に注文する製品のビジュアル面はこの段階ですでに重要であるため、そのような要件を収集する最も魅力的な形式は、ミッドファイモックアップを作成することです。部分的に提案されたコンテンツを含むモックアップ。これは提示できる多くの提案のうちの 1 つであるため、このようなバージョンのプロジェクトに執着する価値はないことを覚えておくことが重要です。この段階では、情報の流れの明確さ、つまり要件がどのように収集され、クライアントによって確認されるかを確立することにも留意する必要があります。この段階を終了しないと、決定事項の変更や新しい要件の追加など、プロジェクトのスケジュールに影響を与える潜在的なリスクがあるため、開発を進めることができません。また、製品を作成し、要件を収集し、おそらくすでにドキュメントの受け入れや開発の段階に入っているのに、突然企業 (つまりユーザー) がプロセスを理解していないと宣言することもあります。

3. 時間の見積もり – 過小評価または過大評価

実際、ほとんどの時間はモックアップの作成、既存のライブラリのカスタマイズまたはカスタム ライブラリの作成、ドキュメントの作成に費やされています。初心者のデザイナーにとって、これに費やす時間を見積もるのは非常に難しいことがよくありますが、何らかの方法で見積もる必要があります。私は特定のタスクに費やす時間を過小評価したことが何度かあり、さらに過大評価したこともありますが、私の考えでは、このスキルは経験によって得られます。このような状況では、一定の時間のバッファーがあると良いです。何かを遅刻するよりも早く提供する方が常に良いです。

4. 舵、帆、船 — 自立

これまでの私の経験では、ホテルの客室や廊下の天井、いわゆる裏庭部分の設備の調整など、プロジェクトの小さな側面のみを管理する必要がありました。最初のプロジェクトに正式に割り当てられた後、UX/UI デザイナーとして、私はプロジェクト チームの唯一のデザイナーだったので、製品に対してより責任を負うことになりました。これは私にとって高貴なことであった一方で、多大な責任と会社からの信頼を得ることができました。これまでは、それが自分に合っていたのかわかりませんが、業界での経験が浅い人間として製品の全責任を負うのは時期尚早だったのかもしれません。それは私にとってかなりの試練でしたが、私の知る限り、クライアントとチームの両方が私に満足していたので、結局のところ、その瞬間はこれらのプロジェクトタスクをうまく実行できたと思います

5. UX段階でのリサーチ、あるいはそれの欠如

クライアントは多くの場合、設計段階で UX リサーチを実施する意味を知りません (知っている場合は、このような情報を持ったクライアントに対して営業部門に感謝します!)。これがソフトウェアハウスの一般的な欠点です。製品会社では、ミートアップやカンファレンスでの会話から、残念なことに、これが設計プロセスに関しても標準ではないことが明らかでした。それにもかかわらず、UX リサーチについてクライアントにプレゼンテーションを実施し、なぜそれが重要なのか、そしてそれがどれだけ時間を節約できるのかを提示することには常に価値があります。岸からの最初の例 — 私が開発していた製品のビジネス プロセスは理解するのが非常に複雑でしたが、それは私だけでなく、ユーザーもよく理解できなかったためです。クライアントと一緒に要件を収集する段階に戻り、プロセスについてさらに学習した後、再度収集し、モックアップを改善して開発を続行します。モックアップのプロトタイプを作成し、将来のユーザー (クライアントのいずれかのチームの従業員) を対象にユーザビリティ テストを実施する時間があれば、これは避けられたかもしれません。それでも、問題が明らかになったのはずっと後になってからでした。

6. ドキュメントの作成

これは実際にはクライアントが検証する必要がある作業です。UX ドキュメントの作成には、ドキュメントの準備に関する Autentika の詳細な記事 (https://autentika.pl/blog/po-owocach-uxa-poznacie-czyli-moment-przekazania-projektu-do-wdrozenia/ポーランド語で）。

作成する際にはとても役に立ちましたが、100%十分ではありませんでした。当時私が作成していた製品のプロセス図は非常に複雑だったので、ある理由からアナリストに相談し、彼らの助けを借りて、代わりに受け入れ基準を含むユースケース仕様とより詳細なプロセス要件を作成しました。もちろん、今ならそのような文書化をもう少し違う方法で行うでしょうが、その時点では、私はそれに非常に満足していました。

7. 方法論? 存在しますか?(いいえ)

ほとんどのソフトウェア ハウスは、顧客に対して個別のアプローチで反復的に作業しようとしています。このような状況では、書籍のプロセスを計画するのが困難です。特に、「時間がない」ため、またはデザイナーだけで仕事をしているため、取締役会間のリサーチがほとんど行われないためです。最終的に、設計方法論はアジャイルに基づいていますが、フレームワークは互いに非常に似ており、むしろ発見、定義、設計、開発、提供/展開の各段階に分けることができます (Double Diamond の段階を備えた拡張 5D など)。 。

8. 顧客の理解

これは、アプリケーション設計レベルでの顧客との協力の中核です。多くの場合、クライアント (特に非 IT 業界) は、プロジェクトの最初の段階では、UX とは何なのか、それが何なのか、どのような問題を解消できるのかを知りません。私の経験からの良い例は、ビジネス要件を完了するためにローファイのモックアップを提示したときです。ミーティングにはクライアントのマーケティング チームも参加していましたが、ローファイ モックアップのデザインについては非常に不確実でした。全員の意見が一致していなかったので、モックアップは機能や製品の動作方法について話し合うためだけにあるという事実を再度話しました。残念ながら、それでもマーケティング担当者がモックアップで使用されている書体についてコメントするのを止めることはできませんでしたが、プロジェクトのその時点ではアプリケーションのデザインには何の関係もありませんでした 。最終的には、このトピックはかなり早く解決され、理解されましたが、すぐには解決されなかったという事実そのものが、UX のトピックが企業内でまったく知られていないことを示しています。設計段階の最初の段階で、私たちがどのように仕事をするのか、何を提示するのか、そしてクライアントからのインプットがどの程度必要なのかについて話し合って、クライアントに短いプレゼンテーションを行うことは価値があります。そしてもちろん、なぜそれが彼にとって価値があるのか​​も。

9. 開発者との協力

多くの場合、開発者はソリューションに関して非常に優れた意見を持っており、非常に技術的かつ論理的な質問をします。これは、私にとってソリューションを考える良いトピックとなることがよくありました。ただし、ユーザーにとってはよりシンプルで、ユーザーの観点からは必ずしも良い解決策ではない場合もあります。そのため、ここでは、変更を提案する価値のあるものと、変更を中止して下された決定を説明する価値があるものとのバランスを適切にとる必要があります。

10. API、JSON、LDAP、オーケストレーター、その他の奇妙な単語

これらはアプリケーション開発の重要な概念であり、開発者と IT コミュニティ全体が使用するため、UX として知っておく必要があります。彼らのことを知れば、エンジニアともっと話せるようになります。わかりません。できれば最初に聞いてください。ただし、私にとって、これらの概念の理解は、開発者が作成していた実装ドキュメントを確認した後にのみ得られました。アプリケーションの内部通信図によって、アプリケーションの詳細についてはよく理解できるようになりました。機能しています。

11. スプリント、毎日のプロジェクト、スプリント計画、およびレトロ (仕様)での作業

これらは、プロジェクトで何が起こっているかを完全に制御できる貴重な会議です。ここではプロジェクト マネージャーが重要で、必要に応じて介入します (例: クライアントが取り決めを変更しようとしたとき)。また、アジャイルに作業している場合 (ほぼすべてのプロジェクト) のスクラム マスターも同様です。

ご覧のとおり、これは私が IT 部門に入社してから知るようになった非常に多くのことでした。興味を持っていただければ幸いです。おそらくこのリストは、UX/UI でのキャリアを検討している人や、この業界で働いている人にとっても役立つでしょう。