DesignOps-TCU

DesignOps was a term coined to describe certain practices that already existed in corporate environments, mainly within companies born in the digital/post-digital era, but which were not formalized in a specific sector. Thus, DesignOps, or design operations, emerge to increase product scalability, generating greater revenue for the company, productivity for teams, and greater customer satisfaction by delivering a more consistent product. As companies mature and invest in design, they need to operationalize the workflow, hiring, and alignment between teams. Design operations are, basically, responsible for making design happen within companies and amplifying the value of their products and services.

Until 2017, the Information Technology Sector of the TCU (STI) consisted of developers, POs, and Service Chiefs who acted as Scrum Masters (SM) and Product Managers (PM). In 2018, the first contract for UX/UI designers appeared, who would add to the future processes and system development of the directorates in this sector.

There was, therefore, a system development scenario with very few criteria and methodological rigor regarding the use of design principles and processes. In view of the arrival of Design professionals and the need to structure a Design process within the STI, a working group was defined to plan the Interface Design processes of the TCU.

Given this scenario, our challenge was:

"How can we create digital processes, projects, and products in an organized, scalable way, with more productive teams and more satisfied users?"

The success criteria for this challenge are:

1. Having leadership that provides support and backing for the Design teams;

2. Efficient process management;

3. Strategies aligned with priorities.

And the defined deliverables were:

1. Creation of a Wiki for each developed system;

2. Creation of an Interface Guide for STI systems;

3. Creation of the Design System for each developed system.

I contributed to this project with the planning and organization of the STI Design process and in the leadership of user experience and interface designers to ensure they delivered high-quality and scalable design artifacts. Additionally, I actively participated in the creation of the delivered documentation.

The DesignOps process was developed in three very objective stages due to the urgency and lack of time available for its implementation:

1. The diagnosis stage, where we verified the structure of the process and initial UX Design maturity of the IT sector (STI) of the Federal Court of Accounts (TCU);

2. Second, the research stage, where we understood the profiles of each collaborator in the task flow of the STI UX Design process;

3. And finally, the deliverables, where we established the new organization and task flow of the STI UX Design process;

The STI is divided into directorates which in turn are divided into sectors, and each has a service chief who acts as Scrum Master and Product Manager, one or more Product Owners, three or four developers, and, with the arrival of UX and UI professionals, there was one UX and one UI in each sector. It is important to point out that without UX and UI designers, the digital environments were developed and designed exclusively by developers, generating various usability issues and visual inconsistency.

With the inclusion of user experience and interface professionals, some redesigning and restructuring existing systems, others designing new ones, and as projects evolved, it was noticed that research processes (UX), visual interfaces (UI), routines, and deliverables were not very well aligned across all STI teams. Therefore, there was a problem of visual consistency between systems, as well as a lack of standardization of user experience and documentation, since there are many systems and interfaces, including with different languages. Hence the need arose to standardize and document UX and UI processes. But before that, we needed to understand what level of UX/UI maturity we were at. It might seem obvious that we would be at very initial levels on any maturity scale, but it was necessary to detail what those initial conditions were and what goals should be reached to evolve to the next level.

When talking about UX processes in a company, sector, or project, it is possible to classify it by level or degree of maturity. In this case, we used the organizational maturity levels proposed by NNGROUP, explained in detail in this article and others detailed therein, to classify the maturity level of the STI.

In this maturity model, we understand User Experience under four aspects: strategy, culture, processes, and outcomes. Thus, to understand exactly where we were on this scale, where and how we should evolve, the Design team facilitated a workshop with managers and POs from each sector to map activities, create a new task flow integrating UX/UI activities, and define the next steps. Given, therefore, the teams' current task flow, the initial levels of each of the four cited aspects were debated and defined.

Thus, under these 4 UX maturity aspects, the following characteristics of the STI were found:

Strategy

• Vision: Users are mentioned, but they are not the focus (Level 2);

Planning and priorities: User Experience is not included in definitions of objectives or priorities (Level 1);

Budget: Does not exist (Level 1).

Culture

Knowledge: They do not understand UX (Level 1);

Support: They understand UX as "making it visually pretty" (Level 2);

Competence: They do not have the UX mindset (Level 1);

Adaptability: They do not make an effort to improve (Level 2).

Processes

Method: No UX method is used (Level 1);

Collaboration: Some people on the team try to use UX processes, but are ignored (Level 2);

Consistency: Basic UX activities are very ad-hoc and not replicable (Level 1).

Outcomes

UX Impact: Does not exist, deliverables are focused on features and not on user experience (Level 1);

Measurement: Few user experience metrics are collected, but they are underutilized (Level 2).

In this context, it was realized that the maturity of UX processes at the STI possessed elements of level 1 (Absent, where User Experience is ignored or nonexistent) and level 2 (Limited, sporadic, and casual), which made perfect sense, as only now were UX and UI professionals working in the TCU STI teams.

The goal of this stage was to understand the initial task flow to adapt it into a new flow with Design processes (UX/UI) and other improvements. Thus, to perfect this flow and define the process most consistent with the new team formats and needs, the use of the affinity diagram was proposed as a tool to decide, together with the team and stakeholders, which stages and activities would be part of the new STI task flow.

For this activity, we gathered all profiles, developers, UX and UI designers, product owners, and managers from different sectors to design together a new, more optimized task flow adapted to the new challenges and team structure.

This exercise allowed the people involved in system development to actively participate in defining the process they would use in their daily work. Thus, therefore, a new task flow was designed, improvements and new stages were suggested in the current process, also allowing the possibility to adapt ongoing projects without much effort.

As a result of the Design team's efforts and collaboration with other professionals, we developed a new task flow compatible with the new STI structure, bringing significant improvements to the process and, mainly, to the quality of deliverables.

In addition to the task flow for system development, we structured and organized a System Interface Guide for the STI based on Material Design, a design system created by Google. The Interface Guide for TCU Systems, like Material Design, is a set of directives or guidelines used for standardizing graphical interfaces. Therefore, adapting it to our reality, we created our own interface guide, which contains recommendations to standardize the interfaces of the TCU STI. For more details, access the TCU Systems Interface Guide file at the link below.

As a complement to the Interface Guide for TCU Systems, the creation of components for each of the new STI systems was established, that is, each system developed or in development would have its own Design System, the result of a task force between designers and developers. The Design System, therefore, will allow for the creation of more consistent and scalable digital products.

The inclusion of leadership from each sector in this process was decisive for consolidating the Design team, its processes, its decisions and, mainly, gaining their trust, more backing, and support for future work. Along with this, the new task flow allowed for more efficient process management, focusing on improving communication and feedback among the team.

Furthermore, the available documentation, such as Wikis, the Interface Guide, and the respective Design System for each system, provided speed to the construction of prototypes and development, since prototypes could already be made in high fidelity, increasing the speed of their approval, generating few doubts and rework, and the backend components were already ready.

Creating all the documentation and the design process was an effort separate from work that already involved UX processes. In this project, it was crucial to learn how to manage time so as not to impact deliverables and to hone my communication skills to be clearer and more objective with my immediate leadership and to be able to have support on any problem or eventual difficulty.

Other important lessons were: guiding the UX/UI team and knowing how and to whom to delegate tasks to achieve our goals, given that each person has their profile. It was important to have the perception and knowledge of each person to be able to demand the best from them. I consider it one of the best experiences I've had, even while sharing this leadership with another colleague. It was months of collaboration and idea exchanges that resulted in work of excellence.

In general, all deliverables were finalized. However, they must always undergo maintenance and updates according to the evolution of the systems and, therefore, the documentation must be reviewed periodically.