見出し画像

モブデザイン と OOUI の素敵な出会い(デザインプロセスの話)

この記事は、株式会社アトラエ アドベントカレンダー 19日目の記事(遅刻)です。

前日の記事は、竹田の「BtoBサービスのランディングページには、NoCodeツールが欠かせない。」でした。

私はwevoxというサービスでデザイナーをしているのですが、チームでプロダクトづくりを行っていると、アウトプットと同じくらいプロセスが大事であると感じることがとても多くなりました。
特に、「なるべく早く物事をすすめる」というのと「チームで共通認識を得る」ということを同時にやらなくちゃいけないのが「チームでのプロダクトづくり」の辛いところだな、って感じですよね。そのためにはやっぱり、プロセスがとても重要になります。
今回は、そういった課題感を解消するために取り入れたモブデザインとOOUIが、コロナ禍のリモート状況で出会い、デザインプロセスとして面白い体験につながったので、その話をつらつらとできればと思います。よろしくお願いいたします。

長くなりながちなデザインづくり

画像1

いきなりの課題感ですが、みなさんどう思いますか。私はそうです。長くなりがちです。今もプロセスをクイックに回すことには苦手意識を持っています。
苦手ながらに、UIを共有→フィードバック→UIを修正→FB…というサイクルは、フィードバックとものづくりのフェーズが分離しているので、進行の速度が実はあまり早くないのでは?という仮説に気づきました。
さらに、この形は基本的にデザイナーのアウトプット主導になるので、割と一方通行なものづくりのスタイルになるなとも感じました。UIにおいてもデザイナー以外が持っているいいアイデアを素早く形にすることも、良いプロダクトを作るプロセスとして重要ではないかと感じていました。

デザインのプロセスをみんなで実行する: モブデザイン
フィードバックとものづくりのフェーズが分離している
という課題感に対し、私が実践してみたのがモブデザイン的なアプローチでした。モブデザイン自体はざっくりいうと複数の人が同時に意見を言い合いながらアウトプットを編集していくデザイン手法です。実際には、Figmaで同じ画面を見ながらフィードバックに対してリアルタイムにデザインを編集、議論を繰り返しました。実際にやってみるとフィードバックと編集と議論がしっかり直線で進むので、決まった時間の中でしっかりと結論に達しやすいと感じました。また、一つのフィードバックに対して参加者の多角的な視点でインタラクティブに発散、収束ができるので、クオリティを高める意味でも優れた点があると思います。

デザインを巡る空中戦

また、私が抱えていた別の課題感で、デザインを巡る空中戦というのがありました。みなさんがどうかはわかりませんが、私は良くしてしまう傾向にある気がします。議論をすることは好きですが、収束させるのは得意ではありません。
得意でないながら、空中戦の問題になっているのは論点と関心のズレが発生している場合が結構あるのではということに気が付きました。そしてそれはUIや実体の共通認識、共通言語ができてないことに由来するのではないかと考えるようになりました。

実体を可視化してUIに落とし込む: OOUI
上記の課題感を抱えた状況で、ここ半年で複雑な仕様の機能を実装する機会があり、これは共通理解 / 共通言語がないと空中戦で爆散するな…と思い、銀の弾丸と噂のOOUI のエッセンスをデザインプロセスに取り入れてみました。具体的にはエンジニアと相談してまず仮のER図的なものをつくり、それをもとにデザインをすすめてみました。
実体から割とロジカルにUIに落とし込めるので、その上で問題があるとすると「UIへの落とし込みが問題なのか?」「そもそも実体がおかしいのか?」など議論のポイントが以前に比べて定まりやすいなと感じました。

 モブデザインとOOUIの素敵な出会い

そして、その素敵な出会いはリモート環境でのデザイン共有で起こりました。ミーティングではFigmaの共有リンクを用いてデザイナー以外の人がデザインツールにアクセスすることが多くなり、モブデザインをしやすい機会がそもそも増えました。さらに、UIに対応するER図もFigma上に存在していたので、今度はエンジニアがミーティング中にリアルタイムに実体を調整できたりするようになりました。
実際にはUIデザインの編集とER図の編集が同時にその場で行われたりしていました。モブデザインの領域が拡張され、アジャイル開発のプロトタイプをしている感覚になりました。

画像3

共通言語を持つと、課題に対するアプローチが明確になる
このような形で共通言語の理解が進むと、OOUIなどの体系だったデザインの考え方やエンティティの捉え方がチーム全体にインストールされ、それがUIの問題なのか、実体の設定の問題なのかをチームできちんと分離して考えられるようになりました(多分)。たとえば、「なんとなく使いづらい」や「なんか複雑だな」という話も、それが「同様の実態に対して共通のアクションやUIが設定できていない」だったり、「そもそも実体の設計やその表現の仕方が複雑になっている」という言葉で表現しやすくなったと思います。
デザインの段階で実装のイメージもつきやすくなる気もしています。

画像2

デザイナーにとっても、ふりかえりのいい機会になるかも
デザイナーは自分で手を動かしてアイデアを作っていくので自分のアウトプットに強いこだわりをもってしまうことがどうしても多くなってしまいがちです。
モブデザインは、やってみるとわかるのですが、かなり集中力を使います。みんなが議論していることを把握してリアルタイムにデザインに沿って形に落とし込まなければいけません。そうなると、結構自分自身の考えをアウトプットに入れる余裕がなくなったりします。
そういったプロセスを経ることで「他の人の意見も意外と面白いな」と気づく機会も得られたりします。


 最後に

プロセスはまだまだハックできる余地があると感じました。
いろんなやり方を試してみて、じぶんなりのスタイルを見つけていきたいですね。

あと、投稿が遅れて本当にすいませんでした🙇



この記事が気に入ったらサポートをしてみませんか?