Project CEU: Four Units, One Month, and a Lot to Organize
How a design team organized a digital experience for four CEU units in São Paulo across three sprints and four weeks.
Four CEUs, one month, and a lot to organize
Phorte partnered with the São Paulo City Hall to work across four CEUs: Silvio Santos, Rei Pelé, Padre Ticão, and Papa Francisco.
I was brought in to lead the Design work end to end—from branding to the website, including visual identity, UX/UI, components, accessibility, and following the experience through to the published environment.
In this project, I worked with Dorys, Marketing Manager, and Emerson, Educational Project Lead. Each workstream had its own decisions, but everything needed to come together in the end.
It was a demanding challenge: three sprints in four weeks, one month to organize a workstream that would normally take months. Across the projects and people involved, we passed more than 819 work stages. This number shows the scale of the work; it is not a metric of traffic, conversion, registrations, or impact.
The official website launch is scheduled for July 27, 2026. While the project enters this stage, the experience can be explored at ceu.phorte.org.br.
One brand for four programs and four units
The materials we received included rich research about the CEUs, their territories, and the people who could use these spaces. The quantitative data is not included in this publication because it is internal information, but the learnings helped shape the first product decisions.
The decision that guided much of the work was to separate the experience into four programs: Education, Sports, Leisure, and Culture. This was not limited to the brand presentation. The four categories helped organize activities, filters, cards, signage, and the paths through the website.
The four units also needed to follow the same logic. Each has its own territory, images, contacts, and programming, but all should be recognized as part of a shared experience.
Color could not carry the entire burden of information. Categories also appear through text, icons, and visual hierarchy. People should not have to distinguish one color from another to understand what they are seeing.
The identity needed to work on the website, posters, murals, shirts, badges, signs, social posts, and smaller screens. It had to coexist with partner brands and materials without losing its own logic. The decision was simple to explain but important to sustain: the identity needed to be beautiful, but first it needed to be useful.
Test fast without letting AI decide the project
Once the context was more organized, I produced quick prototypes with AI to test possibilities. The tool was not meant to decide the project, and a generated image was never meant to become the final deliverable. The idea was to explore directions, find problems early, and learn before investing more time in one path.
We then brought the ideas together in a workshop. Everyone shared what they imagined for the CEU, and we tested those possibilities against business rules, the timeline, and what the operation could realistically sustain.
Separating what was possible from what was only a wish was an important part of the work. At times, we called some ideas delusions. Yes, those were the words. It was useful because not every good idea is ready to become a requirement.
This process helped separate inspiration from decision-making and clarify which points needed to move into the information architecture, visual system, and interface.
The images in this section show part of that exploration: identity, communication, signage, and identification. They are prototypes and conceptual applications used to open conversations and test consistency across touchpoints. They are not records of final materials installed or published.
From identity to website
With the CEU foundation defined, we began turning decisions into an experience. The website needed to bring the four units together while helping each person find an entry point.
Someone could start by choosing a CEU, looking for an activity, checking the schedule, understanding the territory, reading a news item, or finding contact information. On the homepage, people get an overview of the project and can choose the unit that fits their routine.
We also worked on unit pages, the schedule, activity details, news, Olhares do CEU, contact, and institutional information. The architecture had to create a shared language across these paths without erasing each unit's particularities.
The schedule was important because it is where the digital presence stops being merely informative and starts supporting participation. Filters were designed to help people search by CEU, category, day, and age range. Activity states also needed to be clear: registration open, waitlist, or activity closed.
The map serves a similar function. Listing four addresses was not enough; people needed help understanding where each unit is and which one made the most sense for their routine.
The flow does not end when someone finds an activity
The schedule solves one part of the problem: it helps people discover what exists and where it exists. But the experience needed to carry that discovery through to participation.
The flow guiding the work was easy to describe and difficult to organize: what the person wants to do, where they want to do it, how they will do it, what they need in order to do it, and then going to do it.
The registration and activity enrollment area was already being developed by another Phorte team. I did not create it, and it should not be presented as an exclusive deliverable of the Design workstream. The SIS entered the project implementation later, but this need was already part of the scope and user flow.
In practice, the website works as the discovery and guidance layer. People choose an activity, understand which CEU hosts it, and check its date, time, age range, category, and participation requirements. When it is time to register or enroll, the experience directs the next step to Phorte's SIS, which handles registration and enrollment.
This changes how the interface needs to be designed. It is not enough to place a “Register” button. The experience must make clear what happens after the click, which information will be needed, whether a spot is available, whether there is a waitlist or another state, and how the person continues without losing context.
Recognizing the division of responsibilities between teams was also important. The Design work was not meant to replace the SIS, but to make the entry into the transactional flow understandable for people coming from the website.
When Figma meets the real experience
Figma was used to organize foundations, references, wireframes, components, and interface decisions. But the work did not end in the file.
When the experience began to be implemented, problems appeared that a static screen cannot show: imports with broken layouts, blank screens, a map with a misaligned click area, a mobile menu without enough space, desktop and mobile differences, and contrast adjustments on buttons.
This is when the Design Engineer role becomes most visible. It is not enough for an interface to look right in a mockup. It must continue to make sense when the content changes, the screen gets smaller, someone touches the map, or a different state appears.
We also had to keep the core information organized: units, categories, activities, contacts, images, and registration states. In the final website, the registration flow is integrated with the SIS, in a step developed alongside the area another Phorte team was already building.
The challenge was not to create an isolated registration screen. It was to organize the full path: discover a possibility, choose a unit, understand the conditions, know what will be needed, and move forward in the correct environment.
Accessibility as a criterion, not a finishing touch
Accessibility was part of the scope from the start, but it gained more weight throughout the project. It stopped being something to review at the end and began influencing components, content, contrast, focus, motion, and navigation.
An important reference in this stage was A11yMD by Felipe A. Carriço. The proposal to include accessibility in AI work rules before building the interface helped bring the conversation into the beginning of the process.
I did not treat A11yMD as an automatic certification. It worked as a thinking reference for AI exploration and product decisions.
The improvements included keyboard navigation, visible focus, a skip link to the main content, font-size controls, high contrast, reduced motion, voice reading, selectable reading areas, VLibras integration, alt text, labels, and states that do not rely on color alone.
No specialized audit was performed, so I am not claiming formal WCAG compliance. What I can say is that accessibility entered the project's structure and was not treated as a finishing touch.
As the accessibility ideas grew, we also began studying structural and physical improvements to the CEUs to better serve people with mobility difficulties and others who face barriers in the space. This work is still under study and is not presented here as a completed construction project or improvement.
For me, this was an important expansion of perspective: a digital experience can make information easier to access, but participation also depends on how the physical space welcomes people.
The identity had to be useful
The main learning was understanding that identity and product were not two separate deliverables. The identity helped organize information, research helped define the paths, implementation revealed the real states of the experience, and accessibility changed interface and content decisions.
When these parts began to work together, the project stopped being just a collection of screens. It became a system for guiding people to their CEU, helping them find an activity, and explaining how to participate.
To me, this is the most interesting part of the project: Design did not stay confined to the opening screen. It had to follow the identity, territory, operation, partners, components, and the path to the published experience.
I am not presenting the SIS as my deliverable, but as part of the journey the website needed to guide. Each team should be recognized for what it actually built, while the product needs to be understood through the complete experience.
An ecosystem with channels for each unit
The four units also maintain their own Instagram channels. They help follow the project's local communication and reinforce an important experience decision: there is a shared language, but each CEU needs to remain recognizable to its community.
These profiles are public channels for the units and may change over time. They are included as external references for the ecosystem, not as a source of metrics or proof of project impact.
What is being shown
In this publication, I show the visual identity, the logic of the four programs, previews of screens and components, the homepage, the schedule, the conceptual flow between the website and SIS, assistive features, and an embed of the product's Figma file.
The process materials are previews of internal work and should not be considered final promotional materials. Research data, proto-personas, traffic metrics, conversion, registrations, and impact are not part of this publication.
The public website can be explored at ceu.phorte.org.br.
CTA
In service products, which part usually reveals the most problems after the first prototype: architecture, responsiveness, accessibility, or integration with the operation?
