編集部からのお知らせ
動画セミナー「Security Trend Winter」公開中!
最新記事まとめ「医療IT」
組織で取り組むUI/UX

「デザインの粒度を常に意識」--UX設計チームの分化と連携 - (page 2)

綾塚祐二

2016-04-01 07:00

既存の製品やサービスなどのUI/UXを扱う場合

 既存の製品やサービスに対して、理想的には全体のUXまで作り直したいとしても、とりあえず細かな部分のUIやUXを改善することはできる。

 大きな粒度のUXを改善しようと思うと、場合によっては製品やサービス、それを支えるシステムの根本から変更せねばならないこともある。また、「改善」のためとはいえ中途半端な変更はさまざまな混乱を招きかねないので安易に取り掛かるわけにはいかない。

 組織全体の、製品やサービスをまたがってUXを見る立場の人は、改善の必要性と、各種制約などとの兼ね合いを鑑みつつ、どの粒度の改善を、どの製品やサービスから実施していくかを判断し決定せねばならない。

 そうしたUI/UX改善プロジェクトが複数同時に動くことも多いであろうが、どのプロジェクトがどの粒度の改善を実施しているかを明確にするためには、細かな粒度のUXやUIを専門とするチームや部署と、大きな粒度のUXを専門とするチームや部署は切り分けておくとよいかもしれない。

 既存のものでなく、新たな製品、サービスの場合でも、必要な機能がほぼ最初からはっきりしているような場合は、大きな粒度のUXに関しては「設計」というよりは確認程度でよい(というかあまり根本的な変更ができない)こともありうる。

 これもやはり、早い段階でどの粒度のUXを重点的に考慮すべきかを判断し、参加するチーム・部署の種類を決定せねばならない。この場合も、細かな粒度のUXやUIを専門とするチームや部署と、大きな粒度のUXを専門とするチームや部署との区分けは役割の明確化として有効に働くであろう。

 切り分ける単位が部署であるか、チームであるかなどはそれぞれの組織の規模などの都合によることが予想される。部署的としては大きな粒度のUXも小さな粒度のUXも一括して扱い、プロジェクトごとにその都度、必要な粒度に合わせた人員をピックアップしチームを編成するという運用もありうる。

 その場合には、役割の明確化という点ではあやふやになりやすいので気をつける必要がある。

 もともと設定された役割にこだわらず「柔軟に対応」することも時には必要かもしれない。そういう事態が生じた場合は、その事例を糧に、プロジェクトの見極めをより適切にしたり、チームの作り方を見直したりなどの対策をとるように心掛けたい。そうした努力が、組織全体の経験として積まれていく。

ZDNet Japan 記事を毎朝メールでまとめ読み(登録無料)

特集

CIO

モバイル

セキュリティ

スペシャル

NEWSLETTERS

エンタープライズ・コンピューティングの最前線を配信

ZDNet Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]