
Theres no making without breaking
uxdesign.cc
An animated comic illustration of a Fortnite character looking up and to the right, while a city burns in the background. Credit:Me.Fortnite wasnt a hit when it started. It was a totally different game back then. No battle royale, no millions of dollars in prize money, no Mariah Carey frozen in an ice block for Christmas. Originally, it was a third person, tower defense game. Youd gather resources, build a base, and you and your friends would prepare to be attacked by a torrent of horrible zombies. You worked alongside others to free survivors and combat thehorde.It didnt sell well. In fact, before being inspire by PUBG, it was almost cancelled. But they pivoted from their original idea. They looked around at other game models and listened to their user base. And they made out with bookoodollares.I think that the process of making video games lends itself towards making. You have to make a game in order to show it to someone and have them play it. Then, judging by the joy or frustration on that persons face, youll make changes and tweaks to improve thegame.Lets make morethingsIn software, particularly big software companies, Ive seen a different trend. Ive seen a lot of talking, planning, and twiddling. Oftentimes, there way less making than I would expect. And, I think that it comes from a fear of judgement. Because, with the making, comes judgement.But thats a fear that we need toface.If we really want to make things that are useful for other people, the only way well be able to do that is by making something to be judged. We cant build things in avacuum.Dont get me wrong, Im not saying that we shouldnt plan. Plans are great! Lets do our research, understand the problem, and cast vision for the future. But when the rubber hits the road, we need to makestuff.Were not always going to know what the right thing to do is. Sometimes (most times) there isnt a right thing. The path is obfuscated. Maybe were trying to serve other people, but were afraid of making a mistake. What if our mistake hurts the people were trying tohelp?But, if we do nothing, were not helping at all. Were not making thingsbetter.I dont think we should let our fear keep us from at least trying to make thingsbetter.And if we make something that messes things up, we can fix it. We can talk all we want about an idea, but until we actually make something visible and tangible, they wont know what the hell were talkingabout.People need something to respondto.And when we make it? People will give us feedback! We can use it! We can make it better, more effective!!!As long as we keep iterating, well make something great.Starting withresearchHeres where I was four years ago. I had just started my role at Cisco. It was my responsibility to breath new life into their design system, Momentum. This design system was used to create consistency within the Webex App. But there were a few problems that we needed to dealwith.I didnt know anything about this system, how it was implemented, or how people usedit.It spanned five different platforms, with varying degrees of differences depending on the operating system.All the components in those platforms were custom built; no UI toolkits.At the time, I had one designer on my team and we doubled down on our curiosity. Claire and I put together a research project, interviewing designers and engineers across the Webex App to try and understand what Momentum was and how people were using it. At the time, the Webex App was undergoing a complete rebrand. The entire UI was being evolved, and the transition was pretty difficult. People were building the plane as they were flyingit.We surveyed over 30 users and conducted research interviews with 20 participants across the organization. We used the findings from this research to help solidify our mission as a design systems team and specifically target the areas that we wanted to improve with Momentum.Here are some of our key insights:Give us clarity: Participants communicated that they wanted to have a better understanding of the current state of the design system, where its going in the future, and who has ownership ofit.Build a yellow brick road. Onboarding to the design system is particularly difficult here, because it requires so much one on one time to transfer knowledge. Theres a need for better tools and processes used for onboarding, collaboration and system improvement.The system lives inside a select few. It is currently impossible to learn the design system without facetime with experts. We need more solutions to become familiar.Build the machine. Users of the design system want more tools, processes, and resources to build effective and efficient solutions.Rebalance ownership with engineering. Better collaboration and communication is needed across design and engineering so that we can be on the same page when it comes to components, process, and language.More thinking through making. We need to have methods for evolving our system. How do we approach product evolution in a systematic way? How do we incorporate conceptual thinking and cast vision for the future while still delivering producttoday?Breaking things to make thembetterWriting down our guidelines All the information of Momentum was housed inside the heads of a few designers. They were archons; gatekeepers to the halls of software consistency. They gave out their advice and guidance to others, but it was slow. It wasnt scalable, and our features were often blocked, or the design system was ignored completely.Being new to the team, I didnt know how our system worked. I was unfamiliar with our components, colors, and processes. So, I did what Ive learned to be one of the most powerful tools for organizational influence: I made friends. I got to know each and every one of these design system leaders and scheduled a regular meeting with them to discuss common design patterns used in oursystem.Oftentimes the meetings would revolve around a specific issue for a component or design pattern. A question about the dialog component would come up from a feature designer and we would discuss how to answer it with clarity, and make any necessary updates to the component in thelibrary.An example of our Grid and Layout guidelines to help designers understand the importance of spacing consistency.My team and I distilled the information that we learned in various guidelines which we then used to format all our information on our iconography system, layout, illustrations, color tokens, typography, and accessibility.Any time we got a recurring question in office hours, or received multiples of the same request, we used what we learned as an opportunity for something that might be written in our guidelines.An example from our Design Token Guidelines.A brand new process In 2021 when I started, the Momentum Design system consisted of 4 Figma libraries for each of the Platforms that Webex was on (Windows, MacOS, iOS, and Android). A decision was made that the UI of Webex should lean native, ie leverage operating system components where appropriate. This has since bit us in the butt, as a lot of these operating systems core components arent as accessible as we need, but thats another story entirely.A FigJam board with the results of our design system change process workshop.The libraries were maintained via a guild model, with quite a few designers having access and adding components whenever the need arose. This led to massive discrepancies between the libraries as well as an unclear process for new component additions. My team and I were having multiple conversations during the week, being asked to add a new component to our figma library, because its already being built in product. To top everything off with a cherry, none of the platforms had UI toolkits. Components were being built as part of feature work in a completely custom and unscalable way.We had very little control or oversight and inconsistency reigned. We needed to stop themadness.I facilitated a workshop with my team and several key designers who had been on the design system guild where we discussed and created the Design System Change Process. This took work, but was the first milestone in creating order amongst ourchaos.We ran a weekly Office Hours where designers with questions could come and ask questions about their feature work. We used it as an opportunity to share the new component creation process, as well as several teams weekly Show &Shares.We implemented a Momentum Request Form where people could submit requests to our team and they would be stored on our backlog for review and work at a laterdate.All this helped create a stop gap for the massive amounts of changes going into our component library on a dailybasis.The final Momentum Change ProcessChart.Restructuring our Figma Libraries While reviewing our four figma libraries, the obvious thing that we noticed was an inconsistency in component naming. In the Windows library, the Banner component would have its own page. But in iOS, it would be on an Alerts page with Dialogs and Toasts. These inconsistencies made navigating the libraries, and building features across platforms extremely difficult.My team and I (at this point Claire and I had another designer, Morgan) met together several times to discuss how we might approach figma component library alignment.How we used to organize our components on layers. Lots of similar components were on the samepage.Our new way of organizing components. We start with Core Components, then Native Components, and then Product Specific Components.There were three potential strategies that wesaw:Individual components; grouping individual components on their own page, listed out alphabetically.Group by usage; multiple components with similar features or applications would be grouped together on the samepage.Group by complexity; this is something that Brad Frost discusses in his atomic design model when showing the difference between Atoms and Molecules.I proposed to the team that we list out our components individually, and group them together by Core Components, Native Components, and Application Components. Because we wanted to align four different platforms, I felt it necessary to show what all the libraries had in common in the Core Component library and relegate any operating system components to the native section. The Application Components was honestly a free for all. So many strange and unique cards, widgets, or list items were placed there because they could not be used in more than one part of theproduct.This update was one of the biggest that we made. It had the greatest effect on designers daily lives. We were really worried that these new changes might impact or impede their workflows.ConclusionThroughout this process, I was sweating. As design system designers, the things we make and maintain have an immediate impact on the designers around us. I didnt know how they would respond to the huge amount of change in their libraries and processes.A year later we performed another user research project on design system usage. This time around, we were able to increase our overall scores for Momentums ease of use and understandability. Theres still a lot of work ahead of us, but were ready to both break andmake.ReferencesOriginal FortniteTrailerFortnite was nearly cancelled years before it became a global phenomenon, according to a former employee of Epic Games BusinessInsiderPrototyping: Turning Ideas into TangibleProductsMove New Ideas Forward in Your Organization IdeoUAn illustration of the author waving. Credit:Me.Hey yall! Im Trip Carroll, a design leader at Cisco and aspiring cartoonist.I write and publish a new article on design, leadership, and software development every other Monday. You can see more of my work on my website, check out my drawings on Instagram, or subscribe to my newsletter on Substack.Lets make workgreat!Theres no making without breaking was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
0 Comments
·0 Shares
·19 Views