I’ll start with a story
If you hate stories, you should skip this part. It’s about a UX designer who was tasked with championing a modular design strategy for her organization. She has short brown hair and blue eyes. If you haven’t guessed by now, that UX designer is me.
About eight months ago, our team rallied on a modular design strategy called object-oriented UX (OOUX). Unlike other broad-sweeping modular systems, OOUX asks you to focus on modularizing your core content types — what OOUX calls objects — and take a hard look at how these objects relate to one another. This process helps the design team expose inherent instances of contextual navigation and push toward consistent UI modules.
Well…that’s great for designing information architectures and pattern libraries, but what about designing experiences. After all, mobilizing your content is only half the battle. If you’re going to be on the front lines of UX, you have to be asking why and how.
The why and the how
You might be saying to yourself: “don’t tell me about why and how! I’m a UX researcher, dang nabbit! I eat why and how for breakfast.” So let me explain.
I’m not talking about strategy at the feature level. I’m not talking about process flows, wireframes and prototypes. I’m talking about application-levelstrategy. You know, the thing that we should always be doing, but somehow never have time for? And I’m talking about making it an integral part of our approach to our other strategies, like modular design.
To give you a little more context, let’s talk through an example. Let’s say we’re designing a dating app where one of the core pieces of content is a profile.With modular design, we would ask: “where might this content show up in the UI?” — and based on our answer, we would design modules for each of those scenarios. Maybe we would design a profile that can be displayed in a list or a profile that takes up the entire display. Information architecture. Patterns. Check, check.
But now that we’ve decided the what, what happens when we inevitably realize that we need to think about why someone wants to see a particular profile in the first place? And how that profile would appear for that individual? Do we implement those strategies after the fact and hope that nothing breaks?
I hope you’re shaking your heads out there, because the answer is a resounding no.
Instead of leaping head first into designing our modules, we should build a strategic framework that can help drive our design efforts from every angle. Instead of defining the face of our content — the stuff that appears in the UI — we should start by defining the how and the why that support that content. This is called building block design.
Enter building block design
Instead of asking you to think about the content of your modules first, like other models, building block design asks you to focus instead on the strategy behind that content.
Only after you’ve defined your core UX strategies — the frame that holds your content up — can you start designing how that content will be represented in the interface. The “big picture” strategy for each piece of core content is your building block. Together, your building blocks define the UX of your product.
Building block anatomy
To better understand this approach to creating meaningful, structured content, let’s return to the dating app example. Now that I’ve identified a piece of core content in my application — a profile — it’s time to go through and identify what strategies could potentially influence how this block is designed. By exploring the relationship between other strategic initiatives and our content, we’re able to think more critically about how we approach the design and delivery of this information.
When exploring relationships between application-level strategies, it’s best to start at a high level and work your way down. For example, if I identified personas as a main component of my strategy, I might break this strategy down further by identifying:
- the specific personas that engage with profiles;
- where in the app they are interacting with this content;
- their context of use;
- the core actions they take on profiles;
- and how often they are accessing this content.
It might look something like this:
Once I’ve given a little more context to why this content is valuable to a specific type of user, I can start thinking more critically about what actions need to be prioritized, how the module should be structured to promote persona-specific behavior patterns, and where in the experience this content needs to be delivered.
This technique allows designers to focus on the stuff that matters and not get caught up in visual appeal, interaction seduction, and other interface design patterns that look good, but don’t support actual user behavior.
If I repeat this exercise in terms of a second strategic initiative, additional insights will be gained. Depending on the number and complexity of strategic initiatives you have in place, this can quickly become a time-intensive process. I recommend starting with no more than two strategies.
So there you have it. An example of how to get your feet wet with building block design. If you think this would be a helpful exercise for your design team, check out the Quick Start Guide below for some additional tips. And, of course, I’d love to hear your thoughts on all things modularized. Add your comments below or reach out on LinkedIn.
Quick start guide
I’ve found that many modular design models out there fall flat on giving their readers actionable to-dos, so let me make a point of providing that valuable piece of information:
Step #1: Strategy inventory.
We do content and component inventories, so why not a strategy inventory? Make a list of all the application-level strategies you have in place. Examples include: Personas, data, context of use and human environment design, responsiveness, etc. This is a good opportunity to pause and ask “do we have a solid strategy in place for our application?” If the answer is no, it’s time to get to work.
To do: Rally team members to independently create their own strategy inventories.
Step #2: Define your core content.
This is the stuff your users take actions on in your application. To figure this out, block off some time for a brainstorming session with your team. Ask yourself questions like: “what do my users search for? View? Download?” Once you identify a piece of core content, write it on a piece of paper and hang it on a wall.
To do: Hold an initial brainstorming session with your team.
Step #3: Define the how and why.
Now that you’ve identified your application-level strategies and core content, it’s time to bring the two together! Return to your brainstorming room for a follow-up meeting, and make sure your team brings their strategy inventories. For this part of the process, have your team place strategy post-it notes on any core content where that strategy may have an impact.
To do: Hold a follow-up brainstorming session with your team.
Step #4: The anatomy of a building block.
It’s time to divide and conquer. Assign team members a handful of core content types — or building blocks — and have them iterate on the anatomy of this content.
To do: Assign each team member with several content types. That team member should define the anatomy of that content.
Step #5: Align, align, align
As a final step, get the gang back together in the form of a low-key presentation where each team member presents the anatomy of their building blocks. Save time at the end for questions, alignment and decisions on next steps for driving the individual strategic components of each building block.
To do: Schedule a time for team members to present their building block anatomy.