Modularity provides a range of benefits and addresses many drawbacks of a typical documentation process. Useful for many UX staff members - not just your typical IA - it’s benefits increase alongside increases in team size, project scale, project duration, and more.

» Key Benefits
» Common Pains
» Who uses it?
» When is it valuable?

Key Benefits

CONSISTENCY
You and your teammates will create consistent documents, your document’s audiences will establish consistent expectations, and ulimately users will engage in a consistent experience

EFFICIENCY
While modularizing designs requires a disciplined upfront time investment, view and variation production and maintenance is far more efficient as the project goes on.

REUSE
Gone are the days where each designer has to reinvent each view and component with each project or painstakingly open an older project document to copy artwork that’s likely already out of date.

SCALABILITY
The larger the project, the greater the benefits of modularizing your components and views for reuse and repurposing in variations, flows and deliverables.

PORTABILITY
As components and views are abstracted out of but still linked to a design document, designers can then distribute, share, and collaborate on continue design iterations.

Common Pains

Unless your artifacts are modularly architected, it’s likely that you’ve felt pains like:

TEDIOUS MAINTENANCE
“Argh! A label in a navigation bar changed, and that now necessitates 40 changes across 40 views”

FLOWS WITHOUT VIEWS
“It’d be great to include views in flows instead of just boxes and arrows, but every view update would then require a flow update too.”

NO VARIATIONS
“Yeah, but how does it look under this or that condition? Or at this or that time in the sequence?”

“Showing variations of a component across states elegantly is difficult because illustrations are at the view level; I’d love to consolidate those variations and manage them outside of my views”

“It’s time consuming to create many view variations because it requires so much copy and pasting and the maintenance is intimidating. While it’s obviously not worth it to create a view for every possible instance, I don’t have time to even create some of the most common view states because it takes too much time.”

CONSTRAINED COLLABORATION
“Because all the wireframes are in the same document, teammates can’t work on the same document at the same time, nor incorporate changes into another’s document easily”

DETAILS NOT CONSOLIDATED
“When a component is displayed on many views, readers have to scan many deliverable pages to get the component’s entire story.”

DIFFICULT TO CREATE PROTOTYPES
“Views are time consuming to extract from a design deliverable into an artifact more suitable for paper prototyping or usability testing. Plus, if I update my design prior to testing, I have to go through that extraction all over again.”

LIMITED SHARING & REUSE
“All of my wireframes are useless outside of the document I’m producing, unless I send out my entire document and let others cut and paste from it.”

CONFUSED AUDIENCES
“It’s hard to create a single document that speaks to both my non-technical stakeholders as well as detail-thirsty development & QA staffs.”

Who uses modularity?

Any resource that contributes to a user experience design can benefit from producing modular documentation. That said, the modular approach is most often employed by information architects, interaction designers, and user interface designers (aren’t those all the same person? Anyway…). Additionally, the approach has also proved increasingly successful for visual designers, whether they are working as, in conjunction with, or independent of IA/ID/UI staff. Finally, other resources that have also participated in modular systems include copywriters, producers, and design team management.

When is modularity valuable?

Sure, why get modular if you are a sole IA working alone on a quick turnaround project that involves an experience of one, static web-page. However, the benefits of modular increase exponentially as the following increase:

• Collaborating design staff (whether one project or a larger holistic experience emerging from numerous, related, ongoing projects)
• Duration of a design project
• Number of deliverables (wireframe reviews, design spec, paper prototypes, etc)
• Number of deliverable iterations
• Number of views
• Number of view variations
• Number of components
• Number of component variations
• Likely reuse of views or components in subsequent or related efforts