Associate Software Engineer
What a new engineer on the MDS Core team has learned in the past year
November 23, 2021—I joined the MDS Core team back in January of this year and have learned so much about design systems and front-end development that I wish to share some tips with designers and engineers considering using MDS for the first time. Hopefully this will help you make good use of the design system as you work with your teams to deliver Morningstar-branded product experiences.
Not everyone starts their career with the front-end. You might have worked on print design or back-end development before making the switch to be a front-end designer or engineer. While we all can pick up new skills as we move through our careers, having a good foundation in front-end design and development is essential to make full and effective use of the design system.
In both cases, you will appreciate the time you spent laying a good foundation when you don’t have to scratch your head to figure out an error during the handoff process. A few weeks ago, I was reviewing a team member’s pull request and had to familiarize myself with content security policies. The more we broaden our foundation, the more we can contribute to the teams we work with. You will embrace the opportunities to conduct pair programming with your partners to streamline your collaboration.
Before I joined, I naively thought MDS was just another UI library and what was expected of me was to just write code. Over time I did deepen my skills to build components, but I wouldn’t have imagined that so much could go into system thinking. A major responsibility of the team is to engage with product teams and evolve the system through contributions from the community. The team has established principles such as the 3-team rule that contributions to MDS should be relevant to three or more product teams to ensure the system provides the highest shared value. We have also adopted inversion of control so that we structure the system to put as much control as possible in the hands of product teams, providing consistency and flexibility in all the system’s elements.
I believe a system mindset can help you build solutions that are scalable and sustainable, and reduce maintenance costs in the long term too. I would encourage you to look at MDS principles and try it out with your flavor on the next project. I’m curious to hear how it works for you and your team.
The deep focus of system mindset allows us to be curators and tend the MDS “community garden”. Contributions are an essential part of a successful design system. We welcome your contributions and anyone who has time and willingness to contribute will be greatly appreciated by the MDS team and the community. Check out our list of previous contributors!
The MDS team hosts critique sessions twice a week where team members, including the product manager, designers, and engineers, bring questions to the table and solicit feedback from others. Sometimes we have back-and-forth conversations, and the sessions run over time, but I enjoyed being empowered to ask questions instead of just implementing what’s given to me by product or design partners. Indeed, it benefits the entire team to be an active owner and to understand the requirements from different perspectives.
The team follows a standard process for designing, building, and documenting visual language, components, and other patterns. These steps are not independent, but overlap one another as designers and engineers collaborate throughout the process to ensure the usability and accessibility of our components. I would encourage you to feel comfortable speaking to your design or engineering partners at each checkpoint, as well as product stakeholders when you have questions.
The technologies in the front-end space have evolved quickly over the past few years. It may not be a rare case to have doubts and questions when you use a certain technology or even a version of that technology. Be sure to bookmark the MDS documentation site where you could find detailed documentation about component usage, design guidelines, upgrade guides, etc. When I was working with summer interns who tried to adopt MDS a few months ago, I referred them to the Getting Started page and I was glad when I heard they figured it out by following the instructions on that page, even without prior exposure to MDS.
In addition, many people take advantage of the MDS Teams channel to ask questions related to design, engineering, accessibility, and new initiatives when they can’t find the answers on the documentation site. If you need help with addressing implementation challenges specific to your product or planning system-minded approaches to building your product, you can request a consulting engagement with the MDS team.
Besides knowing how to get help, knowing how to ask questions with proper details is equally important. For example, providing a brief description of what you’re trying to accomplish along with the wireframe can give us the context. Recreating the particular issue you are seeing in a CodePen can help us focus on the code related to MDS, and in return better assist you.
I’m proud that our support channels are not just a place to ask questions; many community members are also willing and generous to share their experiences and help each other out. I want to invite you to lend a hand to other colleagues when you have time to do so. Together we can enrich the community and benefit everyone.
I often see posts from other colleagues that link to various conferences, articles, blogs, etc. Take Nadhim Orfali, a Senior Software Engineer on the MDS team as an example. I don’t have enough words to express my gratitude for his diligence in keeping the community posted on accessibility-related news and best practices. I have attended virtual conferences suggested by Brian Verhoeven, our Head of Design at the time, to better my understanding of design systems and shared notes with other team members. I didn’t know what TIL (today I learned) meant until Dan Ciupuliga, our Principal Software Engineer, shared what he learned one day, to name a few.
After a while, I started to follow their example to share what I’ve learned too. The attention this team has given to such learning opportunities motivated me to reserve dedicated time, some of which work hours, to learn and grow outside my day-to-day work. If you wish to be part of such a vibrant community, why not start to foster a learning culture in your team and network? Many of these habits will gradually be part of your team culture, and you will appreciate how much you have grown when looking back.
Lastly, don’t forget to check out our self-guided training on LinkedIn Learning, available to all Morningstar employees, to get yourself prepared to use MDS!