2019 - 2020
UX Designers
UI Designers
Devs
Organization
Planning
DesignOps is a term coined to describe practices that already existed in corporate environments, mainly within companies born in the digital/post-digital age, but which were not formalized in a specific department. Therefore, DesignOps, or design operations, emerges to increase product scalability, generating higher revenue for the company, increased team productivity, and greater customer satisfaction by delivering a more consistent product. As companies mature and invest in design, they need to operationalize workflow, hiring, and team alignment. Design operations are essentially responsible for making design happen within companies and increasing the value of their products and services.
Until 2017, the TCU's Information Technology Sector (STI) was composed of developers, Product Owners, and Service Heads who acted as Scrum Masters (SM) and Product Managers (PM). In 2018, the first contract for UX/UI designers emerged, who would contribute to the future processes and system development of the sector's directorates.
Therefore, there was a scenario of systems development 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 (Information Technology Department), a working group was defined to plan the TCU's (Brazilian Federal Court of Accounts) Interface Design processes.
Given this situation, the defined challenge was:
"How can we create digital processes, projects, and products in an organized and scalable way, leading to more productive teams and more satisfied users?"
The success criteria for this challenge are:
1. Having leadership that provides support and guidance to the Design teams;
2. Efficient process management;
3. Strategies aligned with priorities.
In addition to the success criteria, several deliverables were defined:
1. Creation of a Wiki for each system developed;
2. Creation of an Interface Guide for the STI system;
Working alongside the design team, I contributed to defining the STI Design process to ensure that user experience and interface designers create and deliver high-quality, scalable design artifacts. Additionally, I actively participated in creating the delivered documentation.
The IT department was divided into directorates, which in turn were divided into sectors. Each sector had a service head who acted as both Scrum Master and Product Manager, one or more Product Owners, three or four developers, and, with the arrival of UX and UI professionals, one UX and one UI designer in each sector. It's important to note that without UX and UI designers, digital environments were developed and designed exclusively by developers, leading to several usability and visual consistency problems.
Basic organizational structure of the TCU's Information Technology Sector.
With the inclusion of user experience and interface professionals, some redesigning and restructuring existing systems, others designing new ones, and as the projects evolved, it became clear that the research processes (UX), visual interfaces (UI), routines, and deliverables were not very well aligned across all STI teams. This would certainly bring some problems, especially when it comes to system consistency, user experience, and documentation, since the TCU uses various types of systems, including different languages. This is where the need to standardize and document UX and UI processes arose. But before that, we needed to understand our level of UX/UI maturity. It might seem obvious that we would be at the first level on any maturity scale, but it was necessary to detail the initial conditions and the goals that needed to be achieved to evolve to the next level.
When discussing UX processes in a company, department, or project, it's possible to classify them according to their level or degree of maturity. In this case, we use the organizational maturity levels proposed by NNGROUP, explained in detail in this article and others detailed therein, to classify the maturity level of the IT department..
Summary of the six maturity levels by NNGROUP
In this maturity model, we understand User Experience from four perspectives: strategy, culture, processes, and results.. Therefore, to understand exactly where we were on this scale, where and how we should evolve, the Design team facilitated a workshop with managers and Product Owners from each sector to map activities, create a new workflow integrating UX/UI activities, and define the next steps. Given the teams' current workflow, the initial levels of each of the four aspects mentioned were discussed and defined.
The first three levels of maturity for doing Zen Voting.
Thus, considering these 4 aspects of UX, the following characteristics of STI were found:
STRATEGY
- Vision: Users are mentioned but are not the focus (Level 2);
- Planning and priorities: User Experience is not included in defining objectives or priorities (Level 1);
- Budget: Does not exist (Level 1).
CULTURE
- Knowledge: They don't understand UX (Level 1);
- Support: They understand UX as "making it visually appealing" (Level 2);
- Competency:They do not possess a UX mindset (Level 1);
- Adaptability: They do not strive to improve (Level 2).
PROCESSES
- Method: No UX method is used (Level 1);
- Collaboration:Some team members attempt to utilize UX processes, but they are ignored (Level 2);
- Consistency:Basic UX activities are very specific and not replicable (Level 1);
RESULTS
- UX Impact: Doesn't 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 observed that the maturity of UX processes at STI possessed elements of level 1 (Absent, where User Experience is ignored or nonexistent) and level 2 (Limited, uneven, and casual), which made perfect sense, since only now were there UX and UI professionals working in the TCU's STI teams.
The goal of this step is to understand the initial workflow in order to adapt it into a new workflow with design (UX/UI) processes and other improvements.
Thus, in order to improve this flow and define the process that is most consistent with the new team formats and needs, the use of the affinity diagram was proposed as a tool so that the team and stakeholders could decide, together with them, which steps and activities would be part of the new STI task flow.
Standard workflow of an IT department without UX and UI designers.
For this activity, we brought together all profiles—developers, UX and UI designers, product owners, and managers from different sectors—to collaboratively design a new, more optimized workflow adapted to the new challenges and team structures.
This exercise allowed the people involved in the development of the systems to actively participate in defining the process they would use in their daily work. Therefore, a new workflow was designed, improvements and new steps were suggested for the current process, also allowing for the easy adaptation of projects already underway.
Creation of an affinity map to define the new work process that included UX/UI activities in the IT department and other improvements.
As a result of the Design team's efforts and collaboration with other professionals, we developed a new workflow compatible with the new STI structure, bringing significant improvements to the process and, most importantly, to the quality of deliverables.
New standard workflow for an IT team.
Beyond the workflow for systems development, we structured and organized a Systems Interface Guide for the TCU (Brazilian Federal Court of Accounts) based on Material Design, a design system created by Google. The TCU's Systems Interface Guide, like Material Design, is a set of guidelines used for standardizing graphical interfaces. Therefore, adapting it to our reality, we created our own interface guide, which contains recommendations for standardizing the TCU's STI interfaces. For more details on TCU Systems Interfaces, see the link below.
Interface Guide for TCU Systems
As a complement to the TCU's System Interface Guide, the creation of components for each of the new STI systems was established; that is, each system developed or under 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. To see the details of the CONECTA-TCU Design System, click on the link below.
CONECTA-TCU Design System
Including leadership from each sector in this process was crucial for consolidating the Design team, its processes, its decisions, and, most importantly, gaining their trust, support, and backing for future projects. In addition, the new workflow allowed for more efficient process management, focusing on improving communication and feedback within the team.
Furthermore, the available documentation, such as Wikis, the Interface Guide, and the respective Design System for each system, sped up the construction of prototypes and development, since prototypes could already be made in high fidelity, increasing the speed of their approval, generating fewer doubts and rework, and the backend components were already ready.
Creating all the documentation and the design process was a separate effort from a job that already involved UX processes. In this project, it was crucial to learn how to manage my time so as not to impact deliverables and to improve my communication skills to be clearer and more objective with my immediate supervisor and to be able to get support for any problems or difficulties that might arise.
Other important lessons learned included guiding the UX/UI team and knowing how and to whom to delegate tasks to achieve our goals, given that each person has their own profile. It was important to have an understanding and knowledge of each person in order to demand the best from them. I consider it one of the best experiences I've had, even though I shared this leadership with another colleague. It involved months of collaboration and exchange of ideas that resulted in excellent work.
In general, all deliveries have been completed. However, they are maintenance and update-oriented, and therefore the documentation should be revisited, reviewed, and updated periodically.