← projects
case 02

Bd'A: when a rebrand turns into a diagnosis

Art DirectionInformation ArchitectureAccessibility & AEO

2026 · published August 25, 2026

3 views
see UI screens and prototypes →
Bd'A — project cover

Bd'A is Ricardo Baddini's architecture studio, working with real estate development. He hired me for a rebrand: the studio was turning two, and the brand needed to match the size of the work he was already delivering, with projects for Even, Catuaí, and Alta Diagnósticos in the portfolio.

I delivered the rebrand. And I delivered something nobody had asked for, because it surfaced before I designed the first screen.

How I read a site that already exists

This is my diagnostic method, and it has an order I follow on every project.

First I use the site as someone who arrived with no context, noting whatever is perceptible: visible errors, inconsistent patterns, speed, information architecture. Then I run the accessibility tests, by hand and with tooling. Only at the end do I open the code.

The code coming last is deliberate. I'm not a developer, and what I read there isn't implementation: it's labels, naming, construction patterns, the way the project was assembled. If I opened the code first, I'd reach the screen already contaminated by how it was built, instead of seeing what the person on the other side sees.

What the diagnosis found

The previous site lived inside a visual website builder. The first measurement already played a trick on me: Google Lighthouse returned 92 out of 100 on SEO. A comfortable pass. If the conversation had stopped at the score, the conclusion would have been that all it needed was aesthetic work.

The score measures the surface. It checks whether a title exists, whether a link is crawlable, whether the tag is in place. It doesn't open the door to see if anyone is home.

Here's what I found when I opened it:

  • The "About" page lived at /copia-home-1, which means "copy of home 1". Projects was /copia-copia-home-1-1. Services, /copia-copia-home-1-2. Names that appear on their own when you duplicate pages inside a builder.
  • The home page had five top-level headings competing with each other and then jumped to a fourth-level subheading. About and Services had none. A screen reader can't build an outline for any of those pages.
  • The Projects page served 83 images described by their file name: 1000037986.jpg, WhatsApp Image.... People who see get the renders. People who listen get noise.
  • None of the six pages marked where the main content begins, and none had a skip link. Anyone navigating by keyboard went through the entire menu on every page.
  • The description that shows up in search results was empty, there was no structured data at all, and the sitemap listed six addresses, four of which were copies of the home page competing with it.

I brought this to Ricardo in the middle of a branding project. He was surprised, and told me he hadn't known any of it mattered on a website.

That sentence is the whole case. The work that decides whether a studio exists outside Instagram is exactly the work that never shows up in a layout review.

The decision to audit without being hired for it

The comfortable path was available: do the rebrand as briefed, deliver something beautiful, move on to the next project. The site would stay invisible and nobody in the room would have any way of knowing.

I chose to measure first. That widened the scope, stretched the schedule, and put me in the position of showing a client what was wrong with the site that was his, before anything of mine was on the table.

I work this way because a diagnosis and a rebrand answer different questions. A new brand solves how the studio presents itself to whoever already arrived. Nothing in a rebrand solves people not arriving.

The decision to hold the launch because my own version was worse in one spot

This is the decision I least enjoy telling and the most useful of all.

The first draft of the new site already had the approved identity and looked good on screen. The project pages, which are the core of the portfolio, assembled themselves inside the visitor's browser. For anyone opening the site, it worked. For a crawler that doesn't execute JavaScript, and for a good share of AI bots, an empty shell arrived: no title of its own, no text, no data.

I would have been trading a weak but indexable site for a strong but invisible one, on exactly the page that sells.

I classified it as a launch blocker in my diagnostic report and didn't point the domain until it was solved. The way out was putting a page generator in the middle: project data goes through it and comes out as finished HTML, with title, text, and structured data already in the served file.

That carries a cost I still carry, and I'd rather put it on record: the site was plain static and now has a build step. Every time a project's data changes, someone has to run that command and publish the result. I chose a recurring maintenance cost over shipping an unreadable portfolio.

The decision not to stop at 100 on accessibility

The automated test on the new site scored 100. I reviewed it by hand anyway, and nine problems showed up.

The best one: the counters in the studio section animated from zero up to the final number. For anyone whose system asks for less animation, the animation doesn't run, and the number froze at its initial value. The site announced "+0 years of experience" precisely to the person who asked for less movement.

No automated tool catches that. They read the code and give good hints. I look at the screen with the perception of someone using it, which is why a human review isn't an optional step for me, in any kind of assessment.

What's solid and what's a bet in AI discovery

This separation is the part of the work I make a point of naming, because the AEO market sells everything with the same confidence.

What's solid: every project became a page that exists in the served HTML, with title, text, and structured data. The site's rules file explicitly allows the bots from ChatGPT, Claude, Perplexity, and Google. The structured data describes the studio, the services, each project, and Ricardo's authorship. The questions a developer asks before hiring became a marked-up question and answer section. That's the base a search engine and an assistant can read and quote.

What's a bet: the llms.txt, a clean-text summary written for AI assistants. I published it knowing no provider has committed to reading that file, and that Google has publicly stated it doesn't use it and doesn't plan to. What AI bots actually consume is the page's HTML, which is exactly the solid part above. The llms.txt went in because it costs one file and gets in nobody's way, and it stays on record as a cheap bet, under that name, not as an engine of results.

What changed

Measured in July 2026, between the site that was published and the new version, with Lighthouse on desktop:

  • Accessibility: 79 → 100
  • SEO: 92 → 100

And the foundation counts, which is where the real room for gain was and what a tool score doesn't measure:

  • Project pages readable by search engines and AI: 0 → 8
  • Types of structured data on the site: 0 → 6
  • Useful addresses in the sitemap: 6 → 11, with no duplicate pages

The site is published at bdaarq.com.br. Checking it today, every project page serves its own title, heading, and structured data straight from the HTML, without depending on anything running in the browser.

Credit

The project images and texts are Ricardo's, and the site copy is his voice.

Curating the archive, the information architecture, and the art direction were entirely mine. The project was executed end to end with AI support: I directed it, and part of what I needed along the way were quality and testing tools I had built during the project itself. I did not write the code.

What I take from it

Diagnosis before proposal changed the nature of this work. The brief was a rebrand, and the rebrand alone would have left a beautiful site nobody finds.

The part nobody explicitly hires, meaning headings that make sense, images described for people who can't see them, and a page that exists before JavaScript runs, is the same part that answers for accessibility and for discovery at once. In this project I learned to present it as one thing, because that's what it is.

Comments

loading comments...