In software design, it can sometimes feel like a project is never really complete. Sure, there are points where a stream of design work is finished, you've talked through it with your development team, documented the heck out of it, and it's ready to be built. But then a week or a month or a year down the road, it's time to make an adjustment to meet user needs, add a feature, update the brand, or rethink the entire thing. Yes, things are always in flux. But it's still important to know that as a designer, you did everything you could to provide your team with all the makings of a fantastic product.
At Maark, we've been doing something simple to ensure that we've accounted for everything in a given screen, workstream, or product as a whole: A checklist. In professions where lives are on the line, checklists are a given. Doctors, nurses, and EMTs consult checklists during any kind of response or procedure, even the most routine. Commercial and military airplane pilots have granular checklists for just about every ordinary task — pre-flight, take-off, and landing — as well as checklists for malfunctions and emergency situations.
The work we do doesn’t require quite as exhaustive a checklist as an EMT or pilot, so we don't have a long list stating every possible design pattern. That would be overkill, and it wouldn't be applicable to every project. What we do have is a reasonable list of seven questions we can refer to throughout the design process (and which applies to just about every project). We typically embed them right inside our design file, and as we go along ask ourselves: does my design/documentation answer these questions?
So without further ado, here's our checklist.
A static screen design can be very informative about what needs to be built. It can describe the overall layout, typography, colors, images, and more. But what it doesn't begin to do is let a developer know what interactions can happen within this screen. In modern screen design, we rarely see a screen with no on-page interactions. These can come in the form of dropdowns, accordions, modals, text inputs—the list goes on. And often when these elements are manipulated by the user, it can have an effect on the overall page state or the information being presented. So when you've buttoned up the design of that screen, ask yourself, have I accounted for everything that can happen here?
When you're the one creating the designs, you have a level of insight into the design that others (stakeholders, project managers, developers) just don't. To the designer, it may seem obvious that if a user clicks such and such a button, it will trigger this action or go to that page. Self-evident, right? Nope. When designing and documenting your work, try to imagine that someone with absolutely no context into the project could potentially look at your designs, because chances are they might. Some random executive from the client team may stumble upon your Figma link or a developer who hasn't worked on the project before could be tasked to build your designs.
On our team, we've begun to document how just about anything interactive on any screen triggers or connects to anything else. This navigation item connects to that screen? Add a flow arrow documenting it. This button opens that modal? Add a flow arrow from that button to the modal design. We've received a lot of great feedback from both our client teams and our development team alike for simply documenting how screens connect to each other.
In modern web or app design, a screen can be comprised of many states (think modal windows, active/inactive states, button hovers, etc.). When users interact with an experience in which the state changes, transitions can be helpful in orienting the user to what is happening, or what action they have performed. A transition can be instant, can be the subtle fade in or out of an element, or can be comprised of complex animated motion. Whatever the case, it's important to make sure that any intended transitions are made clear to the development team.
Documenting transitions can be a simple as adding a note to a design that says "this fades in." When more nuanced transitions need to be documented that are difficult to describe verbally, we typically turn to prototyping in a design tool like Figma. But don't let things like transitions get lost in a prototype no one sees. Make sure you provide a link and details to look for, or even walk your developers through it to make sure everything is clear.
Dynamic experiences can hinge on the input of a specific user, and the actions of the user can do a lot to determine what will actually be presented on the screen. Is there a difference between what a user sees when they are logged in vs. not logged in? Probably. Do different types of users see different types of content? Quite possibly. Should something different happen the first time a user logs in? How about the common quandary of a screen that lists content generated by the user, but they haven't created anything yet. Is there an empty state? It's essential to think through all of the possible scenarios in relation to user-specific content. Discuss these scenarios with project managers and developers, as they may think of a state you missed.
This may be an obvious one, but in a time where your design could be viewed on a mindboggling array of device sizes, it's ever important to think through how it will respond. The approach can vary from project to project, but it's typically best to start by discussing what breakpoints already exist in the codebase, or for a new project, getting on the same page as your development team about what breakpoints should be built in. For some components in a design, it may make sense for them to be fluid all the way from a large desktop to a mobile device in portrait orientation. For other components, they may go from a four-column layout to a one-column layout. For a main navigation, it could make sense to collapse into a hamburger menu on tablet and mobile sizes. In extreme cases, a part of the design that looks a certain way on a desktop device may need to be completely rethought for mobile. Whatever the case, separate your designs by breakpoint and make it clear how each component in a design adapts for each size.
Web content accessibility is a huge topic that has its own rigorous set of guidelines (WCAG 2.1), and we even have our own internal accessibility checklist to reference as we design. It's something we always have in mind at Maark, and we've even built tools to help ensure we're adhering to guidelines, including the Contrast plugin for Figma. The biggest things to think about around accessibility in the visual design phase are:
Make sure links are differentiated from other content through something other than color alone.
Make sure the color contrast of text, icons, and other elements complies with accessibility standards (this is where that Contrast plugin comes in handy).
Make sure there is a visible focus style for interactive elements that are navigated to via keyboard input.
Watch the use of all caps as they can be incorrectly read by screen readers.
Keep line length of text within ideal lengths (50-75 characters per line including spaces) for optimal readability.
A lot of accessibility considerations depend on the development phase, and it's always a good idea when testing in dev environments prior to launch, to browse your designs in screen reader mode on multiple devices. Especially in complex experiences, screen reader testing typically surfaces issues that can be corrected by working with your development team.
If you're designing for a global audience, and especially if your design will incorporate the ability to switch languages, it's an important and often overlooked detail that different languages will impact your design. If the audience you're targeting uses a language with considerably longer words (French, German) or a completely different character set (Chinese, Arabic), you'll want to test the limits of your design with these alternate languages. It's possible you'll find that different languages may require adjustments to a design so that things don't break in certain situations.
In software, we're typically not in a position where users are risking life and limb by interacting with our designs. But their experience is on the line, as is the value of the product, and a solid checklist is a way ensure that all the critical elements within an experience are taken into consideration.