Vazgen Harutyunyan

Lumenarc

This is the qualification UI the agent runs before each demo. The layout came out of Figma, but to make it feel right in motion I needed to tweak it live. So I built the debugger on the right. It lets me override avatar animation states, user voice intensity, transition timing, easing, and every other parameter without leaving the running app.

This is a pattern I use constantly now. Instead of going back to Figma to adjust a value and re-export, I build a tool that exposes the variables I care about inside the page itself. I started doing this in Cursor when I first got serious about AI and code, and now I'm working almost entirely in Claude Code. More of my design work happens in code than in Figma these days, and this debugger is one of the clearest examples of why.

Shot shows the live demo experience from the user's side. Lumen runs a pre-recorded version of the client's product and walks the user through it the way a salesperson would. You can see the Lumen pointer hovering over the Scheduled tab, guiding where to look next. The agenda card on the lower right shows where the user is in the demo flow and what is coming up.

This shot shows the agent moving through its different states. I built the animations from scratch for listening, thinking, and idle, then combined them so the mark itself signals what the agent is doing. The same system carries across every Lumenarc deployment, which means clients can name their agent something other than Lumen and the brand still holds. That call gives Lumenarc more brand exposure than a single humanoid avatar ever would.

This is the studio side of Lumenarc, where the client sees what happened on every session the agent ran. Each session opens up to show an AI-generated highlights summary, every objection the agent handled, the call recording, sentiment scores, talk ratios, and a recommended next step.

The point of this view is the feedback loop. Everything the agent did gets captured and broken down so the human team can review it, and so the agent itself can improve from previous conversations. Objections that came up, moments that landed, prospects worth following up on, all of it is structured for both human and agent to learn from. I designed the layout to be scannable in seconds because anyone running a demo program will be in this dashboard daily.

ProSky

This is where the actual assignment happens. The accounting line from the airline's billing file sits on the left, and the user browses every booking and passenger inside the matched project on the right to find the one it belongs to.

The data is dense and the stakes are high. A single project can have dozens of passengers and multiple bookings, with several charges that look almost identical until you check the reference numbers. I designed this view so the user can move through matching work without losing their place. Source data stays pinned on the left, the matched project is summarized below it, and the browse list on the right is filterable by all, booking, or passenger. The assign button is the only commit, and once it fires, the whole line moves out of the unmatched queue.

This is the project overview, before on the left and after on the right. Navigation has been an issue here for a long time. The data has only gotten denser as the platform has grown, and the old layout could not keep up.

The rework is not just a visual refresh. I'm building a clear design system underneath it so the next iteration of this view, and every other view, sits on the same foundation. No more one-off components, no more drift between pages that should feel like the same product.

Booking details is the densest screen in the product. The challenge is the same as everywhere else in the rework, just sharper. Show a huge amount of data without making the page collapse into noise.

The old version drifted over time. Several developers shipped to it over the years, and the design system that was defined back then did not hold. That is the failure mode I am designing against in this rework.

Stackdrop

This is the illustration system shown as a set. I built it so every concept on the site gets drawn the same way: isometric, on the construction grid, in the same line weight and palette, whether it's a connection diagram, a document grid, a database cluster, or a data signal.

This is a single illustration from the system, shown at full size. The layered card construction stays in the isometric perspective the rest of the site uses, drawn in the same line weight and palette, sitting on the same construction grid.

This is from one of the UX consultations I ran while working with Stackdrop. drdm.io was one of their clients, a contract-management platform that had been built for its own developers, not for the outside companies about to onboard onto it. The original had redundant pages and a navigation structure that didn't match how new users would think.

Over a series of sync calls, I reorganised the full page architecture into clear, reusable groupings and defined the happy-path flows the team could build against going forward. The goal was to move the product from developer-ready to user-ready, aligned with the patterns its future users already expect.

I did similar consultation work for several other Stackdrop clients during that engagement. This one is included as a representative example of the UX reasoning and pattern thinking applied across that work.