We are big on collaboration at Mostly Serious, and this is especially true when it comes time for an internal UI review. These reviews mark a pivotal moment in a new website build. Effective collaboration here leads to accurate estimates, realistic timelines, and an overall smooth-running project. On the flip side, misunderstandings here could cause us to spin our wheels, or worse—implement the wrong feature.
Since a project’s success rides upon our shared understanding of the scope, features, and technical feasibility of a design, we take care to:
- Address common pitfalls and “gotchas”
- Anticipate edge cases or fragility in the design
- Asses the riskiness or technical feasibility of every feature
To give you an example of what our collaboration looks like, here are 5 questions our engineers often ask designers when conducting an internal UI review. (If your team is onboarding a new UI designer you might these particularly helpful.)
Question 1. How would you like this to work on mobile?
Some modules adapt easily to different sized viewports, while others not as easily.
It’s important for designers to think about differences between the mobile phone, tablet, and desktop experience early on, especially if a module is inherently complex.
In a UI review, we ensure that our engineers and designers clearly understand how a module’s layout will change with the viewport and the interactions needed for mobile: sliding, tapping, swiping, etc.
By the way, when we use the word “module” in this article, we’re referring to a single, self-contained component, this post explains it in detail.
Question 2. What configuration options will we offer for this Module?
With every module we create, we aim to offer content authors the right amount of design control while still enforcing consistency. To find that perfect balance, engineers will ask questions like:
- How many background color options will we be providing?
- Is the highlight color configurable, or is it automatic?
- Will we provide different layout options for this module (stacked vs. side-by-side)?
- Is there a limit to how many times the author can use this module on a page?
And these questions often lead to others, too, such as:
- Do the color options we are providing allow for sufficient contrast?
- Are there any edge cases that could become problematic? (Such as if an author uses two of these modules back-to-back.)
- Does this make more sense as one highly-configurable module, or would it be better as two separate modules?
Together we arrive at the configuration sweet spot.
Question 3. Are there other states we should consider designing now?
When reviewing a static UI design, we take a minute to (pardon the pun) focus on the state. Our engineers will ensure the most common states have been designed, look for any missing states, confirm our expectations about transitions between states, and probe for unknowns.
For example, if a static design implies the use of a dropdown menu. We’d ask questions like:
- Has the open state been designed? Is it a small panel or a large mega menu?
- Have we defined styles for hover and focus?
A second example would be a table or list of data. In the majority of cases, it will contain several rows, but we may ask the designer’s intent when there is 1 row, 100 rows, or no rows.
Empty states, “no results” views, and less common “what if” scenarios often become opportunities for a designer to bring out the character and voice of a brand in a clever way.
And getting ahead of all the possible states means that engineers are required to make fewer assumptions in development.
Question 4. Is the content here defined globally, locally, or both?
Some modules contain content that is identical 95% of the time. The module could be a call to action section, a contact email, or a global footer. But we also want to account for the 5% of the time when the context requires different content. For example, maybe the call to action should be “Apply Now” only if the visitor is on the “Careers” page.
Spotting scenarios like this in a UI review helps engineers plan ahead, and implement a convenient solution for authors. With Craft CMS we can easily set global default content and allow authors to override that content whenever they need to.
Question 5. Are there any transitions, animations, or motion assumed beyond our baseline?
Tasteful transitions and motion design give a UI that little something extra. To be most efficient, our team has defined a standard set of transitions that serve as a baseline for our projects. For any motion or animation that goes beyond our baseline, we create a master document (in Notion) to define it and include examples for clarity.
Rather than assume, we ask questions like:
- Will this element fade in?
- Will these overlapping images have a Parallax effect?
We also look for any elements that imply interactivity and take care to define what they do precisely, such as:
- Will this video play in place? Or will it open a full-screen modal dialog to play?
With these safeguards in place, we can avoid surprises and ensure we are delivering all the little details our designer intended.
Collaboration time is built into our process at key points like UI reviews and our quarterly design-dev summit. But, we also make it a point to encourage collaboration as the day-to-day norm.
We created a dedicated “design-dev” channel in Slack for our team. And we frequently will iron out UI details with an impromptu Zoom meeting.
Our team has built a solid framework for efficient designer-developer collaboration with these and other efforts. Pretty soon, we expect “Team Engineering” and “Team Creative” to be finishing each other’s sentences ::wink::
