Designing for scale
As we grow as a company we will encounter customers who push our software to its limits. Designing defensively now will help minimize those shocks later.
Functional Clutter
New features tend to gravitate toward high-value screens. There is a natural tendency to place tools where users spend their time. This means that high-attention screens will incrementally accumulate more and more commands and data. Each new feature will seem like a modest change, and there will be no time in the schedule to significantly rework the screen.
Plan early for functional clutter:
- Leave significantly more whitespace than you think you need, especially on the action bar.
- Use progressive disclosures for advanced functions right from the start.
- Create re-usable patterns for exposing features contextually (drawers, dialogs) and hiding them when no longer needed.
- Consider how forms and lists would look if a new field or column were added
Content Proliferation
If the user can create or model an unbounded number of objects or pieces of content, assume this number will eventually grow to be unwieldy.
- Ensure lists can be sorted and/or filtered
- Support dataset windowing (either by explicit paging or list virtualization)
- By default, sort lists of items using an intuitive and visible key (default to alphabetic by name)
Slow Responses
We should endeavor to respond to user gestures within 3 seconds, especially since speed is a core part of our product identity. We do not want to risk complaints about the speed of the web UI being conflated with concerns about the speed of our core offerings.
That said, we should not assume all operations will return in a timely fashion. When the user performs an action:
- Lock controls which are paradoxical to the performed action. If a user requests we delete an item, disable the edit and rename operations for that item.
- If a user performs an action which could (under certain conditions) take more than a couple seconds, show a loading indicator. Even an indeterminate progress indicator communicates that the request has been received and we are working to process it.
- If an action is expected to take more than five seconds, consider displaying the outcome asynchronously (either by polling the progress from the current screen or generating a notification or email when the action completes)