オブジェクトモデリング入門編!SmartHRでOOUIワークショップを開催しました

先日、GoodpatchはSmartHRさんのオフィスでワークショップを開催しました!
OOUIの基礎知識をインプットできる座学、オブジェクトモデリングワークショップをUIデザイナー、PMの皆さんに体験していただきました。本記事では開催の背景から当日の様子をご紹介します。

今回ワークショップを実施したSmartHRさんが提供するクラウド人事労務ソフト「SmartHR」のUIデザインは、2018年9月まで1人のデザイナーによって作られていました。デザイナーやプロダクトの機能が増えるにつれて、様々な課題が出てきたそうです。その一つとしてUIデザイナー佐々木さんのnoteにはこのように綴られています。

現在のSmartHRでは情報の見せ方がタスクベースであることに引っ張られてしまったことで、同じオブジェクトであるはずのものが画面によって名称が別のものになってしまったり、正しく定義できていないなどの問題が散見されています。

今後の幅広いユーザーニーズに応えるためにも、情報設計の再定義やOOUIに基づいたUI設計などプロダクトの根本をデザインし直す業務に取り掛かることで上記の問題を改善していかなければいきません。

このような設計に関する課題と同時に、プロダクトマネージャーの中村さんが下記のようなコミュニケーションの課題も感じていたことからGoodpatchにワークショップを依頼していただきました。

SmartHRではPMがPRD(製品要求仕様書)やワイヤーフレームを書いてUIデザイナーに渡してデザインしてもらうことが多いのですが、プロセスが分断されている感じがしていました。

UIデザイナーにPRD及びワイヤーフレームなどの構造のフェーズで適切に評価してもらえればプロダクトは早い段階でもっと良くなるはず。

しかし、どういった手法や考え方でデザイナーとコミュニケーションを取るべきかなのか。この辺りは長らくソフトウェアデザインに関わってきた方々に一度話を聞いてみようというのが今回のワークショップを依頼した理由になります。

SmartHRさんのオフィスで開催

ワークショップはSmartHRさんのスペースをお借りして、前後半に分けて実施しました。前半の講義を中心に、当日のワークショップの内容をご紹介します。

講義:OOUIの捉え方

前半はソフトウェアデザイナーの丸から講義形式で、ソフトウェアやOOUIの捉え方についてお話しさせていただきました。

デザインの考え方では、物事を多角的に捉えることが必要です。
ここで、UXという言葉について考えてみましょう。ソフトウェアデザインの観点で見直してみると、実はこのように何らかの言い換えであることが多いことがわかります。

UXという言葉を例にとってみても様々な解釈があるため、本来の表現で会話することで、チーム全員の認識を揃えることができ、同じ目当てを見据えながらデザインと向き合うことができるのではないでしょうか。

また、丸は「UXとは感情に起因する何かであり、ヒトの心の中で起こる現象なので、UXデザインとは『ヒトに良い感情をもたらすための視点』ぐらいに捉えるといいのではないでしょうか」という解釈も語っていました。

ユーザーとソフトウェアの関係は、このように表すことができます。右側にある黒いボックスがいわゆる「オブジェクト」と呼ばれるもので、どのように捉えるかが今回のワークショップの趣旨でした。

俗に言うユーザー中心のデザインとは「ユーザーがどのように感じ経験するのかを志向する」ことであり、今回ワークショップを通じて学ぶオブジェクト中心のデザインが目指すところは、客体(オブジェクト)がどのような姿であるのか志向するデザインであると言えます。

「視点は異なりますが、どちらもインターフェイスのそばで起こる現象を捉えるデザインで、目指すところは同じ。デザインの視点が異なるだけ、と覚えてもらえればと思います。」

オブジェクト中心のデザインの目当て

オブジェクト指向、Object-Orientedについて調べてみると、「ソフトウェア工学における設計論のひとつ」とあります。

ヒューメイン・インタフェース」を参照してみると、オブジェクト起点のユーザーインターフェイスとは、まず「名詞=オブジェクト」を捉えてから、次に「動詞=それに対して何をするか」という一連のインタラクションを意識することで、次のメリットが見えてくると書かれています。

  • 操作の間違いを削減できる
  • 操作を迅速に実行することができる
  • 操作の可逆性が向上する

これらの解釈をもう少し進めると、「OOUIの目当てとは、インターフェイスの界隈で起こるインタラクションをモードレスに保つこと」と、言うことができそうです。

OOUIの思想

OOUIの目当てを理解した次は、モードレスインタラクションとはどういうことであるのか、丸から4つの観点で解説がありました。

操作順序

モードレスインタラクションにおいては「まず名詞を選択してから、次に動詞を実行する」形式が基本となります。

表現方法

ユーザーからは、まずオブジェクトが見えるようにしましょう。モードレスなインタラクションとは、ユーザーが自分の意思でオブジェクトを選ぶことができ、自由に命令を実行することができる、この環境が保たれていることが重要です。

方向転換

ヒトは優柔不断な生物で、思考が流動的です。行動の目的が常に切り替わっているので、ユーザーの思考の方向転換が起こり得ることを前提に、UIがその優柔不断さを受け入れやすくする仕組みを用意してあげることが重要です。

ここで丸からは、

UI設計においてしばしば作られる画面遷移図や操作フローの類では、何かしらの「流れ」が線形で描かれますが、実際のユーザーはその線に沿って一方的に「流れる」わけではありません。このような設計図は、デザイナーが考える「ユーザーが最も理想的な操作をした前提」で表されるものなので、ユーザーの戸惑いや取り消した操作などは基本的に考慮されません。

という補足説明がありました。実際に使われるUIを想定するならば、方向転換する可能性を十分に考慮する必要がありそうですね。

取り消し

ヒトは間違える生き物でもあるので、道具を安心して使えるように設計することも重要です。モードレスなインタラクションとは、操作が可逆的で、実行した結果を常にユーザーの意思で元に戻せること。その前提に立ちながら、間違っても取り消しが効くこと、やり直せること、安心感を与えられる表現を目指すと良いでしょう。

ソフトウェア設計において、はじめから理想形が出来上がることはそうありません。「組み立てたものをプロトタイピングしながら、作っては壊すを繰り返すことにより基盤を構築し、その土台の上でも試行錯誤をして形を作り上げてゆくのがデザイナーの役割ではないか」と語られました。

今の時代、プロダクト開発では不確実性の懸念は避けて通れないため、設計の手戻りを受け入れなくてはなりません。構造基盤を保った上で、ユースケースに基づく機能やインタラクションといったものを自然に拡張できる設計を目指すことが重要ではないでしょうか。

UIモデリング

ここから、いよいよワークの内容に近づいてきました!UIのモデル図を描いてビジュアル設計につなげるまでの設計作業「UIモデリング」について解説させていただきました。

「Designing for the User with OVID. IBM 1998」では、ソフトウェアのデザインの主要な3つの観点として次の図のような三角形のモデルを示しています。

デザインを「視覚表現に関する設計」と捉えている方はまだまだ多い印象ですが、ソフトウェアデザインに関して言うならば、視覚表現に当たる設計作業は全体のほんの10%に過ぎないということです。対してモデリングに関する設計作業は全体の60%を占めています。それだけ構造設計段階が重要であることが、この図から読み取ることができるでしょう。

「大切なのは、オブジェクトの姿を表すモデルを、適切な方法によりユーザーに届けてあげることであり、これにはインタラクション設計によって両者をつなげることが重要なのだろうと考えられます」と丸が語ったように、視覚表現がいくら美しくてもインタラクションに関する技術の選定や設計そのものが間違っていたら、オブジェクトとユーザーの対話=インタラクションがうまく機能しないと考えることができます。

機能しているUIからオブジェクトモデルを描き出す「リバースモデリング」

すでに機能しているUIの見た目からオブジェクトモデルを描き出す手法を、Goodpatchでは「リバースモデリング」と呼んでいます。

リバースモデリングによって導き出されたモデル図が実際の形であるとは保障されませんが、おおよそのUI構造は探り当てることができます。このプロセスを経ることにより、既存のUIに関して表層から構造段階まで俯瞰して眺めることができ、構造の拡張性を考慮しながら将来のUI設計と向き合うことができます。リバースモデリングの事例について、詳しくはこちらの記事をご覧ください。

OOUI視点で、iOS写真アプリを分析・考察してみた

今回UIモデリングの設計言語として採用している「UIクラス図」は、Goodpatchで独自に定めたものになります。UMLのクラス図の記法をほぼそのまま引用していますが、「ユーザーがUIで触れるだろう〈オブジェクト〉についての構造を表す」目的を明らかにするために、あえて「UIクラス図」と呼び方を変えています。また、今回例題で使ったUIクラス図はプロパティと関連のみで、挙動に関する記述は省略しています。

ワークショップ:UIクラス図を描いてみる

前半の講義を挟んで、後半からはUIクラス図の設計ワークショップを行いました。
UXデザイナー 神がファシリテーターを担当し、UIデザイナー1名とPM1名のペアでワークに取り組んでいただきました!

お題となるツールが機能拡張したとき、ソフトウェアに現れるオブジェクトがどのように変化するかを考えながら、皆さんにUIクラス図を設計していただきました。

今回のお題:タスク管理ツール

多くの方々に馴染みのある「タスク管理ツール」を題材に、その設計にすこしずつ要求が足されていくことを想定したワークを実施。各お題ごとに、Goodpatchが考えた回答例と解説を交えて、UIクラス図のつくり方をソフトウェアデザイナー丸、UXデザイナー神、デザイナー蔡からレクチャーさせていただきました。

冒頭では、みなさん初めての作業に悩まれていた様子。

ですが徐々にコツを掴み、テーブルごとの議論も活発になっていきました!

ワークの最後は、ペアごとに描いたUIクラス図を発表いただき、丸と神がレビューをさせていただきました。それぞれが悩んだポイントが業務とリンクしていたりと、議論が盛り上がった時間となりました。

参加された皆さんの声

最後に、SmartHRさんからいただいた感想をご紹介します!

「モードレス」を目指す意義が明確になったように思います。

知っていることもあったし似たような図もありましたが、ここまで体系的に聞いたのは初めてだったので学びがありました。

実際に手を動かして考えると業務にどう落とし込むのかのヒントを得られたような気がします。

自分の業務のことを考えながら聞いていました。講義とワークがセットになっているので自分の弱いところもわかったし、新しいことやもとから知っていた部分もあり、それがはっきりしました。

UIモデリングが厳密にはデータモデルと一致しないいところが、若干難しさを感じています。と言うのも、既存サービスに対するリバースモデリングを行うときにデータモデルをどこまで考慮しながらモデリングし直すかは弊社のPM・デザイナーメンバーはかなり模索している課題だからです。今回のワークショップでの議論を補助線に今後は上記のような議論に展開して行きたいと新しい発見を得ることができました。ありがとうございます!

今回のOOUIワークショップについては、SmartHRさんのnoteでもご紹介いただいております。ぜひご覧ください!


Goodpatchのクライアントワークにおいては、今回ご紹介したUIクラス図を描くデザイナー、オブジェクト指向を実践するデザイナーが多く活躍しています。お悩みがある企業さまは、ぜひ一度こちらのフォームからご依頼ください。そのほか、御社のプロダクトが抱えるデザインの課題分析・フィードバック、UIデザインの分野に関するワークショップや登壇のご依頼なども随時受け付けておりますので、お気軽にお問い合わせください。

お問い合わせフォーム | Goodpatch

また、Goodpatchではインターフェイスアーキテクチャをはじめ、UIデザインに関わるさまざまな領域で活躍したいデザイナーも随時募集しております。もしご興味ありましたらこちらからご応募ください。お待ちしております!

採用情報:Design Div. UIデザイナー

ABOUTこの記事をかいた人

アバター

Goodpatch公式アカウントです。
  • Goodpatch Blog