Follow-Up: RE ENGINE UX Overhaul

Follow-Up: RE ENGINE UX Overhaul Let‘s get started with “Follow-Up: RE ENGINE UX Overhaul.” Previously, at the 2019 Capcom Open Conference, we presented “UX Overhaul : User-Centered Design rework of RE ENGINE.“ It has been about 4 years since then, so this time, I would like to share with you what has happened in the meantime. -------Python® is registered trademarks or trademarks of Python Software Foundation. ©CAPCOM 1

Topics this time Topics in 2019 ・Introduction ・Defining the "end user" ・So, what happened? ・Improving programmers‘ development environment ・Example of improvement with ShaderGraph ・Division of labor with designers ・Designers' perspective ・Tool Improvement Process ・Motivation for improving UX ・Design Concept ・UX Design Philosophy ・Defining the "end user" ・Development Structure ・UX Improvement Process ・Design Prototyping ・Usability Testing ・Promotion ・Feedback ・Conclusion ・Conclusion This is what I will be sharing with you at this time. In 2019, I presented the topics shown on the right side of the screen. ©CAPCOM 1 2

Topics this time Topics in 2019 ・Introduction ・Defining the "end user" ・So, what happened? ・Improving programmers‘ development environment ・Example of improvement with ShaderGraph ・Division of labor with designers ・Designers' perspective ・Tool Improvement Process ・Motivation for improving UX ・Design Concept ・UX Design Philosophy ・Defining the "end user" ・Development Structure ・UX Improvement Process ・Design Prototyping ・Usability Testing ・Promotion ・Feedback ・Conclusion ・Conclusion We will be updating information on the highlighted areas in 2023. 2 ©CAPCOM 3

Introduction First of all, I will discuss the tool development must-haves, as well as developers' motivations. 3 ©CAPCOM 4

Introduction Non-negotiable requirements Nice-to-haves 1 Fit for purpose 4 No incorrect labeling 2 Stable operation 5 Difficult to operate incorrectly 3 Operates at high speed 6 Roughly the same feel of operation between other tools 7 Clean appearance Priorities for tool implementation First and foremost, as a basic premise, this is what we consider to be the order of priority in tool implementation. The first priority is to be able to do what we want to do and to operate in a stable and fast manner. Before this is done to some extent, it is difficult to talk aboutthe look and feel of the operation. ©CAPCOM 4 5

Introduction Non-negotiable requirements Nice-to-haves 1 Fit for purpose 4 No incorrect labeling 2 Stable operation 5 Difficult to operate incorrectly 3 Operates at high speed 6 Roughly the same feel of operation between other tools 7 Clean appearance Priorities for tool implementation 1, 2, and 3 are the base requirements. 5 ©CAPCOM 6

Introduction Non-negotiable requirements Nice-to-haves 1 Fit for purpose 4 No incorrect labeling 2 Stable operation 5 Difficult to operate incorrectly 3 Operates at high speed 6 Roughly the same feel of operation between other tools 7 Clean appearance Priorities for tool implementation 4 and 5 are important for trial and error testing that’s done repeatedly to make games interesting. 6 ©CAPCOM 7

Introduction Non-negotiable requirements Nice-to-haves 1 Fit for purpose 4 No incorrect labeling 2 Stable operation 5 Difficult to operate incorrectly 3 Operates at high speed 6 Roughly the same feel of operation between other tools 7 Clean appearance Priorities for tool implementation 6 and 7 are also important for trial-and-error testing, as well as for reducing both the cost of learning to operate the tool, fatigue when using it for long periods of time. 7 ©CAPCOM 8

Introduction Non-negotiable requirements Nice-to-haves 1 Fit for purpose 4 No incorrect labeling 2 Stable operation 5 Difficult to operate incorrectly 3 Operates at high speed 6 Roughly the same feel of operation between other tools 7 Clean appearance Priorities for tool implementation Some items are mandatory to achieve and some are for betterment. How we are trying to improve RE ENGINE is the theme for today. 8 ©CAPCOM 9

Introduction MT FRAMEWORK RE ENGINE Development continues to grow in scale Simultaneous development of multiple games 2000 active users (From 2019's presentation) As we announced at the 2019 Open Conference, development has become large-scale. Especially on the title side. 9 But in the case of RE ENGINE, there is a massive scale of development laterally, with multiple games being developed at the same time. ©CAPCOM 10

Introduction Development continues to grow in scale Simultaneous development of multiple games 2000 active users User-side tool extensions now standard Naturally, many of the tools RE ENGINE provides are general-purpose, and not all of them are suitable for specific games, so it is natural for users to expand the available tools. 10 In particular, title developers need to create tools for adjusting game progression, character customization, and other parameters. However, we will not discuss this title-side tool development in this presentation. ©CAPCOM 11

Introduction Tool Developer's Desires Because of this, continual UX improvement has become an even more important element of RE ENGINE. So, what motivates individual tool developers and individuals to improve UX? 11 ©CAPCOM 12

Introduction I want to meet these demands ・High quality engine ・Rapid iteration Tool Developer's Desires First, we want to meet the demands surrounding game development. RE ENGINE as a whole wants to follow the direction RE ENGINE is heading. 12 ©CAPCOM 13

Introduction I want to meet these demands ・High quality engine ・Rapid iteration I want to succeed ・I want to please users ・I want to make something good Tool Developer's Desires ・I want to have fun making it Next, there's the desire to succeed. You want to please users, you want the sense of accomplishment of having created something good. Also, tool development itself is fun. ©CAPCOM 13 14

Introduction I want to meet these demands I want to avoid these things ・High quality engine ・Rapid iteration ・I don't want to get bad feedback ・I don't want to do things I'm bad at ・The UX police will track me down I want to succeed ・I want to please users ・I want to make something good Tool Developer's Desires ・I want to have fun making it There are also things we want to avoid. We don't want users to complain about our tools, and if we're not good at tool development, we usually don't want to actively do it. 14 Another reason may be that we want to avoid being hounded by the UX police. There are a lot of people developing tools, so whatever the motivation, active or passive, positive or negative, as long as it ultimately leads to UX improvement, anything goes... ©CAPCOM 15

Introduction We asked this question in 2019. We asked this question in 2019. 15 ©CAPCOM 16

Introduction We asked this question in 2019. Does this sound familiar? "Not to put you all on the spot, but do these situations sound familiar?" 16 ©CAPCOM 17

Introduction You ask the programmers for a tool, but the buttons and tabs take up half the screen... The programmers, made you a tool that does what you asked for, but it's just an expanse of buttons and tabs in a row. 17 ©CAPCOM 18

Introduction You ask the programmers for a tool, but the buttons and tabs take up half the screen... Similar editors but with completely different design aesthetics... You have similar tools, but with completely different aesthetics and feels. This was actually happening with our node graph-type tools. 18 ©CAPCOM 19

Introduction You ask the programmers for a tool, but the buttons and tabs take up half the screen... Does this ring any bells? Similar editors but with completely different design aesthetics... I'm sure you have all experienced this, right? 19 ©CAPCOM 20

Introduction Issues in Tool Development Program Issues ・No design guidelines, causing confusion during implementation ・ Which style of button is appropriate? ・The programmer's aesthetic shines through! (In a bad way) Design Issues ・The person implementing it is in over their head. ・...Often due to not having been given enough time User Issues (From 2019's presentation) First, problems on the programming side. The programmer is not surewhat kind of design to use, and cannot decide on the goal of the UI design. As a result, it is left up to the programmer's sense of aesthetic. 20 Also, lack of time is a major factor. ©CAPCOM 21

Introduction Program Issues Issues in Tool Development ・Lack of uniformity The same spanner icon means different things in different contexts ・Appearance and operation ・Overuse of a single icon Design Issues ・Different icons with the same functionality ・Same icons with different functionality ・Buttons not lined up evenly ・The meaning of the UI is not conveyed User Issues (From 2019's presentation) Design problems include a lack of uniformity, look and feel, and clunkiness. Cases where icons aren't suitable for their role, etc., can easily occur. 21 ©CAPCOM 22

Introduction Program Issues Issues in Tool Development ・It's useable, but... Design Issues ・Frustrating They only SEEM ・Takes some getting used to like small issues ・Small issues, making it difficult to prioritize for improvement User Issues (From 2019's presentation) From the user's point of view, they feel that if they just put up with it, they can use the tool. Even worse, the problems are small enough that they don't get prioritized. 22 ©CAPCOM 23

Introduction Program Issues Issues in Tool Development Culmination of issues Design Issues User Issues When you put all of these issues together... 23 ©CAPCOM 24

Introduction Program Issues Issues in Tool Development Culmination of issues Design Issues Workflow Problems User Issues What you get is workflow problems. 24 ©CAPCOM 25

Introduction Workflow Problems ・One part of a toolchain has a (seemingly) small problem The culmination of the problem is workflow problems occur and degrade efficiency... Work Work Work Flow (From 2019's presentation) The dysfunction of one tool, 25 ©CAPCOM 26

Introduction Workflow Problems ・Users end up creating an elaborate workaround The culmination of the problem is workflow problems occur and degrade efficiency... Work Work Work Work Work Flow (From 2019's presentation) can result in workflows containing bizarre workarounds. Often, workflow problems are the result of trying to avoid tool problems. It goes without saying that anything leading to such behavior should be corrected as soon as possible. ©CAPCOM 26 27

Defining the "end user" Next, let's look at how we define the end user. 27 ©CAPCOM 28

Defining the "end user" ? When developing a tool, it is necessary to define the end user. This hasn't changed since 2019. 28 ©CAPCOM 29

Defining the "end user" Wide user range Game development, RE ENGINE included, has a wide range of users. Therefore, we needed an absolute standard that would not get lost when developing tools. 29 ©CAPCOM 30

Defining the "end user" Wide user range Criteria division by technical skills The end-user is not defined by what they make or what they are responsible for, but by their technical skills, which represent their problem-solving abilities. 30 ©CAPCOM 31

Defining the "end user" RE ENGINE Programmer What are Technical Skills? ・Needs someone to help them to solve problems Consumes advanced users' time Technical Skill Level ・Ability to solve problems on their own ・Support Costs Capable of extending RE ENGINE Capable of extending with Python® Understands RE ENGINE workflow RE ENGINE Beginner Supporting the group with lower technical skills is expensive Most end-users Technical skills are not skills that allow you to create something amazing, they are the skills to be able to solve a problem on the tool by oneself. 31 End-users are basically defined as those who are not able to solve problems on their own. In short, they are the group that is most likely to call on someone else for tool support. The goal is to have tool developers share a common set of firm standards, as opposed to vague standards, of ease of use and clarity for end-users. ©CAPCOM 32

Defining the "end user" About Support Costs Most users are end users ・Support Costs Consider technical skills and number of people Technical Skill Level ・Number of users and groupings Most end-users If you think in terms of "this tool is hard to use, we should make it better," the tasktends not to get prioritized. However, thinking "if we don't improve this, the support costs will be huge," makesa much stronger argument for prioritization. 32 Even if the support request doesn't come to the creator of the tool, probably asenior user is supporting it, and they'll be the one to request improvements. ©CAPCOM 33

So, how'd it go? So, how'd it go? How have our tools fared since 2019? 33 ©CAPCOM 34

So, how'd it go? Past Present ・"As long as it works..." ・Find out how the tool is used from the start ・The UI is a mess, but we'll ignore that... ・A degree of attention is paid to UX ・Right clicks and mysterious hotkey combos ・Still pretty unresponsive ・Unresponsive ・Button size mismatch ・Uniform button size and margins ・The borders don't match... ・Behavior consistent between panels ・Margins often missing ・Display discord eliminated z z From left to right, past to present. I still sometimes hear "as long as it works...," but not as much anymore... I also feel that I hear more and more conversations about the feel of the operation and whether it is in line with the user's 34 intentions from the beginning. As a result, even when UX designers are not involved, some care is been taken. ©CAPCOM 35

So, how'd it go? Past Present ・Nobody wants to hear about design ・Programmers can consult with UX designers ・Engine developers not interested in UX ・More cases where UX designers are included from the beginning ・Different UX depending on who implements it ・The feel of the tools is a recognized issue and is being improved In the past, talking to programmers about usability was a hassle. It still is, but programmers now have the means to consult with UX designers before implementing. 35 Tools are developed by different people, but the users are the same. Issues raised by users have put design mismatch on the radar, and we've been able to make improvements. Users also began to request that UX designers be involved in the development of new functions from the beginning. Users have come to recognize that better tools are created when UX designers are involved in the development process, rather than programmers alone. ©CAPCOM 36

So, how'd it go? Past Present ・State often expressed only with color ・UI misalignment and minor color differences have been reduced ・No one supervised the color scheme ・Icons and colors have different meanings depending on the tool ・Primary colors are often used ・Primary colors are not used much anymore ・Old icons are still there In the past, programmers did UI/UX design, so the state of objects in a tool tended to be represented by color alone. The difference in color alone is expensive to learn, and even if you learn it, you will forget it quickly, so it cannot be used 36 too often. ©CAPCOM 37

So, how'd it go? Past Present ・Programmers do their best to prepare icons, but get discouraged... ・Select icons from Visual Studio Image Library ・Icons and colors have different meanings depending on the tool Icons are not just a picture of the subject described; they are used as a means to provide value ・Icons scaled to fit, so appear blurry It may be natural for programmers to choose icons by color, since they can't create icons themselves and are just picking from what's available. 37 By having a UX designer, the options have been expanded to include icons expressing form, color, layout, and operation. ©CAPCOM 38

So, how'd it go? "The tool is almost ready! UX, take a look! Release is tomorrow!" When we first started talking about UX improvement, this was often how the conversation went: "The tool is ready, now we just need UX to have a quick look at it! Then we’ll release it tomorrow!" 38 This is definitely a gateway to UX improvement... ©CAPCOM 39

So, how'd it go? "The tool is almost ready! UX, take a look! Release is tomorrow!" Failure Only a small portion of the UI can be adjusted at this point ・Make sure team programmers understand that this is a bad idea ・Make people aware that UX designers need to be involved in layout and usability But it's not the right way to do it. They understand the spirit of UX improvement, but the means are not yet in place. 39 For the next time, I think it would be a good idea that we create an environment that will allow us to consult with them sooner rather than later. ©CAPCOM 40

Improving Programmers' Development Environment We introduced the areas that have changed between the past and the present, but we also needed to make improvements regarding the development environment for programmers. 40 Not only the participation of UX designers and their willingness to do it, but also implementation support is needed to make this a sustainable effort. ©CAPCOM 41

Improving Programmers' Development Environment Past Present NET Framework 4.8 .NET 6.0 WPF WPF C#7.3 C#10 Visual Studio 2019 Visual Studio 2022 The tool's code is changed by more than 10 units—more than 100 people! Related Sessions RE ENGINE Philosophy RE ENGINE's Past and Future First, the tool development environment has changed with the times. All tool code has been updated from .NET Framework 4.8 to .NET 6.0, and many things have changed accordingly. NET 6.0 has a lot of disruptive changes, so we have planned and implemented the changes very carefully in advance. 41 Since there are quite a few tool developers, the enhancement and standardization of the tool infrastructure part has a significant impact on development efficiency. The structure and scale of this development are described in the separate sessions, "RE ENGINE Philosophy" and "RE ENGINE's Past and Future." ©CAPCOM 42

Improving Programmers' Development Environment Set XAML coding rules for WPF Unified design-related programming How to specify resources Development of basic controls Icon usage Maintain a library to make it easier to follow the rules We established XAML coding rules for WPF to ensure programming consistency, set standards for icons use and how resources are specified, and maintained and enhanced basic controls. 42 In other words, we maintain design-related libraries to make it easier to follow the rules and consult with the library maintenance staff if there are any problems. ©CAPCOM 43

Improving Programmers' Development Environment Development of design guidelines ・Designation of color, icon, size, etc. ・Combined layouts require design knowledge Programmers can only handle the basics ・Consult with UX designers on a case-by-case basis ・Support environment is required when writing programs Design guidelines are created for basic areas. They give programmers simple color and icon usage rules, and specify sizes and so on. 43 However, basic knowledge of design is required for layouts, and consultation with a UX designer is necessary for layouts that are combined and applied. For programmers, a support environment for writing design-related programs needed to be enhanced. ©CAPCOM 44

Improving Programmers' Development Environment Markup extensions to explain usage ・Basic WPF resources are accessed via markup Converter ・No exception raised for StaticResource ・MergedResourceDictionary not required ・By being kind to XAML IntelliSense, compilation target and usage points can be identified Brushes, Colors The WPF resource specification method is now easily handled by markup extensions. WPF resources require forward declarations of keys. 44 Writing forward declarations is tedious, so if you use MeregedResourceDictionaryto make it easier, you will end up reading the same WPF resource twice in each XAML. Since XAML itself is not compiled, resources are loaded in duplicate as described, and as the tool grows, it slowly becomes heavier, and as a result, it becomes unusable. Those familiar with WPF may know that there is a way to describe it in App.xaml. You can, but using the markup extension makes it a compile target, making it easier to track usage. In addition, it is possible to program with confidence because StaticResource exceptions won't be thrown. ©CAPCOM 45

Improving Programmers' Development Environment Redesigned basic controls ・Fulfill requirements and optimize ・ Eliminate desire to create variants Sample Control View ・Displays an interactive catalog on RE ENGINE ・Deprecated controls have warning icons ・Engine developers and title tool developers both see this view Various basic controls were re-examined and redesigned where necessary. RE ENGINE also produces basic controls in-house. Sliders, in particular, tend to multiply due to demands for different handling of value ranges. If a control is cumbersome, people end up creating their own versions. 45 We have re-examined these issues, and as much as possible, we have satisfied the requirements and optimized them so that they can be used as an extension of normal usage. The controls we want used can be viewed as a catalog in the Sample Control view. Controls that we do not want used for various reasons can be marked with a warning. Both RE ENGINE tool developers and game title tool developers see the same view. ©CAPCOM 46

Improving Programmers' Development Environment Image output available Easy to create manuals Description Make size regulations and Restrict usage in unwanted places limit misuse Making the various icons visible at a glance in-engine The icons that were frequently misused can now be checked for their intended use in the icon view. The use of the icon will no longer be based on a vague impression. It also makes it easier to consult with UX designers, or to check the icons on the UX designer's side. 46 The icons are in vector format, but there is a button to output them as png images, making it easy to use them in presentation materials or manuals. ©CAPCOM 47

Improving Programmers' Development Environment It's still not enough Writing in detailed design adjustments Style ends up applied manually Text manually set to white in TextBlock color property Manually writing Some parts are still using People learning from old XAML Margin = 2, Margin = 0 the old XAML style property not getting new information However, margin adjustment is still necessary, styles are being applied manually, and style must be applied for different modes of operation. 47 Sometimes, the foreground text color of TextBlock is set to White and the text becomes dazzling. Best practice information is no quite getting around. We believe that more support on the library side, correction of old code, and standardization are needed. ©CAPCOM 48

Improving Programmers' Development Environment Incorporate tool creation into the training course for new employees New employees: 10-15 Instructor Employees (2nd to 4th year): 20 to 30 (Mid-career employees may also take the course) Members of each responsible unit are instructors ・Think up curriculum structure ・Mid-level and veteran employees may also help To improve the environment for programmers, we have created and incorporated a systematic tool creation training program. The content of the training becomes established and becomes part of the culture as new employees and instructors are 48replaced over the years. ©CAPCOM 49

Improving Programmers' Development Environment Guidance on GitLab's MergeRequest Get used to WPF Step-by-step curriculum structure UI/UX Training Resource handling Diff tool for deliverables The course includes step-by-step basic practice of WPF and currently focuses on a diff tool to teach UI/UX. With a diff comparison tool, you can naturally learn how to handle data, which is important for programmers. ©CAPCOM 49 50

Improving Programmers' Development Environment Tool Training Points ・Data structures, C#, WPF, XAML ・Three-tier architecture (MVVM) ・Bare-basics training on UI and UX will be included Try to prevent "programmer tools" The beginning is the key! We will build tools, so data structures, C#, WPF, XAML, and about 3-tier architectureare on the curriculum. The 3-tier architecture is currently based on the MVVM concept. 50 Developing tools that will be maintained for several years is not something that most students experience at school, so many of them are thinking about UI for the first time. The main purpose is to reduce training costs in their assigned section. Mentioning UI/UX from the training stage will build a sense that it is important. It is difficult to change what is normal after a certain number of years in the company. We have to reject the "as long as it works..." mentality from the beginning. Anyway, the beginning is the key. ©CAPCOM 51

Example of Improvement with ShaderGraph Here is an example of a major improvement we have made. 51 ©CAPCOM 52

Example of Improvement with ShaderGraph Master Material Editor Issues in old shader nodes editor ・Slow startup (takes 3 to 10 minutes) ・Unable to withstand the number of nodes, normal operation is slow ・VertexShader and PixelShader cannot be used on the same canvas ・Hard to see where errors are ・Used for more than 10 years, WAY out of date Strong demand for improvement in speed, but drastic measures proved difficult to implement... We had to improve the shader node editor. It was very slow, and the fact that the VertexShader and PixelShader were in separate tabs was not well received by users. 52 The editor was too far gone to fix all the functional and speed issues; it needed to be rebuilt from the asset data up, so we decided to rebuild it as the new ShaderGraph editor. ©CAPCOM 53

Example of Improvement with ShaderGraph ShaderGraph Editor The result is an example of the ideal editor ・To completely rebuild, a dedicated UX designer was appointed ・Full participation of TA and Shader artists (users) ・Usability testing with 15 or more people As a result of our efforts, the ShaderGraph editor became the model for tools within RE ENGINE. We assigned a full-time UX designer to completely rebuild it. We also carefully worked with the TA and Shader artists early on to reach a consensus and get their cooperation. 53 Everyone was happy to cooperate with us because we could speed up the process, which helped us a lot. ©CAPCOM 54

Example of Improvement with ShaderGraph Support for detailed expressions with clear color coding Complex controls, organized Designed for performance when launching the editor The bottleneck at editor startup was mostly the DataContractJsonSerializer, while the bottleneck after launch was mainly the cost of recalculating the layout. 54 While focusing on performance, it was necessary to adjust even the smallest details of the design so that it would not break down. ©CAPCOM 55

Example of Improvement with ShaderGraph Connecting connector part is shown inside the node Node content drawing self-rolled, not using existing WPF layout elements To avoid unnecessary changes in node size, we changed the design to use more fixed values. The node's connecting connector part was placed inside the node for program simplicity and because we did not want55 to cause resizing of the node and connecting lines in principle. The node content drawing is handled by us, and no WPF layout elements are used to reduce overhead and to avoid size recalculation due to changes in internal elements. ©CAPCOM 56

Example of Improvement with ShaderGraph Control categories on the side are interchangeable Uses a vertical menu, which is not common in RE ENGINE Other than the nodes, a vertical menu was proposed and adopted in order to provide a larger work space. The location of the menu is more easily fixed, and the line of sight when looking for the menu requires only a slight horizontal 56 movement. As a result, the menu is easier to find. ©CAPCOM 57

Example of Improvement with ShaderGraph Mock-up preparation ・Participating members can try it from the early stages ・Match design and feel ・Provides an environment that makes it easy for each section to try it out There were times when the feel and display of these designs were checkedusing only mock-ups of the tool. We used it to communicate with the technical and shader artists who were cooperating with us about the design. We matched the final design and feel of the ShaderGraph editor to it. 57 We experimented to create a design that makes it easy for the editors to perform, the programmers to program, and users to use. The UX designer proposed an overall implementation design and created resources. At this point, four users had participated in official testing. ©CAPCOM 58

Example of Improvement with ShaderGraph V1 to V2 asset upconversion support available Same node configuration is guaranteed to operate on the same VGPR ・Performance differences affect the product ・Create various tests Also, the most important thing was to make sure that the performance of the output shader code and the rendering results were the same. 58 If there is a difference between the old editor and the new editor, there will be a reason not to use the new editor, because the entire asset data will be rebuilt. We have made it easy for users to switch by making upconversion tools readily available at their fingertips. We also prepared tests from a variety of angles regarding rendering results, and carefully conducted them using past titles that had already been released. ©CAPCOM 59

Example of Improvement with ShaderGraph Performance Improvement UX Improvement Shader Code Maintenance Perceived Degree of Completion 100% Difference between the duration of the work and the perception of completion Complete ・Mock-up work ・Related tools are also updated at the same time 90% ・Output HLSL performance is difficult to maintain 50% 100% Actual Completion Switching to the new ShaderGraph was not easy for me as a programmer because of the UX designer, but I had to worry less often about design aspects that are not my specialty. 59 We worked on mockups for about 3 months, and usability checks are done by technical and shader artists. The tool developers, UX designers and programmers update the mockups as needed. During these periods, the UX design itself was naturally subject to trial and error, but the trial and error itself was also accounted for as a normal process of development. The performance compatibility assurance was a large part of the reworking of this tool, and it may have taken about half a year's worth of man-hours just for that alone. ©CAPCOM 60

Example of Improvement with ShaderGraph I want to make it like ShaderGraph, is there a UX guideline? Later editors naturally follow suit ExprGraph (create arithmetic expressions as nodes) VisualScript, etc During the process of making ShaderGraph and after its release, I have been asked regarding other editors to "make it like ShaderGraph." 60 ©CAPCOM 61

Example of Improvement with ShaderGraph I want to make it like ShaderGraph, is there a UX guideline? Later editors naturally follow suit ExprGraph (create arithmetic expressions as nodes) VisualScript, etc It naturally became a model for node graph systems No coercion of any kind was needed This happened naturally without any effort on our part, so we can say that it was a positive effect of the ShaderGraph initiative. 61 ©CAPCOM 62

Division of Labor with Designers Next, we will discuss the division of labor with designers. 62 ©CAPCOM 63

Division of Labor with Designers Benefits of Division of Labor Each has years of specialized study From a programmer's point of view, there are many advantages to splitting the workload with a UX designer. Programmers study for years to program at a level that allows them to work as programmers. 63 The same goes for designers who can design at a level that allows them to work in design. ©CAPCOM 64

Division of Labor with Designers Designer Participation Even if you work hard to design it Responsibility can be shared, the results aren't so good... so programmers don't have to do everything. From a programmer's point of view, it is a great advantage to be able to consult with someone with design expertise in the same context. I am a programmer, and I have had many experiences where I have worked very hard on a design, only to find that the64 user response was not very good. In such cases, if there is a designer, at least the design will not be poorly done, and even if there is a poor response, the responsibility can be shared with the designer. You don't have to deal directly with vague user requests, not knowing how to solve them. It is very hard to deal with such problems in a field that is not your area of expertise. ©CAPCOM 65

Division of Labor with Designers Lets us provide users with more user-friendly tools Designer determines if new controls or icons are needed and makes suggestions Programmers can discover new ideas and possibilities Another benefit is that you will be able to provide better tools. When consulting a UX designer, you'll discover new things, and they'll usually create a better layout than you. Even in situations where you think you need a new button or a new icon, they may be able to make it work without it. ©CAPCOM 65 66

Division of Labor with Designers The programmer doesn't give precise design instructions ? ? ? They think that the designer is just there to make the icons and graphics... It is important to clarify roles and to communicate clearly Since we're on the subject of icons, I'll dig a little deeper. From this designer's point of view, the programmer does not give detailed enough design instructions. 66 From the is programmer's point of view, the designer is someone who makes icons, and at first they just think, "What icons should I ask for?" I think this happens a lot. ©CAPCOM 67

Division of Labor with Designers Programmers tend to add functionality to the screen Because during production, the focus is on adding functionality, the screen quickly fills up with buttons and icons... Programmers tend to think in terms of adding functionality to the screen. When addition becomes the primary solution, the screen quickly fills up with buttons and icons. 67 ©CAPCOM 68

Division of Labor with Designers Programmers tend to add functionality to the screen Because during production, the focus is on adding functionality, the screen quickly fills up with buttons and icons... Busy screen You end up with a busy screen. Going back to the basics of UX design, we review what we want to achieve with the tool before adding buttons. 68 We experienced many situations in which people with different skills consulted with each other to get back to these basics. ©CAPCOM 69

Division of Labor with Designers Challenge for Programmers Challenge for Designers Remove the Show ingenuity in the layout, "I need to add an icon" reflex and escape from the by developing together "person who makes icons" status By developing with a UX designer, you can get out of the "add more icons“ mindset that many programmers tend to fall into. Conversely, UX designers themselves need to show their ingenuity in layouts and get out of the "icon creator" pigeonhole. 69 We need to get to the point where there are no icons that programmers can come up with and request. UX designers have already made many icons and other design resources. Now, in the next part, we will have RE ENGINE's UX designers introduce the designers’ perspective. ©CAPCOM 70

Designers’ Perspective Now, let me introduce the perspective of the UX designers involved in RE ENGINE development. When we talk about UX design work, people think adjusting icons and colors, but here's my perspective of the problems 70 and challenges we faced in the UX design process. ©CAPCOM 71

Designers’ Perspective Points of importance for each section Features fit for purpose, less CPU cycles Color, layout, detail The key points that each section focuses on are, For programmers, it's functionality and execution speed. Designers are thought to focus on color, layout, and so on, but... ©CAPCOM 71 72

Designers' perspective Points of importance for each section Features fit for purpose, less CPU cycles Color, layout, detail Reduction of stress due to cognitive load The most important thing about UX design is to cognitive-load induced stress when working. 72 ©CAPCOM 73

Designers’ Perspective Stress felt when working due to cognitive load Where was that button, again...? The process of finding a function when the user looks at the screen, should be smooth The user's task when opening a large layout is finding the necessary tools, buttons, and other controls. The process of finding the tools and buttons must be smooth. ©CAPCOM 73 74

Designers’ Perspective Stress felt when working due to cognitive load Every minor difference on the display causes the brain to process it for information When looking for the function you need in a tool, the eye tracks over the different layouts, icons, colors, and so on, and the differences are processed. 74 ©CAPCOM 75

Designers’ Perspective Stress felt when working due to cognitive load Every minor difference on the display causes the brain Processing while following with eyes: Color, Line, Icon, Text, Line, Color, Location, Icon, and Text to process it for information In this act of looking for information, even the slightest line or color is processed unconsciously by the mind. 75 ©CAPCOM 76

Designers’ Perspective Color scheme issues Stress felt when working due to cognitive load Visuals with unclear intention waste mental processing power (High load) Aspects that can increase mental load include color scheme balance that does not consider contrast, or color schemes that are hard on the eyes, 76 ©CAPCOM 77

Designers’ Perspective Color scheme issues Stress felt when working due to cognitive load Layout issues Visuals with unclear intention waste mental processing power (High load) Layout problems that confuse order of operations, etc. 77 ©CAPCOM 78

Designers’ Perspective Color scheme issues Stress felt when working due to cognitive load Layout issues Visuals with unclear intention waste mental processing power Behavioral issues (High load) Problems with responsiveness to button presses, etc. 78 ©CAPCOM 79

Designers’ Perspective Color scheme issues Stress felt when working due to cognitive load Layout issues Frequent occurrence Visuals with unclear intention waste mental processing power Behavioral issues (High load) If these issues occur frequently, 79 ©CAPCOM 80

Designers’ Perspective Color scheme issues Stress felt when working due to cognitive load Layout issues Frequent occurrence Performance decline Visuals with unclear intention waste mental processing power Behavioral issues (High load) Users will be wasting their energy. This can interfere with their work. 80 ©CAPCOM 81

Designers’ Perspective Color scheme issues Stress felt when working due to cognitive load Layout issues Frequent occurrence Performance decline Visuals with unclear intention waste mental processing power Behavioral issues (High load) Design adjustments required It is necessary to adjust the UX design to mitigate this as much as possible. 81 ©CAPCOM 82

Designers’ Perspective Color scheme issues ・No uniformity in color ・ Color scheme that's hard on the eyes ・Ugly, colors are harsh Just looking at it takes a lot of energy It's not a good idea to use a lot of harsh colors just because you want to increase visibility. It is also not a good idea to use colors that are too close to the background color, as you'll have to strain to see them. If you do this too much, your eyes will get very tired. 82 ©CAPCOM 83

Designers’ Perspective Color scheme issues ・No uniformity in color ・Set color scheme rules ・ Color scheme that's hard on the eyes ・Color-coded icons by category ・Ugly, colors are harsh ・Adjust the color to a calm color, Just looking at it takes a lot of energy to reduce eye damage It's important to have a well-balanced color scheme, including contrast adjustment between the displayed items and the background color, to make the screen contents clear. 83 Avoid elements that are physically draining just to look at them. Strong colors should only be used for special occasions. ©CAPCOM 84

Designers’ Perspective Layout problems ・The role of each input is difficult to understand ・Close spacing of buttons, etc Regarding layouts, for tools that were launched a long time ago and have gradually added features, or new tools that are still being worked on for the time being, 84 In some cases, the functionality is not well organized. ©CAPCOM 85

Designers’ Perspective Layout problems ・The role of each input is difficult to understand ・Close spacing of buttons, etc ・Uncrowded design ・Organize operations into a single button Aspects that can be improved include the grouping of elements, organization of procedures, location of functions, etc. Organizing them well makes them easier to work with, and may open up the tool itself to further expansion. ©CAPCOM 85 86

Designers’ Perspective Similar design, different behavior Display Game Object Edit Asset Behavioral issues State behavior is disjointed Behavior during operation is also important. When similar display icons yield different results, or the mouse-over response is different for each tool, users will not be 86able to use the tools with confidence. ©CAPCOM 87

Designers’ Perspective Similar design, different behavior Designer manages production and use Display Game Object Edit Asset Behavioral issues State behavior is disjointed Unify interactions in the engine The most stressful aspect of interaction is the lack of consistent movement. Do the buttons do what their labels say they do? 87 We have been carefully confirming intent and behavior, and making sure everything lines up, and does what it seems like it should. When everything moves as expected, the user can work without concern. ©CAPCOM 88

Designers’ Perspective By creating a consistent design we can reduce users' mental strain Improved color scheme Improved layout Improved behavior We are working on the aforementioned considerations on a daily basis. Designing and creating a consistent design using UX design, Increases the amount of actions that don't require any mental effort. The leftover mental capacity can be used for actual work, ultimately increasing the user's efficiency. 88 ©CAPCOM 89

Designers’ Concerns and Challenges Insufficient communication ・Failed to properly understand user needs ・Programmers do not understand the improvements ・Differences in understanding feels like a barrier Timing of Starting Projects Concerns and Challenges ・If it's too late, only minor changes can be made; fundamental improvements aren't possible There've been many cases where UX designers have joined a project and things didn't go well. When we first started out, we had a lot of trouble finding ways to get things done. Communication was the biggest issue. Different sections have different vocabularies, leading to misunderstandings and not fully understood needs. 89 Also, at times we were first approached just before the release of the tool, and there was not enough time to prepare improvement plans. In those cases, we could only arrange colors and elements, and could not improve the fundamentals of the tool. ©CAPCOM 90

Designers’ Concerns and Challenges ? Difficult to judge implementation difficulty and processing load ・Difficult and stressful to find balance ・ End up not making suggestions out of feasibility concerns Tools in fields outside of knowledge area Concerns and Challenges ・Being a specialist still doesn‘t mean you can do everything straight away ・Need to learn, and need time to learn Also, it is difficult for UX designers to judge processing concerns and implementation difficulty levels. Sometimes, this results in needlessly conservative proposals. Finally, there is the case where the editor is in an unexplored field for the UX designer. 90 For example, if animation or shaders are outside of their expertise, they will need to fill in the gaps in their knowledge as they proceed. The only way to resolve these issues is to communicate and deepen our understanding. ©CAPCOM 91

Tool Improvement Process The following is the workflow of the tool improvement process. 91 ©CAPCOM 92

Tool Improvement Process Task appears Project in progress Test and release It can be roughly summarized in three phases. Three sections are involved: programmers, designers, and end users. The first phase may be omitted if the work is simple, but this is how most cases look. ©CAPCOM 92 93

Tool Improvement Process Task appears Project in progress Test and release Contents vary ・The colors are hard to understand and I want you to fix it ・I would like to ask you to design additional functions ・We're going to revamp the whole tool and want your input ・A new tool is being planned and we want your input Understand target tool Set up work environment and and its use cases understand scope of role When issues arise, the end user or the programmer in charge of the tool will contact us. The issue may be as small as a color adjustment, or as large as a request for deep involvement in the overall modification 93 of the tool. First, the UX designer and the programmer in charge of the tool will get to know the target tool and its contents. If it is something that can be verified in the current state, we can start working on it right away. But if the scale of the project is large, we need an environment in which we can work while checking in on progress, so we ask the programmer to prepare it for us. ©CAPCOM 94

Tool Improvement Process Task appears Project in progress Test and release Contents vary ・The colors are hard to understand and I want you to fix it ・I would like to ask you to design additional functions ・We're going to revamp the whole tool and want your input ・A new tool is being planned and we want your input Understand target tool Set up work environment and and its use cases understand scope of role Clearly define duties and roles However, when improving tools that are too specialized, it is difficult understand its goals, so the nature of the work and its use cases must be clearly defined. 94 If this is not organized, we will return to this stage again and again. ©CAPCOM 95

Tool Improvement Process Task appears ・Designs while confirming the tool's content ・Prepare materials for proposals Project in progress Test and release ・Response to questions and answers ・Handles detailed consultation ・Implementation, consultation about tool contents ・Submits requests ・Makes requests to the designer ・Dissemination within the team Once that's sorted out, the actual work begins. We communicate with programmers and selected end users, and prepare improvement plans while seeking the best concepts for the 95 engine as a whole. ©CAPCOM 96

Tool Improvement Process Task appears ・Designs while confirming the tool's content ・Prepare materials for proposals Project in progress Test and release ・Response to questions and answers ・Handles detailed consultation ・Implementation, consultation about tool contents ・Submits requests ・Makes requests to the designer ・Dissemination within the team Repeated implementation and confirmation to achieve the ideal result If the submitted proposal looks good, it will be shaped into a mockup. The UX designer prepares the necessary materials, and the programmer repeats the implementation and confirmation process to create the ideal form. 96 ©CAPCOM 97

Tool Improvement Process Task appears Project in progress Test and release Continue user testing and prepare for release ・Prepare manuals during testing ・Back up materials prepared for development The final stage is repeated user testing and release. At the time of release, we will also check the tools, prepare manuals, and organize the materials and design data thoroughly. 97 Putting together these resources is very important for the personnel who will be participating in the future. Do not neglect this task. ©CAPCOM 98

Tool Improvement Process Task appears Project in progress Test and release This is the way the project will end once it is completed, but... 98 ©CAPCOM 99

Tool Improvement Process Task appears Project in progress Test and release Tool improvements continue after official release Functions and requirements change with time and circumstances Never-ending tool improvement! Even after the official operation begins, various improvements will be made. Opinions and requests will also come from end users. Depending on the content, we will decide whether or not to respond to them, and make improvements. We always aim to further improve the tools. ©CAPCOM 99 100

Personas and User Testing Next, we will tell you about personas and user testing. 100 ©CAPCOM 101

Personas and User Testing Target persona Engine Team Participation Request End users working on title development, or technical artists User participation is essential for making tools practical Select specialists in the right field and ask them to get involved What is the persona we target during UX improvement for in-house tools? It's the end user we defined earlier. Someone who develops our titles. 101 The engine team will take their requests, along with factors such as load, overall engine implementation rules, UX design, etc., into account and make improvements. ©CAPCOM 102

Personas and User Testing The engine people seem to be busy so it's difficult to speak to them. If they reject my opinion, I'll feel silly for saying it... Users' I don't actually know who I'm supposed to talk to... motivations However, because users are both near and far from the engine developers, the scale of the project is so large that they often do not know where to express their opinions. 102 ©CAPCOM 103

Personas and User Testing Programmers won't care about my minor visual complaints... The engine people seem to be busy so it's difficult to speak to them. I don't know if my request is even technically feasible... If they reject my opinion, I'll feel silly for saying it... Users' I don't actually know who I'm supposed to talk to... motivations I don't want to keep using this clumsy, difficult tool! We still see opportunities where people don't offer their valuable input, because they’re worried about their lack of technical knowledge. The major challenge for the engine side is how to facilitate them. Especially since their help is necessary for user testing, which is the final stage of tool improvement. ©CAPCOM 103 104

Personas and User Testing Implementation check Technical Artist User test Pre-Test No longer doing large scale test format; changed to frequent, small-scale tests End users Each phase has different target users User testing will begin once the implementation of a set of functions has been completed. We used to go with large-scale, lab-style tests, but the preparation and procedures are too difficult, so we have changed 104 to a smaller scale. We are currently dividing the test into several parts and switching the type of target users according to the stage. ©CAPCOM 105

Personas and User Testing Implementation check Technical Artist User test Pre-Test No longer doing large scale test format; changed to frequent, small-scale tests End users Preparing an experimental version Quick feedback response in a ready-to-try Each phase has different target users environment; bridging the gap between engine teams and users. It is very important to have an experimental version of the engine with the changes available for users to try out and give immediate feedback. 105 Early response will help bridge the gap between the engine team and end users. ©CAPCOM 106

Personas and User Testing Implementation check Members are a small select number of TAs The duration is about one week Technical Artist Listen to requests via chat and respond quickly In the first phase, we gather technical artists and they use it for about a week. We then gather their feedback, mainly through chat, and make improvements where viable. 106 ©CAPCOM 107

Personas and User Testing Implementation check Members are a small select number of TAs The duration is about one week Technical Artist Listen to requests via chat and respond quickly ・The issues will become clearer and the content will be much better ・Quick communication and improvements ・Even better if you include people who have a degree of clout Requests can be picked up as they flow into the chat and a record is kept in the chat history, allowing for quick responses. Ideally you include people with some clout in their section, so that they can get the word out to other people in their107 team. ©CAPCOM 108

Personas and User Testing Pre-Test End users from a wide range of sections participate Have them play with the test environment during the test period End users Prepare a survey for feedback If you've made some improvements, then the next step is to ask people to participate in a slightly broader test. Feedback here is not via chat, because if you use chat, something important could be lost. 108 Instead, we give testers a survey that must be filled it out within a certain time frame. We then compile the feedback and make corrections and improvements for release. ©CAPCOM 109

Personas and User Testing Pre-Test End users from a wide range of sections participate Have them play with the test environment during the test period Prepare a survey for feedback End users ・ Not just anyone can be an end-user ・ Avoid attracting people with only one skill or role ・Using only programmers, technical artists, or veterans, will result in failure The end users can't be just anyone. They must be the people most likely to use the target tool. It is best to avoid gathering only people with one skill set or role. Selecting only programmers, technical artists, or veterans, is a recipe for disaster. 109 That is all for the designers' perspective. ©CAPCOM 110

Final Thoughts Now, to summarize. 110 ©CAPCOM 111

Final Thoughts Design guidelines alone are not enough to keep things in order For the most part, it only worked for designers ・Simple colors, sizes, etc., work for programmers ・Putting together layouts requires design knowledge Programmers alone can only handle the basics ・Consulting with UX designers needed because of lack of practicality ・Programmers need a supportive environment when programming I discovered that the design guidelines for simple color and icon usage rules, size, and other specifications, work well enough for programmers. 111 However, once it comes to putting together layouts, fundamental knowledge of design is required. Case-by-case consulting with UX designers is still needed, and for programmers, it was necessary to enhance the environment to support design-related code notations. ©CAPCOM 112

Final Thoughts Avoid large-scale user testing Bridging the gap between the engine team side and the user side ・Test versions can be made available with less hassle ・Need to be able to test iteratively Do frequent, small tests ・Switch users at each phase of testing ・Make full use of chat rooms and surveys to facilitate quick handling of feedback In terms of structure, creating an environment to distribute test versions can bridge the gap between the engine team and users. Having an environment where users can quickly try out improvements in-engine is effective in speeding up the cycle 112 of getting feedback and iterating. It was more effective to avoid large scale single tests, and to instead do repeated small scale ones. ©CAPCOM 113

Final Thoughts Changing Attitudes of Programmers Previously: Please check our UX! They only ask for our input right before the tool is ready for release. For example, "just tweak the colors and tidy up the layout..." Currently: UX designers are involved early Consulting begins before the concept is finalized and programmers spend less time worrying about design. In the past, we were often consulted just before the release of a tool that was almost finished. Now, UX designers are approached even before the requirements are finalized. 113 When programmers were the only ones who thought about design, we would sometimes fiddle with XAML endlessly to design by trialand-error. Before I knew it, the day was over and it was time to leave the office. Now, I don’t have to fumble around with XAML and worry about the design. ©CAPCOM 114

Final Thoughts Changes in Tool Development Increased communication opportunities Less design rework Users can give feedback without Users can give feedback without being too self-conscious it being too self-conscious aboutabout it. Quality has also improved It's more efficient than worrying about UX post-release They can feel free to talk about design problems found later down the road Overall, programmers and UX designers are now consulting with each other as needed, and users have also joined in, which has improved the quality of communication. 114 To a certain extent, design supervision is provided during tool development, so there is less rework in terms of design. When users know that UX designers also exist, they are more likely to consult with us. I think that users are now able to give us feedback without feeling self-conscious. ©CAPCOM 115

Final Thoughts Leave Usability to the Experts Time for tool engineers Don't waste time on design trial and error ・Don't waste time trying to design a good UX ・Use that time to improve the tools instead ・Focus on R&D to advance tools and technologies ・Support content creation workflows In conclusion, UX designers remove design trial-and-error time from tool engineers. By leaving UX design to UX designers, we can improve overall efficiency and quality. 115 When UX designers start working in tool development, users will know that they can talk to programmers about design. Usability, which had been neglected, becomes a motivation. Involving UX designers in tool development is a big change from how things were done previously, and there was some confusion at first. It was a process of trial and error. We are glad that we persevered until we were able to make the most of each other’s strengths. If you haven't done so yet, please give it a try. ©CAPCOM 116

Thank you for your attention That is all. Thank you for your attention. 116 ©CAPCOM 117