Recreated for this portfolio — not the original product UI.
Problem
We needed a prototype of an AI chat assistant that would live inside the product and let users ask questions about the data on their current dashboard. Specifically, one that was high enough fidelity to accomplish three things:
01
Give engineering an exact reference for animation and interaction behavior
02
Support future user testing and research
03
Convince stakeholders in a way static comps couldn't
Figma's native prototyping tools weren't accomplishing those needs for us. The animation complexity and the branching click paths the experience needed were beyond what click-through prototypes could achieve.
Prototyping AI with AI
To hit those goals, I moved prototyping into Windsurf (now Devin), using their AI tool Cascade, which was wired directly into the design system repo — meaning the prototype pulled real components and tokens instead of approximating them. I came onto the project to help the team get started on this workflow, having just recently started learning and experimenting with that process myself. My task was to turn a fellow designer's static designs into a working, interactive prototype.
My Role
I turned existing designs into a functional prototype using Windsurf, working section by section to get visual fidelity right.
The org was mid-transition between two design systems: an established one most teams and products were using, and a newer one still early in adoption. We made the call to visually align the prototype with the newer system's direction, pulling its spacing, typography, and color tokens. Components relied on the older system where needed, since the newer system didn't yet have all the components that were required.
Once Windsurf's AI had learned the design language, adding on new features got significantly faster. New features and screens could be added, and the AI would keep them visually consistent with the rest of the system without much back and forth and correction.
Identified gaps the static designs hadn't answered yet and explored ways to solve them during implementation.
Worked across two branches, one tracking close to the intended V1 scope, one for experimenting with features beyond it.
Exploring Beyond V1
While working on the V1 build, I used the second branch to prototype ideas outside V1 scope, exploring things that would be nice to have in future versions. I also took the opportunity to make design changes based on feedback pulled from a design crit on the product, and researched other AI chats and apps to see how they handled similar features and problems. Some of those were:
01
Iterated on menu placement, testing buttons in the header against a hamburger menu that slid out
02
Explored how to switch between the two AI models the assistant would support
03
Explored chat pinning as a feature
04
Worked design crit feedback directly into the experimental build to test ideas quickly
This branch was paused after V1 shipped, so none of these explorations had been migrated into the main product yet by the time my role ended.
Status
I was in the middle of this project when my role at the company ended, so I didn't see it through to final use. The intent going in was for it to guide engineering handoff, support upcoming user testing, and serve as a high-quality stakeholder demo.
Press Ganey · Product Design · 2025
Market Experience Design Sprint
A New Analytics Dashboard Concept
Why a sprint
New feature development was slow to move through the normal design and engineering process, and the team didn't want to commit that time and resources to a full build without more confidence it was actually something users wanted. A three-day design sprint, followed by user testing the next week, let the team validate or kill a direction fast, before investing in a build that might not land.
Overview
The sprint set out to explore an entirely new dashboard concept from scratch. The target user was an enterprise-level user working across multiple areas of the product, someone who relies on their team and didn't want to operate deep in the weeds of raw data.
Discovery and synthesis
The sprint opened with expert interviews structured around “How Might We” questions: how to display data in a more dynamic way, how to connect siloed platforms, how to understand what users actually value, how to unsilo products that had grown apart. Out of that came a north-star framing for the whole effort: tell the user what they don't know, rather than just what they ask for.
Synthesizing across the interviews, four themes kept surfacing: customizability, knowing where to focus, understanding what's changed, and simplicity. Those four collapsed into one central tension the team had to design around: how do you offer meaningful customization without letting the user get lost?
Concepts explored
A few directions came out of that tension, each resolving it differently:
01
“PG Suggests,” leaning on the company's own domain expertise to proactively surface recommended insights and actions, rather than asking users to configure everything themselves.
02
“Choose your own adventure,” a more explicitly customizable, user-directed path through the dashboard.
03
Pre-packaged insight lists (retention, scheduling trends, and similar), surfacing findings directly rather than requiring users to build their own views.
04
A settings-based model for tuning what PG-suggested content shows up.
My Role
Supported the sprint as one of the designers in the room, contributing to synthesis and concept generation.
Took the sprint's wireframes and built them into higher-fidelity frames within the three-day window, getting the prototype ready for user testing the following week.
Wasn't present for the testing sessions themselves, but after returning, took the raw session recordings and synthesized them into a condensed report for the team, including clipped moments from the interviews.
Status
This was a fast, exploratory sprint, not a shipped feature. To my knowledge, this specific concept wasn't carried forward after the testing round. Sprints like this are built to validate or invalidate a direction quickly, and this one did that job, even without a clear line to what happened next.
InMoment & Press Ganey · Product Design
Design Systems in Flux
Overview
Most of this work wasn't building a design system from a blank canvas, it was recreating design systems through repeated hurdles like two tool migrations, a leadership change, and two company acquisitions, while still making real structural decisions and fixing real problems along the way.
InMoment: Sketch to XD, then XD to Figma
I joined while InMoment was mid-transition from Sketch to Adobe XD. One of my earliest tasks was rebuilding existing components from the old Sketch library into XD. That effort stalled amid organizational shake-ups, added on by XD effectively going into maintenance mode as the company pursued its acquisition of Figma.
Around my one-year mark, a new Director of UX joined, and one of their first moves was migrating the system again, this time from XD to Figma. The same goal was to rebuild what existed before. I researched and helped decide on a token organization structure for the new system, and personally owned the button component and more, which meant documenting and rebuilding a large number of existing style variants. This was also where I built real fluency in components and auto layout, skills I didn't have walking in.
Ownership was split across the team. The Figma library was finished right around the time Press Ganey's acquisition of InMoment went through, which meant it never got the chance to be used since the InMoment products were in maintenance mode until they were integrated to Press Ganey's products.
Press Ganey: Maintaining a system
By the time I joined Press Ganey's product team, their Business Experience team had started building a newer design system of their own, but they were busy on product work with no bandwidth to maintain it. They had a list of bugs and changes they needed to make. I was brought in to work through this backlog of known bugs and gaps, converting old notes into tickets and fixing others myself where possible. In the roughly three weeks I had before my role was eliminated, my main contribution was proposing a new structure for the system's spacing tokens.
The spacing problem
The team's existing spacing scale had grown to fourteen tokens (2, 4, 8, 12, 16, 20, 24, 28, 32, 36, 40, 44, 48, 52), and they were considering adding even more. They sensed the growing list wasn't sustainable but hadn't landed on a better approach, so they asked me to look into it.
I researched how other systems handled this same problem and found that Google's Material Design system used a pattern worth borrowing. They had a full set of spacing tokens available for edge cases, but a smaller, recommended core scale determined everyday design decisions. I proposed the same approach for our system. Working with the team, we landed on a six-value core scale, 4, 8, 16, 32, 64, 128, doubling at each step rather than incrementing by four.
Previous 14-token scale vs. the proposed 6-token core scale, doubling at each step.The guideline
Because the original token scale was already tokenized and in production, we couldn't simply deprecate it. Instead, we set a guideline, default to the core scale when designing, and fall back to the full scale only when the core values were too limiting for the design at hand.
What I actually learned to do
01
How to structure a token system
02
Fluency in Figma components, variants, and auto layout, going from weak in this area to owning full component builds
03
How to propose a structural change to something already in production without breaking what people already depend on
Reflection
I came into each of these tasks somewhat weak in my skills in areas like components and auto layout. I was new, fresh out of college with basic knowledge of Figma and XD and of design systems in general. But each of these projects were great in teaching me different and new aspects each time we did it. As annoying as it was to get close to the finish line but have something happen that required us to move on and start over, it gave me an opportunity to learn something else and develop my skills more.
Portfolio · Design System
DylanOS
A Personal AI Design System
The idea
I tried to teach AI my design taste. It worked, until I remembered I actually like designing.
When I started my portfolio during the job search, I didn't want to just prompt an AI for a design and hope it landed. I wanted something that actually knew my taste, my design principles, what I liked and didn't, so I wouldn't be starting from zero every time. That idea became DylanOS.
Building the system
I worked with Claude to build it out. It asked me questions, what design standards mattered to me, what principles I considered non-negotiable, what moodboards and existing designs I was drawn to, and we turned all of that into a set of markdown files I could point future projects back to. The idea was a system that got smarter and more “me” the more context I fed it, rather than a one-off prompt I'd have to reconstruct every time.
Where it actually worked
Credit where it's due: it did a genuinely decent job. Working off what I'd given it, it put together a real website design, and it clearly improved the more detail and context I gave it.
Where it broke down for me
Here's the problem I ran into, and it's a pretty specific one: I'm a designer. I know how to use these tools. Sitting back and prompting my way toward a design through rounds of “make this bigger,” “no, more like this,” “try a different direction” felt slower and more frustrating than just doing it myself. I didn't want to burn tokens experimenting with a design I already had opinions about. What I actually wanted was to hand AI the controller for the one thing I couldn't do well myself, code, since my HTML is pretty basic, and take the controller back on everything else.
The pivot
So that's what I did. I went back into Figma and designed the system and components myself, on my own terms. I fed that into Claude Design, referencing the theme and system I'd built, and had it pushed as an artifact for Claude to turn into real code, which I then deployed on Netlify. A few ideas and themes from the original DylanOS-generated designs survived into the final version, but not much. Most of what's live now is mine, built by hand in the tool I actually know.
Where DylanOS stands now
It's not dead. I don't think the idea was wrong, I just think I had it pointed at the wrong job. Handing AI full creative control over visual design didn't fit how I actually like to work. But as a starting point, a way to gather ideas, reference inspiration, and get a rough direction fast, before I take over and do the actual designing, it's genuinely useful. That's probably the role it's better suited for going forward.
Utah Valley University · UX Design · 2022
The Balancing Act of Ads and User Experience
Recipe Site Redesign
The challenge
Ads or a good user experience? I ask why not both?
Ads and User Experience tend to have a complex relationship. Looking at different websites and apps, it seems that it's either one or the other, that it's impossible to have both. So on the surface it appears that every designer, when designing an app or website, has a choice to make.
There has to be ways that someone can have ads on their site to make money to keep it up and running, free, and still have a good experience for the people that come and use it for whatever it may be. They shouldn't have to sacrifice one of the options completely but be able to have a little of both.
The assignment
In a class at Utah Valley University we were given the challenge of just that: how could we redesign a website with better UX but still keep the space for ads and the content to improve its position in search engines?
It was an interesting challenge I hadn't previously thought of. Up until then I hadn't had to design something while keeping ads in mind. But as my professor explained, this would be something common throughout our career, and he gave an example of something he was working on right then with the same challenge.
The website we were given to redesign was a chocolate chip cookie recipe page on joyfoodsunshine.com.
How the site currently looked, and how the ads were displayed.Where ads go wrong
I understand the need for ads, and generally don't have an issue with them. That is, until they start covering the info I need and keep popping up, requiring me to try to hit that small close button that I always seem to miss, which then takes me on an adventure to another website. Most people would agree ads are fine until they start getting in the way and making the experience not worth it.
Customer journey
I asked my mom to go through the site as it currently was. She's done a lot of cooking and used online recipes often, so I wanted to see what she expected and was looking for. I asked her to open it up as if she was looking for a cookie recipe to make, and to find whether she had the ingredients it needed.
She opened the website and started reading and skimming to find the ingredients, scrolling through the pictures and the long story that was there. She somewhat expected the ingredients to be at the bottom, based on her experience with online recipes and how she'd seen it done before. After a little scrolling, and a few pop-up ads, she found them.
Her main gripe was where the ingredients and step-by-step instructions were located: always at the bottom, requiring a lot of scrolling to find them.
Content inventory & wireframes
I wanted the ingredients and steps to be at the top of the page, since that seems to be the first thing people are looking for when they land on a recipe. I also explored a floating action button, present at all times, that held those ingredients and steps, so no matter where you were on the page you could pull them up without losing your place in the instructions or story content.
Cataloging the current site’s content and structure before redesigning it.
Early paper wireframes exploring where ingredients, steps, and the floating action button would live.Wireframing the floating action button that surfaces ingredients and steps from anywhere on the page.
Handling the ads
For the ads, I wanted them to appear seamless with the content as the user scrolled. I removed any pop-ups or ads that would cover the content and require extra clicks to dismiss. They'd still be present and noticeable, just woven into the layout rather than breaking it up.
Final design
The images below show the top of the redesigned page: a brief introduction to the recipe, followed by the ingredients, steps, equipment, and details like cook and prep time and serving size.
The top of the redesigned page — ingredients and instructions surfaced immediately, no scrolling required.Ad placement in the final design
The next images show how I felt was the best way to include the ads from the site. The gray boxes represent the ad space that can be used throughout the site.
Continuing into the step-by-step instructions further down the page, with ad space woven into the layout.
What I learned
It truly is a challenge to find the balance between ads and user experience. But I learned that there are ways to still satisfy both sides. I like this quote from another article trying to solve this same issue:
“Ads aren't a problem, but how they're shown to the user can be problematic. If the right ad is offered the right way, the user will be delighted, not frustrated. So instead of asking ‘whether ads spoil the user experience?’ we should ask, ‘what's the right way of showing ads?’. You'll reach the right solution if you ask the right question.” — Automatad
Ads existing on a website or app isn't the issue, and it's not the reason there may be bad UX. The problem is how they're displayed and used. Pop-up ads and ads covering the content people are trying to read is annoying and frustrating. It may be what makes a user just give up and go find another recipe, even if they were reading the best one. There are plenty of other cookie recipes out there, so you don't want ads driving people away from yours.
So what is the right way to show ads? Like the quote said, that's the question you need to ask when you start designing.
Prototype
The full interactive prototype is up on Figma — view it here.
Note
Dylan Dusek is a student in the Digital Media program at Utah Valley University, Orem, Utah, studying Interaction Design. This project was completed for the Recipe Redesign assignment in DGM 2270 and is representative of the skills learned in that course.
Quote source: Team, Automatad. “Finding the Right Balance between Ads and User Experience.” Automatad, 18 July 2022, headerbidding.co/ads-and-user-experience.
Utah Valley University · UX Design · 2023
ElementExplorer
A Periodic Table Learning App
The idea
The app is designed to be an easy and engaging way to learn each element one by one.
For a class I took this spring 2023 semester at UVU, we were tasked with designing an app to be used in a module for a junior high class. We could design around any subject we wanted, but were required to use AI somewhere in the process — any of the many AI tools that had popped up recently.
Brainstorming
I started trying to think of what subject I wanted to design for, what I'd be able to do, and how I was going to use AI.
I decided to design an app that would help students learn the periodic table and its elements. I always had a hard time learning and memorizing the table and the many elements on it, so I wanted to try and tackle that struggle — one I know a lot of other people share too.
I then thought ChatGPT would work well with the ideas I had.
How I used ChatGPT
I used ChatGPT to give me the information to build the lessons I had planned for each element, asking things like what the atomic structure for an element was, its chemical and physical properties, and other questions to shape each lesson.
At the end of each lesson I had a “test your knowledge” quiz of four multiple-choice questions. This was my favorite use of it: being able to ask, in that same conversation where I'd just asked all my content questions, for four multiple-choice questions built from that information. It would generate the questions and answer options and tell me which one was correct, making it easy to get both the content and the quiz material I needed to design the app.
Designing the app
I originally brainstormed this as a website, not an app. I couldn't quite wrap my head around how to display a full periodic table without it looking weird or not functioning well.
I hit a mental wall trying to make progress on the website layout, so I started looking up different designs for inspiration and found a few built for apps instead. That opened up a whole new set of ideas, and I pivoted from a website to an app, which is what I'd actually wanted to do in the first place. I was glad I made the switch, since it opened up a lot more ideas for what I wanted the app to be.
The home screen — progress tracking, streaks, and the full periodic table to browse by category.Browsing a category — nonmetals, with progress tracked per element.
ElementExplorer
ElementExplorer is the name of the final product — I asked AI for a handful of name ideas based on the prompt of “a periodic table app for learning the elements.”
The app is designed to be an easy and engaging way to learn each element one by one. It includes features like tracking your streak and seeing your friends' progress.
Opening an element’s lesson, starting with the basics before going deeper.Going deeper into an element’s atomic structure.
Testing what you learned — four multiple-choice questions generated straight from the lesson content.Progress carries through the quiz, element by element.
Conclusion
I really enjoyed this challenge and project. It was neat to see what can be done with AI in a design process, and I know I'm only scratching the surface of what's possible. I look forward to seeing how the UX industry evolves as AI continues to grow and improve.
Prototype
The full interactive prototype is up on Figma — view it here.
Utah Valley University · UX Design · 2022
Beach Finder
A Beach Discovery App for California
The idea
Have you vacationed to another state and wanted to go to a beach but weren't sure which ones were nearby?
What was the parking fee? The tide height and crowd level? This was my goal for this app: to help tourists and locals alike find nearby beaches easily, along with the information you usually can't find until you already show up.
My family hated trying to find a beach without knowing much about it until we got there. We'd show up to no parking, big crowds, and low tide. The goal was to eliminate that surprise before arriving.
Audience
The audience for this app is two different groups.
The first is tourists visiting California for the first time, or the tenth. The app gives them different beaches to choose from, with the information they need to decide, plus other things to do nearby so they can plan their whole day around one area.
The second is California residents. They'd benefit from the same features, plus the ability to favorite the beaches they go to regularly and check weather, tides, and swell for each one to decide where to go that day.
Objectives
My hope was to design an app that's user-friendly while still surfacing all the information both audiences actually need.
Wireframes
From the start I wanted a favorites section and lists of beaches organized by nearby, favorites, and popular. Another feature I wanted was a map, similar to Google Maps, that let you see nearby beaches visually.
Early paper wireframes for the home, favorites, explore/map, and events screens.
High-fidelity design & prototype
For the main page, I wanted quick access to a few pinned favorites, plus a nearby list and a popular section so people new to the area could easily find where most people like to go. Tapping the arrow next to “Nearby” takes you to the map page to see more beaches around your location.
The second page shows events happening at or near that beach, the weather for the day, current tide height, and swell. I also included parking fee and occupancy so there are no surprises when you arrive. You can scroll through images at the top to see what the beach looks like — I originally had them at the bottom of the page, but feedback pointed me toward moving them to the top, and I liked it better that way too.
The third page works similarly to Google Maps: you see a map with your location, and as you move around, a list of nearby beaches updates at the bottom. At the top you can select a specific location or search.
Home, beach detail, and map screens from the final high-fidelity design.
What I learned
I learned the importance of setting goals and parameters up front. I didn't have a clear list of features I wanted, so they stayed jumbled in my head — I'd forget some or come up with new ones mid-process. I wish I'd outlined my feature objectives better from the start.
I really appreciated the feedback I got from friends and classmates. It helped get the design to where it ended up, even though it can be hard to ask for or take feedback, especially when someone disagrees or would approach something differently than you would. It led to some small tweaks that made a real difference.
Prototype
The full interactive prototype is up on Figma — view it here.
Available for work
Dylan Dusek
UX Designer
Featured Projects
Press Ganey
AI-Assisted Prototyping
An in-product AI chat assistant prototype, built with real design-system components for high-fidelity handoff.
