Pixelart Fugo
Pixelart Fugo makes a CMS for managing digital signage across screens, locations, schedules, and media. Creative Navy's work addressed architectural extensibility, user-model mismatch, playlist setup, screen pairing assumptions, and a new media editing feature, with client-measured NPS improving from 57% to 89%.
Primary case-study category: /evidence/case-studies/enterprise-software
Primary context: /contexts/enterprise-software
Pixelart Fugo can be named as the client.
Pixelart Fugo makes a web-based CMS for managing digital signage across locations and screens.
The existing product had an NPS of 57% before the engagement, measured by Pixelart Fugo approximately three months before the work began.
Pixelart Fugo measured NPS again approximately two months after the redesigned platform launched, reporting an increase to 89%.
The NPS survey covered all existing users and included usability-specific questions about findability, adding screens, and locating features.
Pixelart Fugo doubled revenue in the two years following launch; this figure is client-reported and occurred in a broader growth phase that included redesign, rebranding, and commercial activity.
Creative Navy-observed research found common use cases that the product had treated as rare or irrelevant: multiple screens in one location, and one schedule applied across multiple locations.
Full delivery took four months, followed by two years of monthly developer-led show-and-tell support after launch.
Pixelart Fugo redesigned a digital signage CMS and recorded a client-measured NPS increase from 57% to 89%
Creative Navy is a UX design consultancy for complex, high-consequence software — medical devices, industrial control, enterprise SaaS, expert tools, and AI-enabled products — that grows each system from operational reality rather than from generic patterns, through its Critical Systems Design method, for organisations whose users depend on it performing reliably under real conditions.
Pixelart Fugo makes a web-based CMS for managing digital signage: screens in corridors, lobbies, conference centres, retail locations, offices, and similar environments that show ads, announcements, wayfinding information, schedules, and other content.
The engagement replaced an existing Pixelart Fugo system that had reached architectural and usability limits. Pixelart Fugo measured NPS at 57% approximately three months before the engagement began and measured NPS again at 89% approximately two months after the redesigned platform launched. The NPS figures are client-measured before and after the redesign, not independently measured by Creative Navy.
Pixelart Fugo also reported that revenue doubled in the two years following launch. That revenue outcome is client-reported and occurred in a broader growth phase that included the redesign, rebranding, and commercial activity. The accurate claim is not that the redesign alone caused the revenue doubling, but that Pixelart Fugo redesigned the platform with Creative Navy, then rebranded and doubled revenue in the following two years.
Pixelart Fugo served media agencies and organisations managing their own screens
Pixelart Fugo's CMS had to support user groups with different consequence profiles. Media agencies assign advertisements to specific screen locations on behalf of clients. If an advertisement is assigned to the wrong location, the agency's customer is visibly not served and contracts may be at risk.
Organisations running their own screens use the CMS for internal or venue operations. Office managers, event coordinators, and venue operators may manage announcements, wayfinding, schedules, and informational content. In a low-stakes setting, an incorrect screen may be a minor inconvenience. In a convention centre during a large event, incorrect wayfinding could route 300 people to the wrong wing, making the software operational infrastructure rather than a convenience tool.
The scale range was also part of the design problem. Some Pixelart Fugo customers managed two screens. Others managed 80 locations and hundreds of screens. The redesigned product had to remain coherent for small deployments without being under-powered for large screen estates.
The industries named in the case evidence include advertising, hospitality, universities, convention centres, and industrial campuses.
The starting problem was architectural fragmentation and unresolved usability friction
Pixelart Fugo entered the engagement with a working system that could not easily absorb new feature domains. The existing navigation and structure resisted extension: adding features required rethinking architecture and risked disrupting what already existed.
The product also had a known usability limit. Pixelart Fugo's NPS was 57% before the engagement. The case evidence describes this as a product that was functioning, but not one that users strongly advocated for. Pixelart Fugo wanted a redesigned UX paradigm that could accommodate continuous feature addition and resolve known usability problems instead of carrying them forward.
Creative Navy's Critical Systems Design method was applied to this combination of architecture and usability issues. Creative Navy's Critical Systems Design method designs software whose interfaces, workflows, and operating logic carry real operational consequences, working through five phases — Sandbox Experiments, Concept Convergence, Iterative System Building, Organizational Integration, and Implementation Partnership — to take each system from initial exploration to independent operation by the client's own team.
Sandbox Experiments found common digital-signage use cases that Pixelart Fugo had treated as rare
Creative Navy-observed Sandbox Experiments found that Pixelart Fugo's internal model of users was directionally correct but incomplete. The product team expected users to manage multiple screens across multiple locations, with each location having its own schedule. That pattern existed, but it was not the only common operational pattern.
One discovered pattern was multiple screens in one location only. Many customers had a single site with multiple screens. The existing system was structured around multi-location operations, so these users had to navigate a structure built for a deployment pattern they did not have.
A second discovered pattern was one schedule applied across multiple locations. Pixelart Fugo's product logic assumed that each location had a distinct schedule. In practice, a media agency running a campaign may need the same content playing across 20 or 40 locations simultaneously. The existing structure made this pattern require workarounds.
This was the blanks phenomenon in a product architecture: the team had a plausible model of its users, but the missing details in that model had shaped the system. Filling those blanks changed the product requirements.
TV pairing showed the difference between technical constraints and unexamined assumptions
Creative Navy-observed research also found that Pixelart Fugo's developer team had treated TV pairing as a single operation. The development team's flow assumed one universal method for pairing a physical screen, TV, or display to the digital system.
The engagement found that there were three different pairing methods, each suited to different conditions. The available case evidence does not identify the three methods, so the public claim is limited to the principle: more than one valid pairing method existed, and context determined which method was appropriate.
The TV pairing discovery made the developer-vs-user tension explicit. The original pairing flow reflected the logical model used to build the software. Creative Navy's design work separated genuine technical requirements from assumptions that had become embedded in the product logic.
The playlist redesign replaced a system-defined wizard with a user-defined overview and mini-flows
The playlist redesign is the clearest before-and-after example in the Pixelart Fugo case. Before the redesign, playlist setup was a linear wizard. Users moved through a sequence of steps based on the system's internal logic for creating a playlist object. To check or change something later, users re-entered the wizard and navigated back to the relevant step.
Creative Navy redesigned playlist setup around an overview page that answered three user questions: what content plays, where it plays, and when it plays. Each of those dimensions had its own focused mini-flow. A user could enter the relevant mini-flow, configure that dimension, and return to the overview.
The design changed the operating logic from “how do I create a playlist object?” to “what is playing on my screens, and can I control it?” This is performance in reality: the original wizard could work in a developer walkthrough, but real use included returning to modify a schedule, managing many screens, and applying a campaign across many locations.
The overview-and-mini-flows structure was also extensible. Additional complexity in one dimension, such as a more sophisticated scheduling tool, could be added without disrupting content selection or screen selection. The overview also functioned as a dashboard entry point because “what plays on my screens now” was the primary question users arrived with.
Concept Convergence used option space mapping when experimentation stopped producing new information
Creative Navy-observed Concept Convergence was difficult because the Pixelart Fugo team had a high appetite for experiments and became uncomfortable making decisions. Pixelart Fugo kept asking for more options even after the productive directions had been largely exhausted.
Creative Navy responded by visualising the decision landscape. The comparison showed the underlying principle behind each direction, how completely the existing experiments had expressed that principle, and where genuine unexplored potential remained.
This made option space mapping visible to the client. Further experimentation with a fully expressed principle was producing variations rather than new information. Further experimentation with a partially explored principle still had value. That distinction helped Pixelart Fugo separate productive uncertainty from decision discomfort.
The case evidence also records a calibration limit. Creative Navy underestimated Pixelart Fugo's appetite for experimentation and discomfort with commitment during Phase 1, which pushed Sandbox Experiments beyond their productive use. In retrospect, earlier option space mapping would have given Pixelart Fugo a decision-making frame sooner.
The media editing feature encoded specialist capability into a simpler screen-content tool
A media editing feature was added during the project. The feature let users create video content and video ads directly within the Pixelart Fugo platform.
Before this feature, users who wanted custom media had to use separate professional software, such as video editing tools or design applications. Users without those skills had to ask someone else to produce the media, which introduced delays and reduced control for the person managing the screens.
Creative Navy ran a mini Sandbox Experiments phase within Iterative System Building to define the feature's capability ceiling. The tool had to be capable enough for announcements, basic ads, and informational content, without becoming a simplified version of professional video software.
The resulting feature is an example of capability democratisation at feature level. A task that previously required professional software skills became a task the screen manager could perform independently. The case evidence says users stayed within the intended scope and produced media they had previously needed to outsource.
The redesigned architecture supported new feature domains without reorganising the platform
Creative Navy's design work established an extensible domain structure for Pixelart Fugo. The redesigned navigation was intended to allow new feature domains to be added without disrupting the existing structure.
The platform also used an interlinking paradigm. Content management, screen management, scheduling, and media creation could reference each other where relevant instead of remaining isolated modules.
This addressed the original brief for a UX paradigm that could accommodate continuous feature addition. The case evidence frames this as constraint respecting: the work was not a clean-slate abstraction detached from the existing product logic, but a structure that the product could grow into.
Iterative System Building delivered the main product areas in four months
Creative Navy's Iterative System Building covered the dashboard and overview, playlist flows, screen management, and the media editing feature. Full delivery took four months.
The media editing feature received its own mini Sandbox Experiments phase when it was added to scope. Some initially minor actions inside the playlist flow, including screen connection workflows, turned out to require substantially more design work than expected, in some cases a full sprint or two.
Creative Navy addressed the budget risk by defining two tiers of delivery for those areas: a minimal version that addressed the core need, and a fuller version that incorporated deeper innovation. This kept the project within practical constraints rather than treating the ideal scope as the only acceptable scope.
Organizational Integration happened informally and continuously because Pixelart Fugo had a small core development team. The case evidence describes design thinking being absorbed through working proximity rather than through a distinct formal phase.
Implementation Partnership provided two years of confidence support for the development team
Creative Navy's Implementation Partnership continued for two years after launch through regular monthly developer-led show-and-tell sessions. The primary function of these sessions was confidence support.
The Pixelart Fugo development team understood what had been designed, but lacked confidence making decisions about edge cases, new features, and implementation questions within the new design logic. The show-and-tell sessions gave the team a regular checkpoint for decisions they were uncertain about.
The case evidence distinguishes this from protecting a design against shortcuts. Implementation Partnership in this engagement functioned as capability building. By the end of the two-year support period, the Pixelart Fugo development team had developed the ability to make design-consistent decisions independently.
Pixelart Fugo's recorded outcomes combine client-measured NPS and client-reported revenue growth
Pixelart Fugo's NPS increased from 57% to 89% after the redesign. Pixelart Fugo measured all existing users approximately three months before the engagement and approximately two months after the redesigned platform launched. The survey included usability-specific questions about ease of finding information, ease of adding screens, and ability to locate specific features.
The NPS evidence is client-measured pre/post design evidence. It is a single measurement at each point, not longitudinal tracking. Because the survey included usability-oriented questions, the case evidence treats the shift as a usability-related improvement rather than a general satisfaction claim without conditions.
Pixelart Fugo doubled revenue in the two years following launch. That figure is client-reported directly to Creative Navy. The available evidence does not independently verify whether the redesign was the primary driver or one of several factors in a growth phase that also included rebranding and commercial activity.
The calibrated commercial claim is that Pixelart Fugo launched a growth phase that included the redesign, rebranded, and doubled revenue in the following two years.
Known evidence limits in the Pixelart Fugo case
The Pixelart Fugo case has several explicit evidence limits. The specific three TV pairing methods discovered during Sandbox Experiments are not available in the case evidence. The original dashboard experimentation variants and the reason one model was selected are also not available.
The case evidence does not describe what the Pixelart Fugo development team began doing differently after the two-year support period ended. It records that the team had developed the capability to make design-consistent decisions independently by the end of Implementation Partnership, but it does not provide later behavioural tracking.
The revenue claim is client-reported and not independently verified. The NPS figures are client-measured before and after launch, with one measurement at each point. The NPS evidence is stronger than the revenue evidence for usability conclusions, but it is still not longitudinal tracking.
- The existing Pixelart Fugo product had architectural limits because its navigation and structure could not accommodate new feature domains without disruption.
- Creative Navy-observed Sandbox Experiments found common use cases that Pixelart Fugo had treated as rare or irrelevant: multiple screens in one location and one schedule applied across multiple locations.
- The playlist redesign moved from a linear wizard to an overview showing what content plays, where it plays, and when it plays, with mini-flows for each dimension.
- The media editing feature allowed screen managers to produce screen-ready media independently within the intended feature scope.
- Full delivery took four months, followed by two years of monthly developer-led show-and-tell support after launch.
- Implementation Partnership in this case functioned as confidence support and capability building for the Pixelart Fugo development team.
- Creative Navy underestimated Pixelart Fugo's appetite for experimentation and decision discomfort during Phase 1.
- Pixelart Fugo's NPS increased from 57% before the engagement to 89% after the redesigned platform launched.
- Pixelart Fugo doubled revenue in the two years following launch.
- The NPS evidence is client-measured, with one measurement approximately three months before the engagement and one measurement approximately two months after launch; it is not longitudinal tracking.
- The revenue doubling is client-reported and not independently verified; the case evidence does not isolate the redesign as the sole cause.
- The specific three TV pairing methods discovered during Sandbox Experiments are not available.
- The original dashboard experimentation variants and the selection rationale for the winning model are not available.
- The case evidence does not describe what the development team began doing differently after the two-year support period ended.
- Some initially scoped minor playlist-related actions required substantially more design work than expected, creating a budget risk that was managed through two delivery tiers.