5 Principles of Designing for Scale
In the enterprise design world, we often solve problems at a large scale — we have a large number of customers, each with a large number of clients or end-users. In addition, VMware’s vision is to empower organizations to deliver any application on any device on any cloud, and we aim to provide an integrated platform to manage the whole environment. All of these factors combined make designing for scale a frequent challenge for us.
Why is it important to design for scale?
We need to respect realistic use cases.
When we design, we should consider the real scale users operate at, instead of just looking at a simple representation of their environments. The mismatch between the simplified case in design and actual complexity in real life can make designs barely usable.
We need to make sure the design is still relevant in the near future.
Things might start small, but consider how fast business is growing and technologies are advancing these days — your unscalable design might soon be outdated and redesigning the skeleton for each release is costly.
When we say “large scale”, what are we talking about?
There could be different types of challenges.
The number of objects or entities could be enormous.
Will a tree view still be usable if there are 5000 items? How would you help users track hundreds of on-going tasks? How would you surface insights from thousands of metrics for users to digest?
The size of a single component can be huge.
A pill shape label is commonly seen in many places. What if it’s a [key:value] pair, and the max characters it could be is 256? If an object has multiple values for a certain category, how do you show that in a field with limited width?
Relationships between objects could be ambiguous or undefined.
Things might not be bundled naturally, or there could be multiple ways to group them. Imagine organizing your new kitchen: would you keep wine glasses near wine racks, coffee cups near the coffee machine, or put all glasses and cups in the cabinet? After you decide where to put what, how will your family or guests know where to find what they need?
The content could have many layers.
When dealing with hierarchical information, for example, showing a parent-child relationship might be easy, but what if you need to show a genealogy book containing 5 generations?
This is not an exhaustive list, but the challenges do exist. I’d like to share five principles extracted from my experiences to help design for scale.
5 Principles of Designing for Scale
To be fair, not all problems involve crazy scale. We should not assume that. Instead, we should optimize the design for the common use cases.
Principle 0: First things first, figure out “what’s the scale we are designing for”, to avoid wasting effort proposing over-complicated solutions.
With enormous scale, a simple problem can become complicated and some of the most basic and straightforward layout options or components might be immediately off the table. Scale will bring extra needs for crafting interactions to reduce cognitive load, to shorten perceived waiting time, or extra information for expectation management, etc. It would also potentially introduce more work on the engineering side to deliver the desired user experience. These things usually are not obvious without working closely with product teams and conducting user research. You need to do the investigation, ask questions, and then start designing with the scale in mind.
1. Create effective searching or filter mechanisms.
We need to help users navigate through the ocean of objects. If you found it hard displaying all content when designing, it will be even harder for users to locate specific items they want.
When working on Cloud Native Storage solution (referred below as CNS for brevity. It allows containers to consume storage from virtual infrastructure), there was a need to show some objects with their attributes for monitoring. While there’s the existing Datagrid component from Clarity design system that I can directly leverage, I found out that our users could have 10,000+ items with 10+ attributes each, along with secondary attributes from related objects.
- Luckily, the Clarity Datagrid comes with pagination and column filters. However, the datagrid comes with UI-side filtering, which requires the UI to pre-load all the data in advance. This is not optimal as there could be hundreds or thousands of items, which would result in extremely long loading time. We ended up building a server-side filtering mechanism with a new API conducting the query only when filtering happens.
- While 10+ attributes are ok with the show/hide column function in the Datagrid component, showing related objects and their attributes becomes challenging. Considering the related objects are also content-heavy, we leveraged the Master-Detail view. There are a lot of details available in the detail panel. We added them to the enhanced datagrid filters to help users find their targets.
2. Provide high-level information, then drill down.
It’s unlikely that everything is equally important to users. When the view is too crowded, where should they start? What should they look at first? Different users might need to focus on different items. Surfacing all details and spreading everything on one screen by default will overwhelm users. We should provide layering and make it easy for them to drill down to relevant details.
- In vSAN Capacity view (referred below as Capacity project, it helps customers monitor the capacity usage of vSAN datastore), we defined 3 big categories with a drill-down view: VM Usage, User Objects, and System Usage. Rather than overwhelming the user with all 20 types of items upfront, they can dive deeper into the ones they care about.
- We also distribute more detailed information to their dedicated page, rather than including everything in this view. Capacity consumption for individual VMs stays in the VM summary page; usage for each container volume and file share stays in CNS and the File service overview, with links on this high-level Capacity overview. This helps users with different roles to stay focused.
3. Design scalable “containers” rather than merely displaying known content.
When designing the layout of your kitchen, it’s better to carve out a space for “utensils” rather than labeling it “forks & spoons” just because they are what you have right now. What if you fall in love with sushi and need to store some chopsticks? Either your “forks & spoons” label will need to be replaced or you’ll need to store your chopsticks somewhere else. Similarly, if you’re a bookworm, you probably wouldn’t buy a bookshelf that’s only large enough to store the books you currently have.
- The relatively generic categories we defined in the vSAN Capacity project mentioned in principle #2 helped us welcome future items into the system. Both the UI and APIs were structured in a way that allows additional items to be appended easily. Several items have already been added to the view as new services were released in the past quarter, without the need to invent new categories or refactor the design.
4. Consider overflow scenarios and have designs ready for them.
Overflowing content is a great way to tackle extreme edge cases while still optimizing for the design at all scales. It prevents the UI from being flooded, yet contains the full content for people who care. How do you know if overflow is necessary? In your mockups, always try some crazy examples (like for user names, don’t just use “Jay-Z” — at least try “Benedict Cumberbatch”). Here are some overflow tricks:
- Use ellipsis for long content in text blocks, labels, tabs, and buttons. (especially consider internationalization, German…)
- Leverage signposts when space is limited.
- Expand and collapse details when they are not always needed
5. Set “guardrails” to handle performance issues
In the fit-and-finish phase, make sure to check with your engineering team about performance. When possible, request a test environment where you can experience performance issues first-hand and spot usability deficiencies easier. Here are some performance issues where guardrails might be needed:
- Noticeable waiting time: Heavy content batch actions such as page loading, file uploading, and configuration changes are likely to cause sluggish UI or long waiting times. While engineering does their best to improve this, it’s the designer’s responsibilities to inform users about potential wait times, unblock users by allowing them to complete other tasks, or add in delightful distractions to reduce perceived waiting time.
- Side effects: Be proactive and inform users of the side effects of “expensive” tasks such as high resource consumption — CPU, memory, and capacity in the VMware realm, and battery life for consumer devices. For example, long-duration monitoring tasks for a large number of targets might affect the performance of other workloads. We need to warn users of unpleasant impact before they take actions.
- Non-real time content: If the UI does not reflect 100% real-time data, tell users how often the system automatically refreshes or if they need to manually refresh to view the most up-to-date data.
- Inconvenient interactions: Some interactions might not work well for extremely large scale scenarios. You might consider providing alternative paths or batch actions. For example, consider drag and drop cards. When users have a lot of cards, the card that needs to be moved could be far away from its drop target, forcing an annoying page-scrolling-while-dragging interaction. Doing this one by one is also trivial if users want to move dozens of cards. That’s why for the vSAN Capacity project, we included an action menu that includes batch actions. It also helps fulfill accessibility requirements. If you can foresee these earlier in the ideation stage, it would be even better.
Designing for scale is a challenge you will meet sooner or later. The 5 principles above are some of the best practices that worked for us — we’d love to hear other best practices that worked for you. Considering scale forces us to fully understand the problems we need to solve and dig into real use cases. We won’t always get a clear statistic directly from our tech leads or product managers. It requires us to ask the basic questions: “Who, What, When, Where, Why, and How”. Designing with scale in mind helps us build robust products that not only meet user needs now, but also meet user needs in the near future without the need for a massive redesign and re-architecture.
We’re hiring!
The VMware Design team is looking for talented designers to help us continue transforming enterprise design. Check out our open positions!
Thanks to Grace Noh and Bonnie Zhang.
