NobarCloud

02 / Architecture & The Fix

Nothing here started from a blank Figma file. Every pattern had a document behind it before it had a shape: bento grid for the dashboard, button placement inside a modal, all of it reasoned through first.

A design system built specifically for this, documented as its own case study.

Every pattern referenced in this section, the bento grid, the component states, the bilingual and dark/light handling, came out of a dedicated design system built alongside the product, not bolted on after. That system is documented in full as a separate case study: how it was structured, why, and what it enabled.

Competitor research, two fronts:

• Regional: ArvanCloud, Liara, Sotoon
• Global: AWS, DigitalOcean, Vercel, Hetzner, OpenStack

Not to copy them. For every feature and every screen, there was a real answer to “what does the best version of this already look like,” and the job was to go past that, not localize it.

Four prioritization models, never interchangeable:

• Kano: delight vs. baseline expectation
• MoSCoW: the hard line for a given sprint
• RICE: reach against effort, for anything big enough to deserve the math
• Effort/Effect: the quick call, when speed mattered more than process

We matched prioritization frameworks to context instead of forcing one model onto every decision, in order to keep sprint-level calls sharp without sacrificing rigor on larger bets, and the result was 16 months of shipped work with low rework and low back-and-forth with engineering, evidence the approach scaled with the product rather than slowing it down.

User motivation, mapped before features got built around it.

Not every user wants the same thing from a cloud panel, and treating them all the same was a known way to lose both ends. The Marczewski Gamification Framework was used to classify user types by what actually drove them, before deciding what to build or incentivize:

• Achievers wanted to see progress: uptime stats, resource efficiency, a visible sense that their infrastructure was well-run
• Philanthropists were the senior engineers referring teammates and writing internal docs about Nobar Cloud unprompted, driven by helping others succeed, not by what they personally got out of it
• Free Spirits wanted to explore and configure without friction, Memar’s guided provisioning was partly built to give this group room to experiment without real risk
• Players responded to the credit system and milestone rewards, incentives moved them more than architecture did
• Disruptors were the ones who broke flows intentionally to find edge cases, their feedback shaped a disproportionate share of the error-state design

This wasn’t a framework applied for its own sake. Features like the Memar guided flow, the referral mechanism, and the credit system were each built with a specific motivation type in mind, not as one-size-fits-all additions.

Infrastructure came before design, not after.

Open technical questions went to the infrastructure team first, before a single screen got built around them. Resolve what’s actually possible, then design inside that, not the other way around, finding out three weeks later something can’t ship. Separate sessions ran just so infra and technical teams saw the direction early enough to push back while pushing back still mattered.

That ordering is most of why handoff stayed light:

• A real design system meant engineering wasn’t guessing at values
• Infra already knew what was coming
• Error states and edge cases were spelled out in the file itself, engineering could build from it without a single Slack message asking “what happens if this fails”

Not everything landed easily, though.

We restructured panels, flows, data displays, and feature access to fix root usability problems instead of preserving familiar-but-buggy patterns, in order to solve the actual problem rather than repeat a known one, and the result was validated user outcomes that flipped internal skepticism into full buy-in, a shift that carried forward into every unconventional call made after it.

Two designers, split by strength, not by ownership.

Hanie Mansour Kiai and I worked across the full 16 months without splitting the product into “my parts” and “her parts.” Both of us stayed onboarded on everything, specifically so either one could step in if the other hit a wall mid-sprint, a server-side launch deadline doesn’t wait for one person’s calendar to clear. That overlap also meant every pattern got a second set of eyes before it reached engineering, catching gaps neither of us would’ve caught working solo.

Feedback came from wider than the design team, on purpose.

We widened feedback loops to include infrastructure, support, and sales rather than keeping pattern decisions inside design, in order to catch blind spots a design-only process would miss, and the result was fewer late-stage surprises and a product that held up under real operational and customer-facing conditions, not just usability testing.

RBAC, because B2B teams aren’t one account.

Eight months in, the role changed.

The founding design role became product manager for the second half.

Cursor became the fast lane for this: rough low-fidelity flows built quickly, tested, handed to design only once the direction held up. Validating a flow and polishing a flow stopped being the same step, so neither one slowed the other down.

The toolkit behind every decision, not just the metrics it produced.

Data wasn’t gathered once and filed away, it ran continuously, across tools chosen for different jobs:

• Google Analytics for funnel-level behavior: where traffic came from, where it dropped
• Microsoft Clarity for session recordings and heatmaps, watching real users hit real friction, not inferring it from a dashboard
• Maze for testing flows at low fidelity before a single pixel got polished, catching a broken flow while it was still cheap to fix
• Cursor for building those low-fidelity flows fast enough to test weekly, not monthly

Each tool answered a different question. GA said where people left. Clarity showed why. Maze tested whether a fix actually worked before it got built for real. That layering is what kept the team from optimizing against a single, misleading number.

Usability alone stopped being the question. AARRR took over as the lens, and each stage of it had its own page-level targets, not a single shared metric sheet everyone squinted at differently.

• Acquisition / Activation: scroll depth, time on site, signup-to-first-server time
• Engagement / Retention: full flow completion rate, bounce rate reduction, monthly active teams
• Revenue: site-to-console conversion, churn, expansion revenue per account

03 / Impact & Outcome

What this added to the team and the product.

Nobar Cloud shipped a fully designed B2B cloud platform in four parallel versions across seven console modules, backed by a documented rationale for every pattern and a measurement discipline most teams that size don’t bother building.

Research and validation infrastructure, not just screens:

• A 4-layer design system that kept engineering handoff fast enough that most flows shipped with under 2 rounds of revision after the first design review
• 100+ flows, each specified with every error state and edge case before reaching engineering, most of why technical back-and-forth stayed low across 16 months
• A continuous JTBD and proto-persona-to-persona pipeline that caught unmet user needs before launch rather than after a support ticket flagged them
• User segmentation via the Marczewski Gamification Framework, directly shaping features like Memar’s guided provisioning and the referral mechanism

What the growth mechanisms were built to move:

Qualitative signal that doesn’t fit a spreadsheet:

• Candidates and industry peers cited the product as a reason they wanted to work with the team, repeatedly, unprompted
• Internal resistance to the restructured panel and flow architecture reversed into full buy-in once user outcomes validated the direction, and that trust carried into every unconventional decision after
• Feedback loops deliberately crossed outside design, infrastructure, engineering, support, and sales all shaped pattern decisions before they were finalized, not after something broke in production

Then the war happened.

Nobar Cloud shut down during the war. The team continued for a short period afterward with reduced scope, then the project ended entirely, with part of the remaining team absorbed into an external partner company. None of that reflects on the work. Sixteen months of documented, cross-validated, metric-driven product design doesn’t get undone by a macro event no product decision could have hedged against.