Building a Unified Cross-Project UI Framework

[Music] in the next 30 minutes i will talk about why building a ui framework can be beneficial for multiple teams a project's company how to approach the overview of our main ui framework components and about benefits but first i would like to make just a quick introduction my name is natalia rybrova and i started my career as a ui designer in games around nine years ago working on the aaa project but after that i was mainly focused on creating free to play mobile games in different genres and right now i'm a uib ux designer at cyber games but when i joined the company around three years ago we were only 40 employees and had a lot of ambitions to grow right now we have more than 100 we have multiple independent teams working on different projects but during that intensive growth it was very important to restructure the process of the ui development and make it more effective so why build a ui framework

several years ago front-end frameworks for web development became very popular and the accessibility of html css and java combined together with the software that allowed designers to turn their mockups into code let them focused on creating unified design systems and design itself rather than on implementation and it was a pretty big step forward but if we're talking about games building unity the situation is a little bit different unity ui system has never been perfect and it requires to know programming language like c sharp for advanced use nc sharp is much more complex in html and the third-party solutions like solutions you can find maybe in unity as a store are usually not well supported or poorly adopted for mobiles and of course some of you can argue and said sure there is still a lot of games that use unity ui so why wasn't it enough for us and we had two main reasons for it

and the first reason was that designers didn't have enough control over the implementation and this is the simplified version of the pipeline we had before the ui framework and the implementation part as you see completely belong to engineers mostly because of the complex complexity and it made the process of redesigning and iterating very slow and demanding and because designers didn't have enough control it sometimes led to aesthetic and interaction inconsistency and especially closer to deadlines and we also didn't have a good technical solutions that were unified across the projects and so the second reason was that very often multiple teams had to solve similar problems implementing in developing ui and designs and technical solutions varied and there was no consistency across the projects and you know when it happens player experience suffers and so does the company's brand and besides it was also very time

consuming it was very difficult to maintain and teams were less flexible because simply people had different set of skills and problems were sold differently and knowledge sharing is something not that happened that permanently in the companies and so back then we tried different approaches like making ui kids writing specifications making guidelines and the problem was that all those solutions were static deliverables that nobody wanted to use and it was also inconvenient to use and maintain them up to date with limited resources and it also required a lot of communications between designers and engineers and so the third party solutions that improve collaborations between also designers and engineers like for example zeppelin that used in like web design were just expensive and also were not perfect because required some communication between designers and engineers

but however we already knew one thing that if we could make an accurate and reusable implementation once we were much more confident in the design quality and it was also very easy to maintain it from one place and then shared it across the project and so that's why to unify our ui on implementation level we started to build our own ui framework how to approach so the first step for us was to define principles and components we wanted to reuse across the projects and the initial idea is based on atomic design approach where like it considers ui as a set of elements and behavioral patterns and i'm assuming most of you like pretty familiar with the concept well basic building blocks like atoms like patterns labels transitions even color palettes can be combined into more complex components like molecules that can be combined into organisms and organisms can be grouped into screens that provide

context and since the ui framework we built was meant to support multiple projects it consists of technologically unified components that can be skinned and combined into templates that can be then combined to the screens and reusable behavioral patterns and transitions and visual language was intentionally excluded and moved to a lower project best level because we wanted not just to create a ui system for a specific project but a universal tool that would allow us to create ui system for any project saving time and so after we had defined these principles and components we built them as a prefabs with a hierarchy that made sense for the desirable functionality with the minimum hierarchy and we actually had to rebuild most of the basic components that we already present in unity ui and we actually had to do it because even though ui framework expands unit ui

some of the components were not just suitable for us and the main reason was because they were not adapted for mobile and in some complex cases unity ui requires programming knowledge for advanced use and just to illustrate i would like to show you as an example one of the simplest ui framework component like the button and it has an improved structure for providing feedback and it also has moderate hierarchy and one of the biggest differences that we have is that the framework button has a hitbox child object that in basically is invisible image that defines the interaction area for the button and it's placed above the animated part it's placed above with the graphics so it prevents the situation of click not being registered in two cases when we interact with the small size elements in mobile or when due to scaling during the animation for example in the press state when

these small elements can become even smaller and just to show you so you can see at the top you can see the unity button and the unity collider scales together with the unity button when i press it and at the bottom there is a framework button and i have a selected hitbox and it stays the same so even i press it it still defines the interactable area for the button and it's the same and so framework buttons use only animators for providing feedback so we don't have an option like unity button that provides like simple feedback like tinting as pride but it's mainly because using animators we can actually create any type of feedback we need and plus it's very easy to reuse animators across the components with the desirable behavior and so the template we use for like framework button has an improved also animator

state machine that can be easily copied and adjusted and we improved some transition times and we also added a release non-click state for our buttons and we completely excluded hover state which only caused problems on mobile and other components like radio groups staffs toggles progress bars they all had gone from the same rework process and combined and composed of the library of the template assets there we of course have some special components we developed specifically for the ui framework like view config and transition config i will return a little bit later but instantiated this templates can be skinned animated and extended extended according to specific project style and then they can be added to a specific project style library which is like very custom we call skin assets and

their name may be not the perfect one because in skin acids it'll also can be included some components for example like combinations of components with a specific anchoring or hierarchy for different project needs and so it's very easy to instantiate them with one click from a specific window and to show an example how we use it i just want to show you a little video it's not a real game i just made this case specifically for this talk and so i have a preset of a pop-up and i want to fill it with the skinned assets and here just add some list item like two and then i want to for example to add a button just adjust the position [Music] and basically you can see how just like in a second i can create a variation of a pop-up using like this window without going anywhere and looking for anything else i can of

course also adjust some sprites or text and we know and we expect this to become obsolete after we start to use nested prefabs but we built the ui framework even before nested prefabs were announced last summer so we were pretty much satisfied with the solution so yeah it was fine for so far and the second reason the second step in building the iframe work for us was to provide freedom for non-engineers and it's actually one of the main benefits of the ui framework because right now designers can implement ui without a big necessity to code and it significantly reduces the iteration time between designers and engineers and also designers get much more involved in the implementation process and the use right now help from engineers only to create complex transitions or just when they need to work with data but even though

we right now also work on some solutions where designers also can start to work with data and it's much more easier for them to start testing the aesthetics and and it happens much early in the process and very important to say that it only became possible after we gave designers freedom to work with two main complex areas and these are navigations and transitions between the screens and controlling the rendering order of multiple layers including 3d because let's be honest just to add some sprites in the projects and make layouts in unity it's not that difficult for designers but if we're talking about creating transitions and flows this is where like things get difficult and to dive into the details i would like to present one of our main component in the ui framework the slice and the slices

serve as containers of canvases graphics and cameras and a slice can be built as an entire screen like loading screen or 3d model or they can be built as a part of the screen like for example pop-up or top bar or bottom navigation bar and so on and so the framework slice template consists of a root object with freeman children and those are cameras graphics and animation targets and let's take a close look at each cameras so the slice template comes with one autographic camera per default it's because it's most commonly used cameras for 2d graphics if you of course we assume that we have our ui is 2d and we can add as many cameras as we want but if it serves a purpose but of course we should be mindful about the performance and the usual case where we need multiple cameras can be when we need to

render both 2d and 3d and so we can use autographic and perspective cameras accordingly and so added cameras they just got automatically referenced in the field we called camera list and the order of the cameras uh determines the rendering order and it where this like last camera is rendered topmost and was pretty much inspired by unity render order unity ui and so at the end we can easily build multiple layers operate with them and correctly build a hierarchy just in a short period of time and if i want to change the order of the cameras i just don't need to operate with any values i just need to drag the camera i want to render topmost at the bottom of the camera list and that's it and it's very neat and the designers really like to work with it where they don't need to

assign any like camera depth and so on graphics acts as appearance for all the graphics contained in the slice and the children of the graphics expect to be canvases and because it's where the 2d gets rendered and the children on the canvases expect it to be slice panels and this is another ui framework component which is very important for us because slice parents they of course parents of graphics assets for our slice and they are also very similar to your generic unity panel but it has an added component that allows us to associate this panel with a specific animation target and animation targets is actually our favorite feature that we develop for this ui framework because animation targets they propagate animations for our slice panels and this is the way for us to reuse animations across all slice panels

in our projects independent of amount of children and naming and if you have ever worked with the unity animation system you probably know how painful it can be to be tied to specific naming if you want to reuse like an animation and it's right now it's possible because it's basically an abstraction layer that allows us to reuse animations because we are assigning just an animation target type to a specific panel so we don't care what's underneath it we don't care how it calls but we just assign the type and i would like of course to go into more details but i would need a longer presentation so let's move on and so to assign and execute these animations we need to use our slides somewhere and for that purposes the ui framework has another component we called viewconfig and this is basically a recipe for our ui system about how to build and present

the view or if you can onetech you can call it a screen and so we need to fill in the information the system needs to know about how to build this view correctly and if you can config can include one or multiple slices it has to have at least one slice and slices also can be shared across the views and again the rendering order defined by order like when i like add our my slices in this view config and it's also very easy to manipulate with this view in run time so to illustrate i have another small example so here i have a view config that i called inventory screen and please notice it doesn't have a top bar here and what i need to do is just like in the inspector i just need to add another slice i need to reference it

so let's say it's top bar it's the same top bar i have in the character screen and it immediately added this top bar in the inventory screen view so it's pretty easy it's very fast and it really literally takes seconds and i can do it one time so i can reshuffle all my small pieces of my ui and create different combinations so the benefits are the redesign and iterations right now are very fast and once i broke down my ui into like small pieces and assembled them i can combine different setups and it's just a matter of seconds and the render order of the slices in the view config defines the rendering order and it's also very easy to show or hide previous views it's just like a matter of ticking the checkbox so if i want to hide the previous view behind the pop-up

i just opened i can just easily do it and after we have defined the view the ui systems knows what to show but it doesn't know how i mean in the previous example it already knew how but for knowing how it needs another component that we call transition config and the ui framework provides transition examples for different configurations like sliding scaling it can be instant transitions or it can be absolutely custom animation and after that all these transitions can be copied adjusted and they can easily be assigned for every view config and so to show this also a small example how we use transition configs so here i have a pop-up with settings which has an animator pop-up transition config and it looks like this so you see the background fading

like pop-up is scaling and what i want to do is just change it to the slide right transition config that i created before like both hiding and showing and as you can see immediately will apply the changes so the benefits of the transition config so the main one is that it operates with the whole slice panel through the animation target which is again an abstraction layer that allows us to reuse animations across all slice panels without depending on object naming and they can be also reused not only across the views but also can be reused across the projects so if we work with multiple projects that want to reuse the specific transition between the screens we can easily do it without like redoing it again and again and it allows us to create different

combinations of animations for multiple slice panels in one slice so as you saw before i had like a combination of a background that just was fading and the pop-up content was scaling and it's possible because i just broke down my content to two slice panels which has two different animation target types and so right now i just would like to show you how we execute animations or navigations using the ui framework because i mentioned it is very easy just to create flows and this is also just a small example so now i'm just running a project and i have a starting prefab where i can assign my starting view and right now it's a splash screen kind of a splash screen i can use any and as you can see this has a

view has a button a start button right now it does nothing but let's assume i would like to execute navigation to another screen the character and so what i need to do is just to find this button in the hierarchy and i need to add one navigation script and then i will have a field with animation target this i am adding a view i want to navigate it's like gtc start u and then i just need to add a function navigation execute navigation and that's basically it and i didn't touch any transitions so it will happen instantly let's just press apply and i can operate it like with any button so press and navigation happens so as you can see it's super fast it's very easy for designers to just start create these views

and it's not only fast but right now i'm doing the uh animated prototypes not using other software like before i use like principles and principle in sketch but right now i'm just using unity because it's so much easier and the result looks like the final result and just to make a quick maybe recap i would like to yeah to say that your dui framework is built around this concept of navigations between the views that reference slices and navigations are requested to be done between the views and views can reference one or multiple slice and slices are responsible for containing graphics and logic and in specific cases like slice panels and animation targets and slices can be included in one or multiple views and they can be shared across and the navigation transitions right now

can be built by a designer and once they build they can be easily reused across the views and also across the project and it's easy to start prototyping inside the project saving time technical unification so interaction design principles and basic ui architecture is unified to maintain the holistic design and is very much less time consuming and requires less resources to develop and to maintain so we have right now like one or two dedicated engineers that help us to maintain the ui framework it's also much easier to drive the ui innovations so once a good solution is found and implemented in the ui framework all the projects got the benefits of using it and of course in-house development allows us to adapt it very fast to all technical needs and not wait and yeah it's just

really nice but of course it's very important to remember that building a ui framework is not just a silver bullet and we still complement it with other tools and just to give you an example that we still use like text mesh pro style sheets for coherent typography so it's like the place we control all the text styles for the projects and we can easily adjust it and then we'll propagate the changes across all the textiles we need we work with the decelerated assets and we use unity color color library and easy very easy to adjust these color palettes and it will also propagate the colors across all the assets yes with the nested prefabs it will be much easier and we're also waiting for it and yeah we also draw all our assets disregarding the project style in vector and we are working right now on integrating nswg importer to unity

and to support the original assets inside the project so we can always have original assets inside the project and keep them up to date and if we need to correct something we just need to open it from unity project and save it back and we still use unity ui systems in sketch and we still use other software for creating prototypes especially in the concepting phase so there are still a lot of things that support our ui framework and so at the end i just want to say so it doesn't matter how you build your yoif frame framework but having a living design system of components interaction patterns inside the projects can give you a lot of benefits and it's not right now for our engineers or game designers to start to use this ui framework and start creating good looking screens just opening the project because all the

guidelines are already inside it you don't need to go and look to other guidelines so like re-documentation and of course first of all ui framework for us was a time-saving measure that allows our designers to focus on research design and testing rather than on implementation and i think that's it thank you so much for listening [Applause] i think we have some time for q a just four minutes maybe several questions if you have i have a small question if i may um could you share with us like how big was the team developing the ui framework or how much time did you guys take to develop that framework yeah actually

we had one year of one engineer's time that worked dedicated like work on this thing with the support sometimes and advices from others engineers but mostly yes it's a one engineer that helped of course you shouldn't probably just put the ui framework on engineers because they don't want to work with ui usually but yeah it's it's not that much it wasn't too bad thank you of course hi hi yes i would like to know if you came up with the need to make debugging tools for your ui framework i mean we i mean it it all happens inside the tools team so the engineer who worked on ui framework is a was a part of the tool stem and we

still have like a bigger thing for our internal components and inside this thing this uh like i mean the question was um because if the you know sorry the designers and these other persons in the team who doesn't have the technical skill and maybe they have problems and you have to go to the programmer who make the tool for support i mean if you have that kind of problems in your project now the thing is our teams are pretty small and we have usually one ui ux designer per team so we yeah i mean if something is wrong it's very easy to communicate so i think our ui ux designers like tested to like themselves usually yeah

i know that we use a similar system okay but um especially with transitions yeah um and input i know there's if you oh qa really love to just keep tapping things so how does it know what the top most one is so if you have like the slide transition and push push the button to open it and then push it again because they're like um like does it know what the most so the rendering order defined by order i placed the slices in this view list so if i want to change it i just can drag it like it's that's the beauty of it because it's just super easy you don't need to like mess with numbers or anything so so the ui well if you tap anywhere on the screen it'll know like don't interact with the screens behind yeah did i run it okay of course yeah

it's just completely different view so if you navigate to another view it just open we just can choose to show or to hide the previous but you won't be able to interact yeah we also like i remember this thing hi hi um i was wondering you mentioned uh data bindings and how you plan to rule out sort of yeah it's in the plans can you elaborate or is it still something very yeah it's still in our plans actually because it's not something that you you we're already testing it but i wouldn't like go into my explanations it's yeah but it's still in development right now all right yeah i understand thank you but it's definitely will make our lives much easier i think this was the last question yeah i think we can continue in the whole if you want you're very welcome thank you so much again