How DRY is your design? Does every element in your design have CRUD? Can you narrow the GIGO gap?
I find it hard to think about creating UX designs without considering the underlying logic an engineer will use to bring it to life. Successful UX designers are often trained in markup and coding, working within modern web design principles supported by constantly updated libraries housed on Github. However, there are many principles that are used by software engineers that can help new user experience professionals make design decisions that are more likely to be implemented successfully and scale appropriately. Here are three that I use regularly in working with my design teams.
Just How DRY Is Your Design?
DRY stands for “Don’t Repeat Yourself,” and it’s an engineering mantra every designer should know. “We’ve got to DRY this out,” I’ve heard many engineers say when they’re thinking through how to build on-screen components, establish relationships between page templates, refactor how a back-end service should work through an API, structure a database model, set up automated testing protocols, and so forth. (The acronym originates from The Pragmatic Programmer by Andy Hunt and Dave Thomas.)
The DRY principle has equal application for how designers approach what elements they should include in their screen designs. Exploring many divergent potential design ideas is what allows us to create the best concepts to build and test with users. But we often cause issues by varying our designs in ways that require engineers to create multiple and varied instances of the same objects, styles, and screen structures. We burn time managing these details rather than repurposing key elements. In the long term, users can become confused by so much variation in the large and small details of our designs, and we will need to refactor our design and associated code to simplify the experience.
You need exceptional reasons to justify building out so many exceptions for your product. Apply the DRY principle to your UX and development work by asking these questions of your design ideas, as well as when you enter into critique with your team.
Design Pattern Replication: Are there major variations in the design patterns we’re using across screens? If so, should they be made more consistent? This applies to both overall screen templates and layouts, just as much as the design of modules that slot into your screens. As an example: Say that you’ve created a blog template for your corporate web site where you have a specific carousel design for when people upload and display their images for users. On the home page of your corporate web site, you have a completely different carousel design and implementation. Should they be the same design and code base, or different? If so, why? Can you justify the need for a difference, or should you DRY it out?
Screen Templates and Content Relationships: Is the content hierarchy reinforced across different screen templates? Are we creating too many templates, when only one or two would suffice? Are we thinking modularly about what modules and components will inhabit them? Are we presenting the objects in these templates in a constrained way? As an example: If you have eight ways you allow the user to display a text block or image on a screen, you are creating dozens of potential layout issues and exceptions in how those screen templates are engineered. What if you only had six ways to display those items? Four? Two?
Component Reuse: Do these components we’re using on this screen appear anywhere else in the system? If so, are they consistent? If not, should we consider making them global components, which can be reused over and over again? This approach can apply for anything from radio buttons and drop-down menus to navigation and search patterns. This approach also applies to how you size and present those components across devices, if you’re reinforcing cross-screen consistency and/or fleshing out a responsive design.
Type Handling: Are our decisions around type handling consistent across screens? Do our h1, h2, h3, and other elements match in size, weight, and spacing? Do the typefaces that we’ve selected render appropriately across the devices that we’re targeting?
Color Use and Reinforcement: Are we repeatedly selecting and applying our color choices in a way that reinforces specific intents for our users? As an example: You use red as a color for when issues come up during in-line form validation for users looking to sign into your product. Are you sure it’s a good idea to use the same color for headlines on your home page and for buttons asking for you to leave a comment?
If you have a strong brand system and design language in place, it’s easier to answer the above questions and make sure your designs are DRY. If you don’t, then continuing to ask and answer these questions from sprint to sprint will help you drive towards a more explicit design language for your product.
Does Every Element in Your Design Have CRUD?
Most things that we design allow our users to create all sorts of content. But as designers, we often leave out the explicit actions that people need to properly interact with that content. And if we don’t specify these actions in advance, we might risk leaving out critical functionality that makes our interactive websites and products unusable.
All you need to remember is CRUD: Create, Read, Update, and Delete. The term was first spread widely by James Martin in his book Managing the Data-base Environment. These are the key actions (verbs) that people require when using a software system that involves the creation and management of content that is held in a database. You see this principle applied to all types of software, from managing content in a corporate CMS to allowing user-generated content within a product.
Here’s how each action should be considered in your designs.
Create: Provide people with the ability to add an object into the system, including any key supporting details or metadata that support how it’s read and updated. As an obvious example: When you use Facebook and want to post to the News Feed, you tap on a button that allows you to create the post and upload it into their system, including text, links, photos, videos, and any associated metadata that’s required to support how that object will render to yourself and other users. The metadata may be explicit, such as time posted to the system or location, or implicit, such as what other friends happen to be near you and also posting. UX designers should have an awareness of all these data elements when they design a flow for content creation within their product or system.
Read: Allowing people to view this content once they’ve created it. You will need to choose what elements that the user creates will be rendered, and where it appears in the system. The user may need to sort, filter, or adapt the view of that content object to make better sense of it, as well as take other actions related to that content object. As an example: If you’re managing a web storefront, you may create an item for purchase, and the user will need to be able to read information about it in order to buy it, save it to their wish list, and so forth.
Update: Once you’ve put content into the system, you may need to update some of the details associated with it. You may only be able to edit select fields related to that object, depending on the case. As an example: Revising a comment that you have left on a website may only be allowed for 15 minutes after you’ve posted it.
Delete: If you don’t want the object to be within the system anymore, you need the ability to remove it. The challenge from a design and engineering perspective is not only providing the ability to remove it from rendering, but also to consider the cascade effects of that deletion across your entire design and all screen types. Don’t assume that the user deleting the object should cause it to be wiped from the system completely, especially when the deletion has to do with the user’s profile or identity within the system. As an example, if you go to cancel or delete an account, you may want to ask the user if they want the data to be held in case they want to reactivate the account. Doing this absolutely depends on the context of your system! As a sacrificial example: If you’ve created a website that’s meant for secure, anonymous storage of a person’s legal documents, deleting your account might require the destruction of all objects associated with that person based on what you’ve promised to your user.
You’d be shocked how many websites or products build minimum viable products without including one of the above actions, causing major issues along the way.
Can You Narrow the GIGO Gap?
Most people know the term GIGO: Garbage In, Garbage Out. In essence, if you’re bringing garbage into a system that you’ve created, that system will inherit and recombine that garbage, then presenting it to the user as part of what they experience. (Unless we’re talking about the content we see regularly on fail blogs and humor websites.)
As a UX designer, I want to reduce the ratio of garbage coming into the design that could impact the user, both in what is provided by back-end systems and databases in terms of data, and in what design decisions that I am making that enforce the appropriate level of quality for the resulting output. There is always a gap between the two. Narrowing that gap is one of the constant struggles that you will have as a UX designer, and it’s one of the top reasons why a designer’s intent is not realized in a website or a product.
Ask the following questions of your team to try and narrow the GIGO gap.
Database Schema: Do the content elements and functionality shown in your design exist in your system’s database? If so, what is the level of consistency and specificity in how it’s stored? If there are gaps, how hard would it be to add those fields? In doing so, are there larger impacts that you hadn’t considered? New relationships between those data elements? Missing metadata? New models for content relationships?
Content Audit and Quality: How robust is the actual content that is in the system and stored in your database? Does it meet the quality standard that you’ve set in your designs? If not, how much time and effort will it take to improve it? Does that dovetail with how much time it takes to update the database to store those changes?
Back-End Services: Does the way that content and data is served to the user need to change based on what you’ve designed? Does new functionality that you’ve proposed require new services to make them a reality? Is the quality of that service part of the GIGO gap? If the database and content has changed, what will need to be revised to properly consume and serve that content? Are the proper API contracts in place to allow them to be served for use by your user interface?
Front-End Development and UI/UX: What’s the minimum viable functionality and content revision that can create the greatest impact for the user? If a proposed function or type of content isn’t available for a period of time, does removing it degrade or destroy the design solution you’ve set up?
User Feedback and Metrics/Analytics: How does the user give feedback about what they perceive as garbage in the system? How does their feedback dovetail with the overall data and analysis you’re doing about user behavior?
By answering the above questions, you’ll identify the necessary gaps to fill, and be able to prioritize and plan how they can be improved with your teams.
What Engineering Principles Do You Use?
Are you also using engineering principles in your UX design work? Please leave them in the comments, so we can make stronger design solutions and become BFFs with our engineering collaborators.
Thanks to Michael Devin and Matt Conway for discussing the above principles with me over the years and helping me apply them.