Cover photo by Joyce McCown on Unsplash
It may seem obvious, but outlining specific acceptance criteria is a great way to get non-designers involved in the user experience without having to go through all the work of making screens to review. These tests can guide designers on what the objective of a page is, and allow them to focus on making that experience as friction-free as possible.
Developers have been doing this for years with a process called Test Driven Development (TDD) in which tests are written before code. Designers can benefit from this approach, too. For design, the goal is the same. You want to establish the success criteria for your designs up front, so you have an objective to design for. This has many benefits including more focused design time, easier defense of design decisions, opportunities for collaboration with non-design teams, and a shared understanding of the user experience of your product.
You can approach TDD(esign) with 3 easy steps.
You should always be answering the question "Why does this screen exist?". Describe your goals by using concepts and action words, not UI elements. Design is communication, so saying "we need a way for the user to add this item to the shopping cart" is more abstract than "include an add-to-cart button". This keeps the test open to implementation so a designer could give option A that includes a button, or option B that uses a gesture. Both options can satisfy this test, which gives more room for innovation (and feedback - which solution is the best fit for your product?).
This is actually putting pixels on pages. Sketch, code, markers and white boards, doesn't matter. Use UI elements and good ol' boxes to get the job done. If a page has 3 tests (users need to do 'A', 'B', and 'C') try to think of multiple ways to solve each challenge. Designers have a million tricks in their bags so this is a great way to isolate some creativity and think through iterations per problem. If your company uses a design system, you should already have a documented set of UI elements and components on file. Establishing the tests up front means you can simply drag and drop the corresponding elements on the page to satisfy the requirements.
Design without a designer? Is this legal?
Using the criteria from step 1, compare your design to the objectives. Its good to tackle a page holistically, then zone in to one element at a time to help understand what is or isn't working.
For example, at a macro level does this page layout and hierarchy support the prime directive of the page? From there, zone in on the details. Does the heading support the prime directive? Do those photos? Is this action the best way to complete that task? Etc. I like to score things binary (pass or fail). Binary helps to focus on making decisions. Does this element pass the test objective, yes or no. If "yes", move on, if "no", put it on the list to review.
I've explored using numbers (1-3) but it opens too many doors for interpretation or non-test influencing. Remember, in the dev world a test either passes or fails - there is no "kind of". When you're done testing a page give it a total score. Out of 10 elements on the page (total of 10 points possible) how many passed? 50%? 80%? 100%? You should be aiming for 100%, because if we remember Step 1, the team worked together to set out the goal of this page. If the page doesn't meet those goals something needs to change.
Here are some examples!
An eCommerce site's product page...
This page exists to... "enable customers to purchase an item".
The bare minimum here is an action that enables the purchase, possibly adding the item to a shopping cart. A follow-up question might be, how do we support the primary action with additional elements on the page?
Your design might have a cool product photo, a gallery, maybe some augmented reality feature to see the product in your home, a buy now button, some witty descriptions, and a few customer reviews. Time to test.
Each element should support the primary test condition / objective of "enable customers to purchase an item". One by one test what's on the page. Does the page title support or detract from this objective? The photo? The actions? The copy? The reviews? The layout? For each element give a score. Just like in school - how did the design fair overall? Did it pass the tests enough to move on, or should parts be reworked?
An agency's contact page...
This page exists to... "allow potential clients to contact us regarding new opportunities."
There needs to be an action from the user to initiate contact. How that unfolds is up to you. Additional constraints might include time-zones, hours of operation, methods of contact that make the most sense for your users, handling expectations of the response, etc. All of these can be constraints applied to the page concept before anything is designed.
This will probably be a form, but what if it was a button to "tweet at us" or a link to live-chat? How can you use the objective of the page to delight and engage the user? Using the constraints can help designers innovate while still keeping the objectives in sight.
Test the page against the acceptance criteria. Does the page make it easy for someone to contact you? Are there elements detracting from this experience that could be removed? It's very easy to add to a UI, but this method helps designers (and non-designers) understand what should stay and go.
A dashboard for managing investment portfolios...
This page exists to... "allow portfolio managers visibility into their client's assets, specifically indicating items requiring action."
Dashboards are notoriously cluttered because they often become the "kitchen sink" of design. Isolating why this dashboard exists at a high-level can help clear away clutter so only the most important elements remain.
Using these constraints you might find a list of tasks to be helpful, showing the user what they need to focus on. Data visualization might be another win, giving "at a glance" insights into some numbers used to influence decisions or tasks. It can be easy to dump all the content on a page - but if you can pair things down to "just enough to achieve the goal" your design will still be effective without the noise.
Test your page. Are the actions the user needs to take clear? Of those, what actions are most important? Is the right information presented to help make decisions? What is polluting the objective here?
At this point you can either revise the page, or revise the tests.
If you've worked through steps 1-3 above you likely will have spawned some new ideas, or gotten some feedback about what isn't working. Take that feedback - which is about how this design achieves the objectives - and iterate to try to develop a better solution to those tests.
Sometimes a requirement that seemed important in the beginning begins to melt away as people chew on it more. Test Driven Design can challenge key stakeholders about what is really important - and allow designers the freedom to clear out the noise that distracts.
Sometimes more requirements are added. The existing list of tests is a great tool to push back on additions as you can objectively say "well, there are already X goals for this page... this new one seems at odds with the others, can we put it somewhere else?" Or it forces some conversations about how the experience is coming together and what needs to change elsewhere.
If you happened to hit it out of the park first try (which this framework really tries to set up), then move on to the next set of screens in your workflow and keep at it.
As a bonus, you can include more tests in your design process. Try building in accountability for things like...
I hope you find this approach to design helpful, thanks for reading!