Time-saving Best Practices for Scalable Product Design
By: Caleb Khoo
Tags: Product Design, Ui Ux, Ui Ux Design, Design Patterns, Product Management

Have you ever found yourself in a heated discussion with your team about how the user’s experience is all wrong halfway into the development process? You are not alone. Whenever a team of designers and developers work together, there must be a shared product vision which is unambiguous and united. Furthermore, each team member must be able to step into the end users’ shoes and build the product to solve the users’ problems together. This has to be done to reduce the inevitable friction that will emerge once development begins.

Looking back at my work experience, I found that a lot of time was wasted when the team did not have a common design and development language. While some cases were unique, I would say that more than half of it was repetitive. It would have been faster if we had established a kind of “design repository” or “design library” (which is the term that is becoming widely recognized in the design field), similar to how developers have their own code repository.

Having this “design repository/library” would also help any newcomers to the team get up to speed very quickly and contribute to product discussions. Everyone will then need to be familiar with these common terms and use cases so that discussions are optimized when everyone is on the same starting page. With this system in place, you will not have a case where someone is talking about something so far off from the product that no one else understands them.

When should you do this? The crucial time to do these things is right after the research and prototyping phase where you will have a good understanding of what you are building and who you are building for, just before you kickstart high-fidelity mockups and development. Before would be too soon and after would be too late.

In this article, I want to share my own approach after going through a bit of the chaotic period before we settled down on some common practices which increased our productivity exponentially. The case that I use here is a web-based access control enterprise software solution which grants digital key access to a consumer’s mobile device which I recently pushed into Beta production.

Here are four key considerations we had:

Terminology

Interactions

PANEs

Realistic Dummy Data

Terminology

Before any development began, our team would sit down and discuss use cases together. We would identify the key stakeholders that we were building the product for and we addressed classes and objects upfront. Then, we would clearly define the different types of users, standard use cases and variables inside each feature set. The Product Owner or Product Manager in charge of the project will be the keeper of this document and also the final decision maker on any feature or design changes, after consulting with the designers and the developers. It is essential that all team members, including developers and designers, use the same terminology once it is established.

A sample of our lexicon:

A sample of base user stories which the whole team would be familiar with. These base user stories describe the fundamental core experience of what we want our product to achieve before adding on sub-flows and other features:

Interaction List

To speed up the design and development process, you should also have a template of frequently used interactions that are standard in most products so that you don’t have to waste time debating what these interactions do or get confused when someone else mis-labels them. In essence, this really is just an extension of what UIUX designers already do when they create their style guides for the usual buttons. From this reference sheet of interactions, you can also create your buttons and button states like mouse-overs and selected buttons.

Here are some of my frequently used interactions:

PANEs

PANEs (Prompts, Alerts, Notifications, Error Messages) are a special type of interactions or user feedback which involve catching a user’s attention (read: POP-UPS) and require them to be informed of something important. Typically, we only think of these issues spontaneously when they crop up. And understandably, the team cannot pre-emptively predict every single issue that will appear.

Therefore, we adopted a “Pareto Principle” where we simply designed what we believed to be the biggest buckets of use cases. Simply create a spreadsheet of PANEs and where you will use them, then design the visual of what it looks like so that you can rapidly create screens when you need to. This will also help your developers build the error handling system much faster.

Realistic Dummy Data

When it comes to dummy data, you typically come up with a random name or random number (some Lorem Ipsums) that you just put as placeholder data spontaneously. But this gets confusing if you are designing for multiple roles and multiple core UX flows. One tip is to be more thoughtful when placing dummy data and actually consider what this data is used for, where it will come from (inputs) and what does it affect (outputs). Once you have this consideration in mind, you will be able to create more situation-specific realistic dummy data which will be much more helpful in your design.

Here are some benefits in creating realistic dummy data:

It is kind of fun — allowing you to play around with your imagination and roleplay a little

Helps you transform your design into a narrative where you can then tell a story to your internal team to help them build the product better

Communicate the core problems you are solving much more clearly to your customers externally

My approach is to generate an index of dummy data filled with personas and dummy company names so that you and your team will be clear minded even as the design and development process becomes more and more complex. Many times, I observe that junior designers work hard in research and creating the user personas but then neglect to use these names and identities inside their prototypes.

And as always, you can never think of all the possibilities at the beginning but the important thing to do is to create that index or directory where you track all of your dummy data so that you can replicate things easily and add on to it to keep optimizing your design.

One caveat to this is to also know when you should stop creating such unique dummy data. There will come a point in time where Lorem Ipsums are indeed sufficient. From my point of view, the most impactful unique dummy data would used when describing the first few instances of a class of objects. For example, if you are creating a list of visitors, you would only need to give unique names to the first 2–3 visitors that you need in order to create a coherent user story. Subsequently, giving the rest of visitors unique names would be an inefficient use of your time.

Ending remarks

With that, I would like to end off this article. I hope that my fellow product managers and designers have learnt something new or at least got reminded of things that they might have missed out on. One question I always ask myself when doing projects is whether the work or assets that I am about to create can be reused later. We should aim to minimize the amount of throwaway work so that less effort is wasted. There are a lot of ways to make your product design work more optimized and scalable so that you can take on bigger and more complex projects so let me know if you have your own recommendations.