製品設計者：操作規則

デザイナーは進化を続けています。



幅が広く、空に向かって、さらには横に。



以前は自分をデザイナーと呼んで「フォトショップ」という言葉をためらうことなく発音することを学ぶだけで十分だったとしたら、今ではこれらのスキルだけではまともな仕事を見つけるのに十分ではないことは明らかです。



かなり新しい方向のデザイナーのタイプの1つは食料品です。記事では彼についても話したいと思います。



私は理論と実践にぶつかります。



理論的には、彼が誰であり、彼らが彼に何を望んでいるのかを理解したいと思います。



実際には、まさにその製品に対するこのデザイナーの作業プロセスを説明してください。



行く！

パート1。理論的。

誰が、いくらかかり、何が期待されるか

それで、私の手紙の最初の行で、親愛なる聴衆、私はまだそのような「製品デザイナー」がどんな種類の動物であるか、そして会社が彼らの輝かしいものを受け入れて彼に何を望んでいるかを説明したいと思います。



まず、まさにこの製品設計を教えるコースに目を向けました。



これがコースの内容です。



Netologyは12万の給与を約束します。ルーブル

「UX / UIデザイナー、製品デザイナーは、成長と高給の機会が十分にある、最も要求の厳しいデジタルプロフェッショナルの1つです。

分析と創造性、エンジニアリングアプローチ、および非標準ソリューションを組み合わせています。デザイナーの有能な仕事は、クライアントの利益を増やし、製品とのユーザーの相互作用を改善します。」

スキルボックスは8万の給与で誘惑します。

「製品設計者は、アイデアから市場投入まで、製品の作成と開発を担当します。

ビジネス戦略を通して考える方法、ITチームと協力する方法、研究を実施する方法、および設計システムを設計する方法を学びます。」

Bangbangeducationは金銭的な賞について適度に沈黙しています。

« , , , . . . , -. , . — .»

一般的に、説明のすべてがかなりぼやけています。



それでは、hh.ruを見て、雇用主が製品デザイナーと呼ばれる人物に実際に何を期待しているかを見てみましょう。



私は不器用で飾り気のない行動をしました。検索ボックスに「ProductDesigner」と入力し、頻繁に発生する要件を書き留めました。



ホステスへの注意：欠員では、給与のレベルが示されていないことが多いため、実際の状況を理解するのは非常に困難です。



しかし、私は10万人からの給料の約束と期待を悲しむことができます。

たくさん欲しいが、お金を払う準備が全くできていない会社もあります。



さて、彼らは一般的な要件に従って今運転しました：

• デザインなどのプログラム（Sketch、Zeplin、Figma、InVision、Adobe Photoshopなど）の経験。
• web, iOS Android ( , , );
• ;
• . , , , . , , , , ;
• . , , , , . , ;
• ux- — , , ;
• , ;
• . ;
• - , ;
• - ( : , , );
• , ux ;
• . , , ;
• frontend , . frontend , , , ; , - front ;
  
  , . ;

そして、ささいなことについて：あなたの仕事を提示するスキル、開発者と合理的に議論する能力、自己組織化、マルチタスクなど。



一般的に、要件は非常に広範囲です。どこかもっと、どこか少ない。

うまくいけば、主な方向性は明確です。



製品設計者は、理想的には、設計者、インターフェース設計者、ビジネスアナリスト、研究者、講演者、創造的な論理学者、そして一般的に幅広い魂と強力な展望を持つ素晴らしい人物を組み合わせる必要があります。







実際、すべてが人によって異なります。



しかし、私は確かに手ごわい要件のいくつかの部分を知っています。それがなければ、あなたは決して仕事を引っ張ることができません、実際、不必要であるか、非常に少量であることがわかります。



しかし、これは私の個人的な経験です。多分誰かがそのように全くそうではありません。



このような状況の理由はごくありふれたものです。研究、テスト、その他のがらくたでこれらすべてのsushu-pusuを行うのに十分な時間がないだけです。結婚は耐えられず、党はそれが必要だと言ったので、私たちはそう言った。



そして、あなたがスイス人、刈り取り人、そしてギャンブラーである場合、もちろん、1人の大きな製品デザイナーから小さなuxとuiのデザイナー、ux研究者、コピー家、アーティスト、アナリストの束に分かれる力はありません。 ..。ちなみに、時間も。しかし、ここでも、すべてが時間、複雑さ、その他の天体に依存しています。



正直なところ、いつかマンオーケストラが終わり、1人の製品デザイナーが別々の専門分野に分かれると思います。負荷がかなり高く、考え方も人それぞれ違うからです。



レイアウトデザイナーの話のようなものです。



理論的には良さそうです。実際には、高品質のデザインを最初から作成したり、その逆を行ったりできるレイアウトデザイナーは1人もいません。おそらく私は見栄えが悪かったか、私のビジョンが私を失敗させています。



しかし、その間、私は座って、足をぶら下げ、人生について不平を言い、自分自身を製品デザイナーと呼んでいます。後でそれが耐え難いほど苦痛にならないように、プロセスを構築した方法の私の経験を共有したいと思い



ます...あなたはまだそれをしなければならないからです。



さて、どうやって？



まず、時間をかけて製品に取り組むプロセスを構築します。これにより、発売後、ユーザーの幸せな笑い声の代わりに、彼が選んだ相手の声が聞こえることに気づき、神経質に陥ることがありません。まあ、それはあなたの方向に目を細めるのは良くないので、再び開発されました。

二部。実用的。

真のイベントに基づいています。

すべてのプロジェクトで、意図したとおりに実行できたとは言えません。しかし、それがうまくいったとき、私の伝記には明るい点がありました。



そして、私の話はこれらの輝点についてです。



ここで、私が過去4年間、ゼロからプロジェクトを開発してきたという事実に特に注意を払う価値があります。したがって、プロセスの説明はそれらに関係します。しかし、このプロセスは既製の製品に適用できるとのことです。



はい、この記事では、まったく新しい機能を開発して起動するプロセスについてのみ触れます。後で仮説を立てたり、フィードバックを収集したりすることについては、そうでなければたくさんのことがあります。



そう…

顧客からの要件の収集

要件は、プロダクトオーナー、顧客、またはその他の責任者から収集できます。



この段階で、それが現在どのように機能し、担当者がどのように見ているかを理解することが重要です。そして今ここだけでなく、将来へのギャップもあります。

結局のところ、全体像をバラバラではなく全体的に見ると、さらなるスケーリングと洗練のための基礎を築くことが常に簡単になります。



要件は慎重に収集する必要があり、白い点が1つも残らないようにします。



良いニュースは、ビジネスアナリストがこれを行う必要があるということです。私はそれを見つけ、書き留め、持ってきて、「スマック」を作り、ペンをさようならと振った。



しかし、私のベルトの下で壊れた電話の苦い経験で、私は製品設計者がそれをするべきであると確信しています。まあ、または要件のコレクションに存在します。



アナリストにとってそれほど重要ではないものがありますが、インターフェースを設計するとき、それらなしでは何もありません。したがって、彼自身と彼だけ、まあ、または彼の隣に、ノートブック、ペン、ボイスレコーダーを備えた茂みの中のピアノのように。



ちなみに、ディクタフォンについては別に言いたいのですが、仕事で使わないのなら使い始めてください。この機能は恥ずべきことに便利です。会話全体が録音されていることがわかっている場合は、途中で注意を失ったり、録音に気を取られたりすることなく、会話に集中できます。

ユーザーからの要件の収集

これはコインの反対側です。



これで、上部でどのように機能するかを理解できました。次に、さらに深く掘り下げる必要があります。トップスだけでなく、ルーツも知っている人の方向に掘り下げる必要があります。



座って、彼がすでに持っているものとどのように連携するかを見てください。



何があなたに合っているか、何が合わないかを尋ねます。そして、私たちが望むように。特定の行動をとったり、決定を下したりするときに重要なこと。



まだ行われていないことをしても、どういうわけかこれらの問題を解決します。



両方向に棒で突いたので、あなたはすでにあなたが働くことができる多かれ少なかれ理解できる絵を持っています。



もう1つの重要なことは、それがどのように機能し、何が悪いのかということです。専門家からではなく、エンドユーザーから学ぶ方がよいでしょう。専門家は過ぎ去った日々の理論や記憶しか持っていないかもしれませんが、エンドユーザーは実際の練習、痛み、涙を持っているからです。



なぜ私はこれに注意を払っているのですか？繰り返しになりますが、練習からぶつかるからです。私は専門家から問題を収集し、卒業して、問題を解決するという形で彼らに降りかかった幸せに対してエンドユーザーがどれほど幸せであるかを見に行きました。



そして突然、突然、いくつかの問題は有効ではないことが判明しました、いくつかはここで発生せず、現時点では発生しませんが、いくつかは一般的に奇妙に聞こえ、貧弱です、それをどうするか。要するに、彼らはそれを悪化させただけでしたが、おかげで、私たちは決めました。

ユーザーパス図

この部分は、CJMまたは他の何かと呼ぶことができます。



その本質は、受け取った知識の山の後で、今回はさらなる作業のために、この山をある種の肥料に変える必要があるという事実にあります。 2-すべてが理解され、考慮され、犠牲者の言葉から正しく書き留められているかどうかを判断する。



私は今、新製品の開発について話していることを思い出させてください。どうやってやったのか。おそらく、誰かがそれを別の方法で行うか、まったく行わないのでしょう。



そして、ポイントAからB、BからCなどの機能を使用して、使用するユーザーパス全体を取得してレイアウトしました。



まだ存在しないことをしなければならないことが多かったので、本当の問題や喜びなどを伝えることができませんでした。



理論的には、彼らが悪の暗黒面に転向したり、間違った方向に進んだりするリスクがあるかもしれないと私は考えました。



問題、解決策、ブランチなどの可能なオプションを使用して各ステップを検討すると、自分が何をしようとしているのかを自分で理解しているかどうかを簡単に確認できます（はい、この段階でも、すべての会話の後、茂みの中で未知のピアノに出くわしてから、他の何かを明確にするため）。ボタン、情報、写真、猫の形で、将来の戦闘機にどのような武器を提供しますか？



赤ちゃんの涙のように、パス全体が明確になったら、すでにプロトタイプを開始できます。

プロトタイプ1：紙

わかりません。この手順は必須ではないかもしれませんが、私はいつもそうしています。ボタンやグラデーションの美しさに気を取られることなく、ソリューションをすばやくスキミングして修正するのに役立ちます。



論文を一列に並べて、将来の製品の論理と明快さを評価することができます。



たとえば、紙に、考える必要のあるいくつかのポイントを書き留めたり、開発で明確にする必要のある新たな質問をすぐに書き留めたりすることもできます。

プロトタイプ2：動的

私はAxureでそれをします。



正直なところ、他のプログラムで試してみましたが、特に画面数が多い場合は不便です。



動的なプロトタイプは、テスト時にすべてが正常に進行していることとユーザーを示すために必要です。



直接デザインしているとは言いませんが、重要なアクセントや色をいくつか使っています。

プロトタイプテスト

プロトタイプを使用してスクリプトを実行すると、目的の場所に確実に到達するのに役立ちます。または多分彼らは得たが、そこにはなかった。あるいは、まったくヒットしなかったのかもしれません。



いずれにせよ、プロトタイプは、本番環境で発売された製品よりも簡単にすべての編集を転送します。



特定のシナリオ、ユーザーがシンボルの意味をどの程度理解しているか、情報を提示するのが便利かどうかなどに従って、通過をテストします。



すべてが順調に進んでいるとは言えません。



ちょうど来て、仕事の結果を見せてくれる時間制限もありました。見てください：あなたは尋ねました、そしてこれは私たちがしたことです。次に、座ってフィードバックを聞きます。



このアプローチのイチジクがうまくいくと初めて思ったが、そうではなかった。エラー、理解できない、物議を醸す瞬間がまだ見つかりました。



したがって、「話す」時間を割り当てることが不可能な場合は、ショーに限定してフィードバックを収集することができると結論付けました。



何もないよりは間違いなく良いです。

プロトタイプ開発を表示

一般的に、そのような焦点が常に得られるとは限りませんが、双方の時間を見つけることが重要だと思います。



多くの場合、時間が限られている場合、品質を損なうことなく何かを単純化することができます。

開発者が後でより簡単に生活できるように、作業のロジックのより詳細な説明が必要になる場所に注意することもできます。

タダム！ホームストレッチ：デザイン

特別なことは何もありません。あなたは座ってプログラムを開き、前のシリーズで取り組んだことをうまく描くかどうかにかかわらず、描き始めます。



時間は許します-あなたはリソースについて視覚的および他のインスピレーションを得るために行きます、それらの名前は最近しばしば嫌われているので発音できません。

開発への移行

以前、シナリオをユーザーストーリー形式で説明しました。



こんな感じ でした：

私、好き…、欲しい…

さらに、機能自体、ユーザーによるアクション、追加機能などが説明されていたの



ですが、たまにたくさん出て、誰も読みたくないことがわかったので、プロトタイプ自体にメモを入れてレイアウトしました。 miroでは、すでに設計された画面を使用します。



開発者がこのように作業する方がはるかに便利であることが判明しました。



彼らは一度にすべてを見て、何かを忘れないように質問したり、ステッカーを貼ったりすることができます。

実際、これが、製品設計者がタスクをどのように処理するかについて私が伝えたかったことのほとんどすべてです。

結論

これが私のビジョンであり、私の経験であることを繰り返します。



各ステップは、それをうまく機能させるために重要です。そして、各ステップには時間がかかります。



だからこそ、製品デザイナーの立場が長く続くという話を信じていないのかもしれません。まあ、誰もが時間の袋を持っているか、何かがそれほど慎重に解決されないでしょう。



製品設計者の作業プロセスの構築、責任、能力についてのご意見をお聞かせください。



この職業は将来的に関連するのでしょうか、それとも最終的には個々の狭い専門家に崩壊するのでしょうか？