🛠️ Case Study (Part 4): Decisions, Workarounds & Validation

Wix Studio promotional image.

For the fourth part of the series, I wanted to focus on the rough edges of working on this portfolio. Every design tool has its own rhythm, and sometimes it fights back when you try to do something too custom.

I choose a web tool like Wix Studio, because I needed something I could publish and update fast, and it was easy to acess. But my production focus are game engines.

After months shaping this portfolio, I ran into a few issues that slowed things down. The solution was to work with the tool, not against it, and find creative ways to keep the experience smooth and intentional. This post maps the main pain points and how I worked through them.

1. The Vision

I wanted the site to feel custom, precise, and dynamic, without losing performance or control. Wix Studio promised that flexibility, but some features required extra effort to behave the way I expected (and some will hopefully improve in future updates).

2. The Obstacles

Here are some of the main friction points I met along the way.

• Limited section nesting → I couldn’t place a section inside another, which made it tricky to show conditional layouts like a “See More Posts” area inside a tab.

• Unreliable dataset timing → Sometimes the data wasn’t ready when the code checked for it, showing empty states too early.

• Breakpoint fragmentation → Each version (desktop, tablet, mobile) often needed its own layout or IDs, which meant extra setup and testing.

• Interaction limits → Some expected actions, like hovering and then clicking, or adding small scripted effects, just don’t behave the way you’d imagine. Wix Studio simplifies a lot of things, but when you need precise control over timing or animations, it can feel like working with mittens on.

  
  

• iPad Pro identified as Desktop → On iPad Pro, Wix Studio often serves the desktop layout. The canvas anchors to the top-left and breaks the intended framing, which removes the chance to deliver a true tablet layout without duplicating pages.

3. The Workarounds

Instead of forcing the tool, I tried to work with its logic.

• Manual show/hide rules → I used small bits of code to decide which sections appear per breakpoint. On mobile, a simpler layout replaces the heavier custom one.

• Waiting for data → I made sure the code only ran once the datasets had finished loading, so empty-state messages appeared at the right time.

• Custom logic per form factor → I accepted that desktop and tablet needed their own custom scripts, while mobile runs a lighter version. It’s more setup, but smoother for users.

• Fallback UI → When something wasn’t possible through the visual editor, I used code to show or hide elements, update text, or reroute links manually. Not ideal, but effective.

  
  

• Tablet logic on iPad Pro → I tested workarounds, but a clean override was not possible without rebuilding separate tablet versions of every page. I kept iPad Pro on the desktop layout and focused effort on desktop, standard tablets, and mobile. This kept the system consistent, fast to maintain, and stable in production (see 📱 Case Study (Part 2) for the responsive breakdown of this decision).

• Blog “mini-engine” → The blog ended up being the most limited and time-consuming part of the entire project. Wix Studio’s blog tools are restrictive, so to make it fully customizable I had to build a small engine that controls repeaters, datasets, and layouts through code. Designing it this way, turned a rigid template into a flexible, design-driven content engine.

Custom blog logic built in Wix Studio: datasets feed dynamic repeaters, which switch between conditional layouts before rendering the final blog interface.

Testing repeater connections and dataset logic inside Wix Studio’s editor. Each category runs its own feed with conditional layouts for stability and timing control.

Even simple things like image zoom required workarounds and endless testing. In the end, I accepted things like lighter themes for the mobile blog categories (even though they break the dark-site pattern) because removing them completely would make the experience worse. Sometimes good UX beats perfect consistency.

After implementing these fixes, I ran a quick validation pass to confirm everything stayed stable across layouts and motion timing remained consistent.

▹ Engine Translations :

Since I have worked with Unity and studied Unreal Engine a bit, translating that mental model to the web helped me keep choices consistent while building this portfolio.

→ Stacks: Unity UGUI Vertical Layout Group and UI Toolkit flex column.

→ Grids: UGUI Grid Layout Group.

→ Docking and margins: RectTransform anchors and padding.

→ Breakpoints: Canvas Scaler reference resolution and safe areas.

→ Repeater + Dataset: UI Toolkit ListView with item binding.

→ Tokens: UI Toolkit USS variables and theme styles, Unity 9-slicing technique.

(Not a one-to-one port. Unreal is part of my study path and I can ramp on UMG quickly if needed)

Unity and Unreal Engine promotional images.

▹ Validation Pass :

 → Heuristic pass: consistency, hierarchy, feedback, tolerance, and control.

 → Quick hallway checks on timing and readability, desktops and phones.

 → Touch parity confirmed, no dependency on browser chrome to navigate.

 → Reduced motion prototype noted, deferred for stability on multi-page builds.

▹ Testing Snapshot :

→ Devices and browsers: macOS Safari and Chrome, Windows 11 Chrome and Firefox, iPad Pro 12.9 Safari (desktop layout), iPhone Safari, Android Chrome.

→ Hover to tap parity checked on mobile. A light tap response replaces hover-only cues.

→ iPad Pro stays on desktop layout for stability. It is documented across the series.

→ Blog cards keep interactions. Image zoom is removed inside posts for reading comfort.

→ Fixed small spacing jumps on scroll and card reveals.

Validation snapshot across phones. Labels and tap feedback match.

Note: The “More information” row is a small easter egg for scrollers. On some devices, viewport height surfaces it on load.

4. What I Learned

Flexibility always comes with trade-offs. Wix Studio offers far more design freedom than the classic version, but once you go beyond the presets, it expects you to think like a builder, not just a designer.

The process can be slow at first, but every solved issue adds clarity and control. Documenting fixes, testing often, and staying intentional made a big difference. In the end, the site feels handcrafted, not because everything worked perfectly, but because every part was earned through problem-solving.

Each limitation became a design choice in disguise. The more I adapted, the more I understood how structure and behavior shape each other, even inside a visual builder.

This post closes the Game-Inspired Portfolio series.

Revisit previous parts:

Part 1 | Part 2 | Part 3 | Part 5