エンジニアがUXを一年勉強してみて
一年間一通り勉強してみて輪郭が見えてきたので、今年はUXをお休みして技術の方に振り切ろうと思い、考えたことを書いてみようと思いました。
勉強したきっかけ
「説得できる武器」がほしかったからです。過去に、事業的に長年改善できなかったけれどユーザーにとって課題となっている点があるとき、案を出してもなかなか通らず、ユーザーのことを思うと悔しかったことが何度もあります。そのときにきちんと説得できるように、また改善した結果を示せるように学ぼうと思いました。
UX施策の結果を表すこと、時間がない中リソースを確保することって非常に難しいなと思います。
ちなみに過去記事はこちら
めっちゃUIの話をされる
UXに興味があるというと必ずどこでも、
「デザイナーの分野でしょ?」「エンジニアといってもフロントエンドの話でしょ?」「ああ、(UIの分野のこと)ね!」
とものすご〜〜〜〜〜〜〜〜〜〜く言われました。「UX(ユーザー体験)」という言葉が指す範囲が広すぎるためですね。
UXの定義の話はchachakiさんの勉強会に出たときが一番勉強になったのですが詳しくは下記です。多くはユーザービリティに近しい分野でUXを捉えられがちなのですが、「ユーザー体験はユーザーの内的動機、ユーザビリティと品質は製品のパラメーター」という言葉がとてもしっくりきました。
(chachakiさんの勉強会は非常に濃かったので別でnoteまとめたいとずっと思ってるおりいずれ書きます)
UXデザインって何?の図!!#HCD_Chachaki pic.twitter.com/5WgeOeTw4F
— まなみん (@manamin0521m) November 16, 2019
ユーザー体験は”ユーザー”の内的動機だけど
— まなみん (@manamin0521m) November 16, 2019
ユーザービリティと品質は"製品"のパラメーター
UXデザインはプロセスでしかなく
HCDは規格化されているもの
今までそれぞれ混同しがちだったけどとてもしっくりきました! #HCD
UXというと一時的UXのみについて語られがちだけどホントはこれらすべて #HCD pic.twitter.com/fL5IbXMEhB
— まなみん (@manamin0521m) November 16, 2019
そのためUIよりは上位の概念で、(実装関係ない)仮説の検証と(MVP作成など)ソリューションの検証のうち、仮説の検証の部分やMVPの作成でエンジニアも関わっていけるのでは?と思いました。
またUXの勉強会に複数出てみて学んだのが、UXは職種限らず組織で行うべきということです。UXを深くやっている人ほどエンジニアの参加に肯定的でした。ファシリテーターはUXに詳しい人がやるとして、アイディアの発散やユーザーの課題の理解は複数の視点からやるほうが望ましいといった内容も本に書かれていました。
また複数参加して、UIデザインはわからないけれどUXデザイナーをしている、というエンジニア出身の方にも多く話を聞けたのもよかったです。
結局UX改善の指標って何?
これが一番学びたかったことなのですが、ユーザーテスト(ユーザビリティテスト)での前後の比較が一番いい指標でした。操作までに何秒かかった、この操作が完了できなかったけどこの操作は完了できた。は定量データがとれます。ISO(国際標準化機構)におけるユーザビリティの定義である、効果、効率、満足度にしたがってユーザビリティテストをしましょう。
これに関してはユーザビリティエンジニアリングという本が非常に勉強になりました。
劣化コピーになりがち
数件ユーザーインタビューやユーザーテストをさせてもらって、たしかに課題解決の手段としてUIでの解決を選ぶことが多かったです。ただそういうときは特定の分野に限っている狭めのスコープなこと、またユーザーが出したソリューションをそのまま実行する場合でした。
また、現状エンジニアが企画を少しだけさせてもらう際にはすでに要件が決まっていてほんの少しだけ改善案を出せる場合が多く、そうなるとUI改善しかしにくいかなと思いました。
UXを勉強したものの、上記の状況の中なんとか実践しようとすると単純にサーバーサイドの実装時間も減るし、UIデザインや企画の知識もなく、PdMやデザイナーの劣化コピーになりがちだなと。そうなるとエンジニアの評価基準では成果を出しにくく、がんばってもうまくいかなくなります。
一方、サーバーサイドエンジニアだって設計や実装がんばったものが、使いにくいと言われたり、あんまり使われなかったら悲しいじゃないですか...。自分の直接の担当分野じゃないとしてもその気持ちはどこに向けたらいいんでしょう?
そこでUX本を一人でなぞるとそうなるので、UXを組織でやっていくことを今後目指すとして、UXを推進していくこととUX分野でサーバーサイドエンジニアだから出せるバリューに集中したほうがいいのではと考えました。
そうなるともっとサーバーサイドエンジニアとしての本業を勉強して、発言力や影響力があるようにならないと推進していくことも難しいし、もっと手前のフェーズから企画に関わることも難しいし、サーバーサイドエンジニアだから出せるバリューは設計面を詳しく学ばないと難しいなと思いました。
サーバーサイドエンジニアだから出せるバリュー
UXエンジニアの勉強会にも参加したのですが、プロトタイプ作成の話とDX改善の話が非常に多かったです。そのため、フロントエンドエンジニアの方が非常に多かったです。なので直接的にサーバーサイドエンジニアが既存のUXエンジニアの文脈で関わるのは難しそうだなと思いました。(DXに関しては不勉強でそこまでUXとの関連性が見えておらず、、、)
そこでまたサーバーサイドエンジニアでもあるchachakiさんの勉強会にて学んだことになるのですが、ユーザビリティテストなどで見えてきたドメインを実装に落とし込むDDDはサーバーサイドエンジニアとしてUXに関わっていけそうだなと思いました。
サーバーサイドエンジニアがUXの文脈にどう関わるかはDDDの要素がとても大きそうだなと思ったのと、関連してDX的面も大きいように感じました #HCD_Chachaki
— まなみん (@manamin0521m) November 16, 2019
また、カスタマージャーニーマップではなく、サービスの動きを考える上ではサービスブループリントなどを使うとよいとのことでこれも関わっていけそうだなと思いました。
サービス側でバックエンドとフロントエンドがどう動くかを考えたいときはサービスブループリントがおすすめ
— まなみん (@manamin0521m) November 16, 2019
カスタマージャーニーマップは、サービスの動きが入っていないし、ユーザー複数いるとややこしくなる(売り手と買い手など) #HCD_Chachaki
学んできたことも梃として活かせるように、今年度はサーバーサイドエンジニアをよりがんばっていこうと思います。
以上です!!
いいなと思ったら応援しよう!
![manamin](https://assets.st-note.com/production/uploads/images/7050932/profile_63bfe9c49cc0d2c388ab8498959f85e5.jpg?width=600&crop=1:1,smart)