Nokia is a telecommunications company that builds vital mobile, fixed, and cloud networks around the world. Between May 2022 and April 2023, I interned as a UX Designer under the Cloud and Network Services (CNS) business group. CNS deals with 5G, core, IoT, and cloud solution deployment to help companies embrace disruption and develop new business models.
I worked in the design system team, developing and maintaining Nokia's design system, FreeForm UX. FreeForm helps to drive and deliver unified solutions across three different libraries with fully themed, tokenized, and accessible components. FreeForm is part of a larger initiative called Common Software Foundation (CSF), which aims to bring CNS applications together into a coherent software suite through modular and scalable software infrastructure.
Similar to many global design systems, FreeForm strives to encourage the usage and consumption of its modular library across software teams as it reduces the cost of service and care for the company. However, scaling isn't as simple as it looks with an application suite and workforce as diverse and global as Nokia's. Therefore, we needed to think about how we might further encourage application teams to champion FreeForm as their source of truth. With a company rebrand in the works (launched February 2023), there was an opportunity for the team to evolve the design system in order to help application teams reinforce and scale Nokia's core competencies as a B2B technology innovation leader. As a result, we looked closely at what our design system had and who it engaged, and pondered about how we might evolve its delivery and capabilities in order continue empowering designers at the company.
Build the next generation of FreeForm UX
Adoption of FreeForm UX reduces cost of service and care for teams
How might we make it simpler for FreeForm UX to grow at scale and complexity with the company?
One way to approach this is by providing designers and developers with the right tools and information to build great experiences in their respective teams around the globe. This is where the majority of my efforts had been focused on during my time at Nokia.
In order to achieve this, our team focused our contribution in three main areas: the creation of new ways to consume FreeForm, the gradual improvement of what already exists, and the maintenance of elements that work well for our organization. Some of the tasks that were prioritized during my time here included; accessibility compliance, exploring new tools and processes, identifying and documenting common patterns, and expanding the capability of our components. We believed that making actionable progress in these three areas would act as a staging area for the next iteration of Nokia's design system and at the same time, increase FreeForm's adoption and allow it to scale to the company's complex and changing needs.
Tools are a vital medium for designers to get their work done. Part of my work included exploring and evaluating new tools to improve how FreeForm is consumed and scaled within application teams. I worked on three main projects in this domain: Evaluating a potential migration from Sketch to Figma, exploring how plugins could provide useful information to designers when prototyping, and testing new content management systems (CMS) for our design system.
A potential migration to Figma would have a significant impact to how FreeForm is consumed and the tools designers would need to use the design system. We formed a team consisting of stakeholders from application and UX teams to investigate the potential benefits, drawbacks, and obstacles we would face in moving over to Figma. I worked on researching and testing different configurations for a potential design system in Figma as well as finding out how feasible it was to migrate our current design system into Figma. To summarize, our overall findings were in favour of moving to Figma. The process of migration is currently ongoing. Unfortunately, I cannot speak about the other projects as they are currently ongoing.
April 2023: Parallel to Nokia's rebrand in February 2023, we migrated the bulk of our design operations from Sketch to Figma. As a result, we had the opportunity to rebuild our design libraries from the ground-up and implement new features. To ensure this effort was successful, our team needed a coherent direction to work towards. This is where I stepped up and led 10 designers to create a minimum viable offering of the design libraries we had available.
As this was a time of significant change, it was important for our team to lean towards playing the role of the educator – frequently holding 1-on-1s and team-wide tutorials to help ease designers into the new environment and tools they had available to continue solving meaningful problems. This also led to me hosting tutorials for 30 designers and creating videos for many more to reference in the future.
In addition to exploring new ways of working, I worked with application designers to compile and create new pattern documentation to address recurring and common design problems. This consisted of identifying how solutions for these problems were implemented in the real world, conversing with designers on what factors they considered when creating such solutions, researching what patterns other companies use to solve the same problem, and making refinements to documentation based on feedback from designers. The objective of creating more pattern documentation wasn't to limit designers in what they could do, but rather show them how they could address common design problems as scale and complexity were introduced.
A design system is constantly evolving and as such, parts of it are improved over time. I improved components and documentation after pain points or feature requests were identified. To accomplish this, I made several iterations to explore potential solutions as we wanted to maximize the benefit a change or addition would bring. I refined iterations based on feedback until we honed towards a clear solution that was consistent with FreeForm's principles. Once an approach was finalized, I updated documentation, created specs, and worked with developers to implement the solution. These improvements gave designers more flexibility when tackling complex problems without substantially adding more elements to the design system.
As with all systems, FreeForm needs to be maintained by our team to ensure it continues to function as intended. This largely consists of testing, testing, and more testing. I thoroughly tested various components for accessibility compliance, verifying the component is working as intended after improvements were made, or just for routine testing. This was followed by writing tickets and collaborating with developers to address issues if there were any. The constant maintenance of our design system ensures that designers are always using tried and tested solutions to solve the problems of today, and tomorrow.
While I can't share the specifics of our processes, throughout my time here, communication has been a key factor in helping FreeFrom evolve. From consulting stakeholders during research phases, to working with developers to implement solutions based on detailed guidelines, communication kept everyone in sync with what they needed to do and what to expect from others.
I frequently communicated with managers, designers, developers, and other stakeholders when solving problems. I used tools such as JIRA to stay aligned with the rest of the product team, Abstract to gather feedback from designers, Microsoft Teams to sync with stakeholders, and good old PowerPoint to create and present insightful presentations to decision makers. My primary goal when communicating with stakeholders was to understand their goals, needs, and pain points. This gave me an idea of what shape or direction my work should take. For every task I set out to tackle, I always considered the bigger picture — how did it fit into helping the design system reach its goals? Was there an opportunity to provide more value if I expanded the scope of the task? What challenges might teams face if the solution was applied to complex problems? I believe asking questions in this manner helped guide my work to provide long-term value to the design system. Overall, frequently communicating with our stakeholders meant that I was creating solutions based on clear requirements that would be useful to them when using the design system to solve ambiguous and complex problems.
Focusing our efforts into three main areas helped move us closer to our goal of building the next generation of FreeForm. By making sure teams have the right tools and information available to consume the design system, the barrier to adoption is much lower than it was before. FreeForm continues to evolve and is better positioned than ever to solve the complex problems that arise as the company grows. The growing maturity of FreeForm benefits over 270 stakeholders spread across five locations globally, who use and consume the design system daily to achieve their goals.
My work included a mix of immediate and long-term impact. Solutions such as new pattern documentation or new component features had an immediate impact as they are being used to solve the problems of today. On the other hand, work such as a new CMS or migrating to Figma in the months to come will have a long-term impact as it will shape the way that stakeholders use and consume the design system. As this work is internal, I cannot share specific measures of my impact, but we have observed positive results from our combined efforts to evolve our design system.
Unfortunately, I can't share more details publicly as these initiatives are still in progress and have yet to be made public. I look forward in sharing more details on my website when it does. In the meantime, feel free to contact me at suhailjaffer3@gmail.com for more information.
I have practiced this in every new environment I work in, and this takeaway never fails to reap benefits for me. Nokia was the first company that I've worked at that already had established UX principles and processes. Because of this, there were a number of processes and systems I had to get acquainted with. Being curious and asking a lot of questions made this transition easier. I made an effort to understand not only the systems I used for work, but also the systems that I was contributing to. By doing this, I was able to learn of the different stakeholders involved, which made it easier to empathize with their needs. I also asked questions about the decision making process as I was curious about how decisions are made and the factors considered when making them in the context of a UX team in a global company. I'm grateful to have been supported by my co-workers and supervisors at Nokia during this process. They encouraged my curiosity and allowed me to drive impact in areas that I was passionate about.
My previous experience had me mostly working around design systems in Figma. This however, does not reflect the reality of an established and scalable design system. Things like design tokens, a comprehensive implementation and testing process, and thorough documentation are all elements that contribute to the success of a design system. This intricate web of components and their consumers made me think more about how my work fits in with everything, which leads to my next takeaway, always thinking about the bigger picture.
While not exploring new tools and processes, part of my work revolved around writing documentation. Writing documentation sounds boring at first, but it is one of the main ways that stakeholders consume your design system. It is one thing to write a paragraph of text, and it is another to write guidelines that are consistent with common patterns, your design principles, and guidance that you have given to other components with similar behaviours. Thinking about the bigger picture is important as it showed me how the little details can affect a much larger entity. It encourages me to ponder on potential implications before taking action, allowing me to make well thought-out decisions.
The way the community manifests itself around your design system can make or break how successful it is. This is why it is important to always engage with and foster the community you have around the design system. Implementing the next generation of your design system is enough of a significant change. Working on other major initiatives while making changes to the design toolkit adds even more complexity that your community needs to consume in order to maximize the design system's potential. We could have made major changes and pushed it all on a random day, but we felt that was not the right way to engage with our community. Instead, we included our community in the process as we make these changes, procedurally onboarding them so as to not overload them while giving them a chance to contribute to their source of truth. Engaging with your community is an iterative process, and I look forward to prioritizing community engagements in any solution I work on in the future.
© Suhail Jaffer 2023. All trademarks and copyrights are held by their respective owners.
