A website can grow in two very different ways. It can keep adding more responsibilities to the same surface until every page tries to serve every audience, or it can learn to separate purposes without losing coherence. For quite a while Blupoli — and Blupoli Puzzles before it — grew in the first way. That made sense at the beginning. There was one experience, a puzzle catalogue and a publication around the project. As the product matured, however, that early simplicity turned into overlap. Game navigation talked about editorial material. The editorial area mixed product announcements with development diaries. The footer, logo and some visual patterns were not always aligned between the Blupoli home and Puzzles. The overall feeling was difficult to name: everything belonged to the same project, yet it did not always feel as if it had been designed as one system.
The recent restructuring is an attempt to solve exactly that. We are not chasing a dramatically new aesthetic for the sake of novelty, and we are not redesigning the interface so that every week looks different. We are using design to clarify product architecture. Blupoli is the umbrella brand. Blupoli Puzzles is the place to play. The Blog explains news, launches, ideas and meaningful product changes. The Devlog explains how those results are built: decisions, mistakes, experiments, architecture and lessons. Once every surface knows why it exists, design stops being a collection of pretty components and starts acting like a language.
The problem was not that the design was too dark
When an interface starts to feel wrong, the first temptation is often to adjust the palette, corner radii, shadows or typography. That is understandable because those are the most visible ingredients. But when we reviewed the site, we found that the main problem was not there. We already had strong visual pieces, especially inside the puzzle experience. What was missing was hierarchy between products and content types.
A visitor could arrive to play and encounter editorial navigation that was not essential to that task. Another person could open an article about a new feature and land on a page that looked too similar to a technical build diary. We had accumulated genuinely interesting material, but the way it was presented did not always explain what kind of content it was or why it belonged there. Instead of reducing decisions, the interface introduced new questions.
That is why the redesign started with something less dramatic than a new hero section: defining responsibilities. The Blupoli home should represent the brand and lead to real products. Puzzles should prioritise catalogue, play and discovery. The Blog should behave like a public publication. The Devlog should have room for process, chronology and engineering depth. Once that split existed, visual decisions became easier because every button, heading and card could be judged against a concrete question: does this help this surface do its job?
We are moving from one surface that tried to tell every story to several areas with explicit missions.
Blog and Devlog finally mean different things
The split between Blog and Devlog is probably the most important change in this phase because it affects both design and writing. We previously used labels such as Journal, Logbook and Devlog, and some content moved between them. That worked while the volume was small. Once the archive grew to dozens of pieces, it became increasingly hard to know where a story belonged and what a reader should expect when opening it.
The Blog now has a public-facing rule. This is where we want to talk about changes that matter because of the outcome: a new way of organising the catalogue, a launch, a major design improvement, a story about a puzzle family or a broader Blupoli update. You should not need to have followed the development history to understand the article. It must stand on its own, provide enough context and end with something useful.
The Devlog looks at the same project from a different distance. There we can explain that a build step had a limitation, that a legacy route complicated a migration, that a puzzle engine needed its own solver or that a design decision appeared after a specific inconsistency was discovered. The Devlog reader does not only want to know what changed. They want to understand how we reached the decision and what we learned along the way.
This separation changes the interface too. Labels, return links, metadata and listings can set expectations more clearly. Someone who enters the Devlog knows they will find engineering depth and process. Someone who opens the Blog does not need to reconstruct a chain of commits just to understand a product update. That clarity reduces friction while giving us room to write more ambitious pieces in both places.
Covers are no longer optional decoration
Another visible change is the decision that important editorial pieces should have a real cover image. When a publication grows without imagery, the problem is not merely aesthetic. Cards start to look indistinguishable, discovery becomes a wall of text blocks and every article loses part of its identity before it is even opened.
We are treating covers as part of the editorial system rather than an illustration added at the end. They should communicate the topic, work in social previews, remain readable on mobile and fit the Blupoli identity without turning every article into a clone. A piece about catalogue quality can use the idea of a gate or verification pipeline. A design story can visualise the relationship between surfaces. An architecture devlog can show flows, dependencies or layers.
There is a useful side effect: creating a cover forces us to define the article visually before publishing. If we cannot decide what the image should represent, that often means the story itself still lacks a strong central idea. The visual becomes a small editorial test.
Infographics have to explain something
Covers help with identity and discovery, but long-form writing needs another kind of visual inside the article. We have started adding semantic diagrams and infographics because some ideas become clearer when they are seen rather than only described. The important part is that these visuals are not filler.
A flow diagram can explain how a game moves from prototype to published. A comparison can show why Blog and Devlog have different jobs. An architecture map can connect Blupoli, Puzzles, Hosting and domains. The intention is that a reader can stop at the figure and learn something that complements the prose instead of simply resting their eyes on a generic illustration.
This principle is especially natural for puzzles, where many rules are spatial. But it works just as well for product and engineering. A good infographic can summarise a complex decision without flattening it into something inaccurate. And when diagrams are built as part of the page rather than as tiny screenshots, they can remain responsive, accessible and theme-aware.
One logo, one source of truth
The visual identity had also accumulated a small but persistent inconsistency: different parts of the site could render the logo in different ways. There were duplicated marks, symbols recreated in separate components and a footer that did not always resolve the correct asset. The mismatch became especially obvious when moving between the Blupoli home and Puzzles.
The answer was not to redraw another version for every surface. It was the opposite: reduce the number of versions. We created a shared asset and started pointing the different interface surfaces back to the same source. The white B on blue works as a compact mark and can sit next to the written name when space allows. Header, footer and other shared surfaces no longer need to reinterpret the identity independently.
Centralising something as basic as a logo can sound trivial until the next change arrives. If every area embeds its own SVG or recreates the mark with CSS, a small adjustment becomes a hunt through variants. One source of truth prevents that drift and makes it possible to add checks that catch an outdated copy if it reappears.
The shared header matters more than it seems
The top navigation is one of the few components users see across almost every page. If the main site and Puzzles use unrelated patterns, switching subdomains feels like leaving one product and entering an unrelated website. But copying the exact same links everywhere creates a different problem: it ignores the specialisation we are trying to build.
Our solution is to share the visual language and behaviour, not necessarily the exact destinations. Logo, proportions, focus states, button shape, responsive behaviour and interaction patterns should belong to one system. The navigation targets can adapt. Puzzles needs routes connected to play. The home needs to explain the ecosystem. Blog and Devlog need editorial navigation. This keeps identity consistent without pretending every surface has the same priorities.
We are also removing duplicated pieces of shared chrome that historically grew in different files. The more the base component is shared, the less likely it is that a spacing improvement or accessibility fix lands in one place and is forgotten somewhere else.
The footer stops being where leftovers go
Footers often receive less design attention because they live below the fold. In our case that created two problems. On some surfaces the footer felt too dark and too empty, and on mobile it could disappear or be pushed out by the page structure. On top of that, the Puzzles footer did not make it sufficiently clear that there was a broader Blupoli home outside the product.
The redesign gives it a clearer job. It should close the page, offer useful paths, reinforce identity and allow someone to return to Blupoli from a product. We do not want to turn it into a giant sitemap. We want it to be a consistent, readable component in both light and dark themes that does not trap users inside a subdomain.
The footer is also a useful maturity test for the shared system. A footer that works on desktop but disappears on mobile is not finished. A footer that shows a broken logo because its relative asset path changes across deployment targets is not finished either. Fixing it forces us to think about assets, breakpoints, hosting context and accessibility at the same time.
Light and dark mode without making every page an exception
Blupoli had already invested in themes, but splitting the site into clearer surfaces introduced the risk that each one would grow its own interpretation. The current direction is the opposite: theme behaviour should be a platform expectation. If someone chooses a mode or their operating system expresses a preference, the experience should respect it as consistently as possible.
That means reviewing more than page backgrounds. Cards, borders, links, code blocks, figures, active states, secondary text and game surfaces all need adequate contrast in both themes. Blog and Devlog are particularly sensitive because they contain long-form reading. A secondary colour that feels acceptable in a short interface can become tiring over twenty minutes of prose.
The goal is not for light and dark mode to be visually identical. They can have personality. What matters is that both are deliberate and that publishing a new article does not require one-off exceptions just to keep it readable.
Editorial typography needs room to breathe
Separating Blog and Devlog has also let us treat reading as its own experience. A game page optimises space for controls and a board. An editorial page optimises concentration, rhythm and hierarchy. Using the same density for both would be a mistake.
Long articles need a controlled line length, enough spacing between paragraphs, headings that support scanning and figures that interrupt the text intentionally. They also need a header that answers basic questions quickly: what am I reading, what category is it in, when was it published and what is the central idea?
This is part of why we want the Blog to be genuinely enjoyable to read instead of simply becoming a repository of announcements. A three-thousand-word article only works if the design supports that commitment. Excellent writing can still feel exhausting if the interface ignores reading ergonomics.
The Blog home stops being a mixed pile
When every editorial piece shares one undifferentiated list, categories stop helping. A Sudoku guide can appear next to an infrastructure note, followed by a brand announcement and then a debugging diary. Technically they are all articles. Editorially they do very different jobs.
The new organisation introduces clearer categories and allows the Blog hub to behave more like a publication. News and product changes can coexist with guides and puzzle articles without hiding the fact that they belong to different families. The Devlog, meanwhile, can organise development, architecture, design, AI, quality and learning without flooding the public-facing Blog.
This improves discovery as well. Someone who arrives from search on an Akari guide can find related puzzle content. Someone reading about the new quality strategy can continue into the Devlog that explains the gate in technical detail. Links stop being random and start forming meaningful paths.
Designing connections between surfaces instead of walls
Separation should not mean isolation. In fact, the new structure only works if the surfaces connect better than before. A Blog article about restructuring the catalogue can point to the technical Devlog that explains the quality gates. A piece about a specific puzzle can link directly to Blupoli Puzzles when that game is actually published. A design story can connect to the new catalogue strategy because both decisions share the same principle: less noise and more intention.
The challenge is making those links useful rather than promotional. We do not want every paragraph to end in another call to action. We want to build context. If one article explains the result and another explains the process, they complement each other. If a guide describes a mechanic and a playable version exists, it makes sense to offer it. If a future idea is still only planned, we should not pretend there is something to try.
SEO is also information design
Canonicals, titles, hreflang, social metadata and structured data are often treated as technical tasks separate from design. In practice, they describe the architecture to search engines, browsers and social platforms in the same way navigation describes it to people. If Blog and Devlog look separate but the metadata still calls everything Journal or Devlog, the system continues to tell two conflicting stories.
That is why the migration includes cleanup of names, publishers, browser titles, descriptions, routes and historical references. “Blupoli Puzzles” remains where it is necessary to explain the past, but the active identity is Blupoli and the product is Blupoli Puzzles. In the same way, “Devlog” may remain inside legacy file names for compatibility while the public-facing section is called Devlog.
These choices make the site more coherent even outside the site itself. A shared link should show the correct cover and brand. A search engine indexing an English and a Spanish version should understand that they are genuine alternates rather than accidental duplicates. When a route changes, a redirect should preserve history without turning the old architecture into the new identity.
A responsive website is not a desktop layout made narrower
A large part of the recent design work has also focused on mobile. The catalogue and the games had already taught us that shrinking widths is not enough. Navigation needs different states, controls need sensible touch targets and a footer that works after a desktop column can behave very differently around persistent mobile bars.
Blog and Devlog have their own responsive challenges. A large cover image has to retain hierarchy without pushing the article itself too far down. Infographics need to reorganise nodes and labels without requiring zoom. Code should never break the layout. Editorial navigation has to remain available without consuming half the screen.
We are trying to turn those decisions into shared components and rules so that every new piece inherits good behaviour by default. The real value of a design system is not that it makes page one faster. It is that page fifty does not need fifty unique patches.
The design system is starting to remember
There is another, less visible change that matters a lot to us: we are adding checks so that solved inconsistencies do not quietly return. A shared logo can be tested. Legacy branding can trigger a build guard. A publication can require a cover, metadata or a particular structure. An editorial route can be validated.
That turns visual and editorial decisions into contracts. It does not freeze the design. It means that when we change a convention, we do it consciously and update the contract. This is especially useful in a project where agents, scripts and automation contribute to the workflow. Documentation gives direction; automated checks make it harder for an isolated task to reintroduce a contradiction we already resolved.
What we are not trying to do
We do not want Blupoli to pretend it is a giant corporate suite before the products exist. We also do not want to create five empty subdomains just because the architecture allows it. The home should remain compact. Puzzles should stay easy to understand. Blog and Devlog should justify their existence through content, not through menus.
That is why some internal names will remain legacy-shaped for a while and some routes will migrate incrementally. Renaming everything at once could produce a beautifully clean tree and a pile of regressions. We prefer the public identity to be coherent while the internal infrastructure evolves safely.
We are not trying to make every page visually unique either. Personality belongs in the content, covers and purpose. Chrome, base components, the logo, theme behaviour and interaction patterns should remain predictable. Consistency creates room for the articles and puzzles themselves to stand out.
We share the structure that creates trust and specialise the parts that create purpose.
What you should notice when navigating now
The accumulated result should feel calmer. When you enter Puzzles, the focus is play. When you open the main home, the brand does not advertise products that do not yet exist. When you visit the Blog, public stories have a more deliberate editorial treatment, with covers and categories. When you enter the Devlog, the name tells you what kind of depth to expect. Header and footer are beginning to speak the same visual language. And the logo is no longer determined by whichever folder happened to be edited most recently.
Not every change should demand attention individually. That is a good sign. A useful design system does not need every component to announce that it has been redesigned. It should remove small points of friction until the overall navigation feels more obvious.
We will keep tuning details as more real content flows through the system. The best editorial design decisions only become visible after seeing very long titles, different image styles, uneven category volumes and articles that genuinely exceed three thousand words. The important thing is that we now have a structure that can learn from those cases without collapsing responsibilities back into one place.
The new Puzzles strategy and the redesign are the same decision
At first glance, marking unfinished games as “coming soon” and separating Blog from Devlog may seem unrelated. To us they express the same principle: make the real state of things visible. A prototype should not pretend to be finished. A development diary should not pretend to be a product announcement. An umbrella brand should not pretend to be only a puzzle catalogue. And a duplicated component should not pretend to be part of a shared system.
We are trying to make the interface honest about architecture and maturity. That may reduce some visible numbers in the short term and it means spending more time on every published game or article. In return, everything that remains visible carries a clearer meaning.
You can read more about this product decision in A new stage for Blupoli Puzzles. If you are interested in the technical side, the Devlog about the editorial split goes deeper into architecture, migration and compatibility decisions behind the new organisation.
Designing a home we can keep growing in
Blupoli is still at an early stage. That makes it tempting to postpone this kind of work and invest every hour in more games or immediately visible features. It is also the best moment to define boundaries before every exception becomes a dependency.
We want a site where it is easy to understand where you are, what you can do and what kind of content you are reading. We want Puzzles to grow without carrying the full weight of the brand. We want the Blog to be interesting even to someone who never looks at our commits. We want the Devlog to preserve the memory of development without turning every announcement into an engineering lecture. We want the logo, footer and navigation to feel familiar even when the subdomain changes.
That is what this redesign means at its core. It is not a new coat of paint but a house with better-defined rooms. We will keep moving furniture, correcting proportions and learning from use. But for the first time the structure is beginning to mirror the project we actually want to build: one shared brand, products with purpose and a publication that knows when to tell the result and when to show the process.