Start with the problem, not the screens.

Most projects start with a simple question: where are people getting stuck, and why? From there, I test ideas with users, share the reasoning with stakeholders, and use systems thinking to keep the work consistent. More recently, I've also been prototyping in code with Claude Code, so ideas can be tested in a way that feels closer to the final product.

The homepage showed links, not what needed attention.

An enterprise management platform where work spans goals, projects, and tasks. Executives tracked KPIs, project managers monitored delivery, and team members checked deadlines — but they all started from the same link-based homepage.

Users didn't need more information — they needed clearer priorities.

Interviews with enterprise clients, behavioral analytics, and a competitive review all pointed to the same pattern: executives, project managers, and team members had plenty of data, but each had to move between tools to understand what needed attention for their own work.

Four layouts were tested before the structure worked across roles.

Each feature was mapped against the users it served before layout exploration began. Redundant navigation paths were removed first, then four dashboard concepts were prototyped and reviewed with enterprise users. Feedback shaped iterations around calendar interactions, tab behavior, and the visibility of the assistant.

Navigation became a question users could type, not a menu they had to search

The AI assistant was positioned as a primary entry point for navigation. Instead of relying only on menu exploration, users could ask for what they needed directly and reach the relevant area faster.

Metrics that lived in separate tools were brought into one row

The statistics section consolidated KPIs across projects and targets into a single overview. Users could scan overall status from the homepage instead of checking multiple tools one by one.

Organizational and personal priorities shared the same space

Admins could highlight what the organization needed visibility on, while users could pin and rearrange the items most relevant to their own workflow — useful at both company and individual level.

The calendar brought deadlines from different tools into one view

Meetings, to-dos, reports, and tasks appeared in the same sidebar calendar, with filters by type and days of the week. This made time-based workload easier to scan without opening separate modules.

Tabs were organized by the user's relationship to the work, not by tool

“My Items” grouped everything the user owned, edited, or participated in, while the remaining tabs organized content by source. All relevant work was a single click away, reducing the need to remember where each item originally lived.

Shaped by user needs, but also by what was realistic to build.

Some ideas could have created a stronger experience, but I had to balance them against stakeholder preferences, existing product expectations, and what was realistic for development to build within scope.

That meant focusing on changes that would make the homepage clearer and more useful — without introducing unnecessary implementation cost or complexity.

When users work across connected tools, the interface should help them understand what matters without making them assemble that picture manually. This redesign focused on making priorities easier to scan, compare, and act on.

With more experience, I'd approach this with an even more restrained visual system and a stronger focus on content clarity — leaning further on spacing and hierarchy, and tightening the messaging so the site could communicate the offer faster and with less friction.

This project also shaped how I think about the relationship between design and content. Today I'd get involved earlier in UX writing and message structure, working alongside the team from the start — because when design and copy are shaped together, the value proposition lands more clearly and the path to action feels more confident.

Working with a no-code platform and limited resources meant I couldn't rely on custom development or expensive features. That forced clarity: what truly differentiates Brainny? The answer wasn't in complex interactions — it was in how information was structured: progressive disclosure, strategic navigation placement, dual-format social proof. The constraints drove better decisions than unlimited freedom would have.

I approached it as an accessibility problem shaped by context, not as a feature race.

The central question became: how could the platform help students study more effectively without assuming stable internet, large screens, strong prior confidence, or teacher support? That pushed the work toward mobile-first flows, clearer learning structure, supportive feedback, and AI features that removed friction instead of adding complexity.

From "ENEM AI" to "Aprova"

The project started as "ENEM AI," but I renamed it partway through. Said aloud, "ENEM AI" sounds like "tô nem aí" — Brazilian slang for "I couldn't care less" — the exact opposite of what the product is about.

"Aprova" speaks to what students actually want — getting in — is easier to say and remember on a phone, and leaves room to grow beyond the ENEM later. A small change, but it reframed the product around hope instead of the tool.

Inclusive design isn't just about removing cost barriers. It means designing for real conditions — small screens, inconsistent internet, limited feedback, and students who need the platform to be clear enough to use consistently without support.