Building Components for Large Ecosystems
A perspective from designing Salesforce.com
In a perfect world, us designers should be able to dig deep into our creative minds and spin up anything we want. Yes, that works if you’re the sole designer for a startup or designing a personal website. But the reality is if you’re working for an established company, such as Salesforce you simply cannot. This is because everything we do or everything we should do, must be consistent throughout the branding of the site and make it efficient for other designers to build on top of ours.
At Salesforce, we have what’s called a Web Experience Manager (aka Web Producer) that help to construct the pages. Our job is to make sure they have everything they need to use the components and set them up for success. It’s almost impossible for you to stay for the entire lifecycle of a company unless it goes under or you get fired, therefore you can’t be the only designer managing these components or pages forever. This means when we design we must think hard about making sure all the elements are compatible with the assigned use cases throughout the site and interact well with the other elements. If done correctly, it will save you and the company time, money, and will be more efficient when scaling up.
Why component-based design?
- Better management of the site content
- Easier to spot design flaws and bugs, and deal with them quicker
- No one-off experiences but one cohesive body
- Improving a component benefits the entire site, not just one page
- Helps you think about the experience with more granularity
- Easier for someone else to take over and continue your work
What to think about when building a new component?
I’m going to dive into some key requirements I discovered to be crucial when designing new components on Salesforce.com.
Landscape Analysis
What are other competitors doing to solve the same problem? What components do they use and what can you learn from them? What can you do better to solve your need? Make sure to take this with a grain of salt as another company’s solution is to solve their problem, not yours. Sometimes you have to bend the rules to make it your solution.
Entry/Touch Points
Where do I see this component in your site and how do I get to it? Think about all the use cases you would use this component and the different ways you can get to it. For example, components like tooltips have a wide range of entry points, from hotspots to buttons.
Content Requirements
Components can consist of more than one element. It’s important to think about what goes in that component whether its copy, media assets, icons etc.
Component Characteristics
Since a component can be used in various use cases, most of the time it will take different forms, especially on responsive screens. A simple example of this is a thumbnail. A thumbnail could look like a card on desktop or a slab on mobile due to a limitation of space and depending on where it's being used.
Sizing
This is probably thought of the least (at least for me) when designing components because it’s easy to design around a certain environment. Does the component flex due to width size and if it does how do the elements that it contains respond? For example, will it have a fixed width or max width?
Positioning and Placement
You might decide to give the new component a position that is relative to another component or type of page.
Interaction Requirements
Now the fun part, how does your component interact with user engagement and how does it accomplish the user’s goal or task at hand?
Setting Guidelines
Designing how a component looks like is one thing but we need to make sure it’s used in the right way too, giving the best possible experience to our users. Therefore, we need to set guidelines, UX recommendations and limitations for all the components. One of my favorite ways to do this is “Dos and Donts”.
Use Cases
Displaying all the use cases or examples that you would use this component will help web producers or anyone using your component to clearly understand how it's used.
Conclusion
By designing components instead of pages we can spend more time building a system of solutions that are scalable, easier to manage and maintain, and gives us more time innovating rather than producing pages of one-off solutions.
Follow Me!
📧: malvinyeung@gmail.com
Website: malvin.io
IG: malvin.design
