既存の製品やサービスなどのUI/UXを扱う場合
既存の製品やサービスに対して、理想的には全体のUXまで作り直したいとしても、とりあえず細かな部分のUIやUXを改善することはできる。
大きな粒度のUXを改善しようと思うと、場合によっては製品やサービス、それを支えるシステムの根本から変更せねばならないこともある。また、「改善」のためとはいえ中途半端な変更はさまざまな混乱を招きかねないので安易に取り掛かるわけにはいかない。
組織全体の、製品やサービスをまたがってUXを見る立場の人は、改善の必要性と、各種制約などとの兼ね合いを鑑みつつ、どの粒度の改善を、どの製品やサービスから実施していくかを判断し決定せねばならない。
そうしたUI/UX改善プロジェクトが複数同時に動くことも多いであろうが、どのプロジェクトがどの粒度の改善を実施しているかを明確にするためには、細かな粒度のUXやUIを専門とするチームや部署と、大きな粒度のUXを専門とするチームや部署は切り分けておくとよいかもしれない。
既存のものでなく、新たな製品、サービスの場合でも、必要な機能がほぼ最初からはっきりしているような場合は、大きな粒度のUXに関しては「設計」というよりは確認程度でよい（というかあまり根本的な変更ができない）こともありうる。
これもやはり、早い段階でどの粒度のUXを重点的に考慮すべきかを判断し、参加するチーム・部署の種類を決定せねばならない。この場合も、細かな粒度のUXやUIを専門とするチームや部署と、大きな粒度のUXを専門とするチームや部署との区分けは役割の明確化として有効に働くであろう。
切り分ける単位が部署であるか、チームであるかなどはそれぞれの組織の規模などの都合によることが予想される。部署的としては大きな粒度のUXも小さな粒度のUXも一括して扱い、プロジェクトごとにその都度、必要な粒度に合わせた人員をピックアップしチームを編成するという運用もありうる。
その場合には、役割の明確化という点ではあやふやになりやすいので気をつける必要がある。
もともと設定された役割にこだわらず「柔軟に対応」することも時には必要かもしれない。そういう事態が生じた場合は、その事例を糧に、プロジェクトの見極めをより適切にしたり、チームの作り方を見直したりなどの対策をとるように心掛けたい。そうした努力が、組織全体の経験として積まれていく。
