Defining (and using!) design principles
I recently came across this Medium article about design principles by Jason Marder. In the article, Jason outlines how he and his design teammates created design principles at Gusto and used them to help envision future opportunities for the product. Having had success with using design principles to aid decision making within my scrum team, I figured I’d take cues from Jason’s article and write about how I have been using design principles within my scrum team at Truist.

Disclaimer: To comply with my NDA, I have fictionalized certain project details, like the type of product I use these principles for and the specific features that are supported by each principle. 
Why use design principles?
As the first full-stack product team dedicated to our line of business, we have very often been in the position of defining standards and setting the course of work for both internal tools and client-facing products. Over time, more product teams were added and our scope of work became more focused. As a result, our approach to decision-making, at first exclusively prioritizing work based on time and ease of development, has also become more focused, as we now also make decisions based on user need and value. Victory for UX!

One of the tools that we have used to ensure that we are user-focused in our decision-making is a set of design principles. Not only are they helpful to me as the Design Lead, but they also serve as a condensed, easily-shareable representation of synthesized research that can be shared within and across teams. They have also helped us think aspirationally by giving us another perspective to consider when we start falling back into old habits of exclusively focusing on speed and making things easy for the developers.

In this write-up, I will briefly walk through how we apply design principles to the design of a product that my team supports. For illustrative purposes and to comply with my NDA, let’s say that this fictional product is Loop, a reporting tool for our Enterprise Customer Support team.
Starting with what we've already learned
Like most UX teams, our research and data comes from an interesting mix of usability studies, stakeholder interviews, HCI best practices, tribal knowledge, and everything in between. However, it all works together to form a big picture of our users and what they need and value. I pulled out the biggest and most consistent insights from this research and translated those into statements that I thought represented the core needs of our users. 

Getting feedback and refining as needed
After writing out initial statements, I met with our researcher to get her input and to ensure that I was translating the research accurately and effectively. After getting the thumbs up from her, I met with my PM, PO, and UI designer to get their feedback as well.

Because principles can change over time, I update them as we continue to learn more about internal users and as the product evolves, and share them with the team for feedback.
Applying the principles
Creating design principles is one thing, but actually using them to drive and support design decisions is another! For illustrative purposes, I spent 45 minutes pulling examples of how we’re leveraging the principles today (and brainstormed a few new opportunities!). Here are some of those examples:
Principle: Accept the ecosystem
If we aim to fit into Enterprise Customer Support teammates’ overall processes by being flexible and adaptable, how might we make Loop even more flexible and adaptable? 

By considering how we can be more helpful and smooth out the seams within in each user’s daily workflow.

What if Loop users could enable relevant push notifications so they could focus on other work but only be subtly interrupted if needed?

Principle: Be credible
If we aim to build trust and confidence through clarity and consistency, how might we establish the trustworthiness of the information we present?

By ensuring that users can understand and utilize the information in front of them.

Providing users with smart tooltips that not only explain unfamiliar content but also indicate where else that same content can be found in the app would allow users to determine how else the content might be of interest to them.

Principle: Mind the (knowledge) gap
If we aim to support both the expert user and the novice user by providing clear paths of least resistance, how might we allow users to accomplish the same tasks in alternate ways that suit their working style?

By identifying the most frequent tasks where efficiency can be improved, and structuring functionality in a more open-ended way.

What if building and sharing reports was a more accommodating and flexible experience, where users could customize reports as needed and then schedule recurring reports to be shared automatically?

Principle: Temper newness with familiarity
If we aim to make new features and tasks more palatable by being familiar, yet modern, how might we use design to meet or improve user expectations?

By anticipating when user expectations may not be clear and taking the opportunity to clearly, but artfully, fill in the blanks.

What if we used product update emails to not only tell internal users about new features but also to show them how a feature might be helpful to them, so they can try it out on the spot?

What's next?
We have had great success with using our principles to shape and refine solutions, but my next step is to work with my Product partners to take a more user-centric approach as a part of our overall product strategy. I intend to use our design principles to reframe the more feature-specific items on our roadmap to be more thematic and less prescriptive, and to help give direction on what the team should tackle next. 
Back to Top