Hi, I am Cassiano Psomas

A product designer crafting user‑centered experiences that maximize product value.

Selected work ↓
Siteimprove
Siteimprove

Grouping users and sites for people management

Sora School
Sora School

Streamlining onboarding for an education portal

Digibee
Digibee

Bringing AI into a low-code integration map

Wildlife
Wildlife

An infrastructure platform for game developers

← Back to work

Streamlining an
onboarding process for an education portal

ClientSora School
RoleSenior Product Designer
Two students doing schoolwork at a table at home

About the project

Overview

The onboarding process marks the beginning of the Sora experience, where families and students submit the necessary documentation to ensure their first day at school is successfully prepared by the end of the process.

Over the past two years, as the school experienced growth, several issues began to negatively impact the onboarding process and the overall operations of the school.

The challenge

Improve the school onboarding process to create a seamless and straightforward experience from both the user and service perspectives.

The business goal was to streamline the onboarding process, ensuring that at least 50% of users completed it within one week during the first month of the MVP launch.

My role involved deeply analyzing the experience to understand the workflow, users' needs, and service requirements, to streamline the process as effectively as possible.

Objective
50%

of users complete onboarding within one week (first month of MVP).

Discovery

Exploring user needs

During this initial phase of the project, I discovered that recent user research had already been conducted. My task was to evaluate the findings and share them with the team. The key insights from the research were:

  • An overly overwhelming process across emails, PDFs, and external links was confusing families.
  • Parents and students are given the same links to complete checklists, causing confusion between families.
  • Users frequently needed to fill out the same information across multiple documents.
  • Lack of a schedule for the completion of the checklist.
Diagram of the old onboarding process spread across PDFs
Diagram of the old onboarding process spread across PDFs

Uncovering service flow

The next step was to understand how the service team managed the onboarding process from a behind-the-scenes perspective. So I initiated a service blueprint in collaboration with the administration team to map the entire flow, uncover needs, identify gaps, and highlight key opportunities for improvement.

  • Organizing groups of students at that time was messy, cumbersome, and very stressful; they needed a better way to organize this hierarchically.
  • There was no way to track families' progress at that time; they needed a tool to do this.
  • Instead of trying to improve the current manual process, we decided to centralize the entire onboarding experience inside the Portal.
  • By analysing the current checklist, we reduced 33 checklist items to 13 by removing redundant and duplicate content.
Service blueprint of the onboarding process
Service blueprint of the onboarding process

Ideation & Definition

Discussing opportunities and defining priorities

Once the blueprint was complete, we collaborated to explore the opportunities identified and propose feasible features from both technological and business perspectives. The key highlights identified were:

  • Possibility to track families' progress and organize onboarding groups through the portal.
  • Create a streamlined checklist and task structure, and provide earlier access to users on the platform.
  • Remove external links to avoid confusing navigation.
  • Review all content and rewrite the checklists and tasks to remove repeated information and simplify copy.
Certainties, suppositions and doubts (CSD) matrix
Certainties, suppositions and doubts (CSD) matrix

Solution prioritization

With the key problems well defined, we began brainstorming possible features. We ensured that the prioritized features were technically feasible within the time and resource constraints, and that they would meet the needs of both users and the administration team.

The features prioritized were:

  • A checklist structure with onboarding groups, assignments, checklists, and tasks.
  • A report where admins can see families' assignment status and organize families by onboarding groups.
  • Separate parents' / students' checklists and tasks, to avoid confusion in delivering tasks.
  • A trigger for the internal team to move families to the next stage of onboarding.
Effort vs. impact prioritization matrix
Effort vs. impact prioritization matrix

Understanding the onboarding division hierarchy

To effectively design the user flow, we first needed to understand the hierarchical structure of the school's onboarding process. This step provided clarity on the flow's complexity and was a crucial phase for the development team to begin estimating potential deadlines.

Diagram of the onboarding division hierarchy
Diagram of the onboarding division hierarchy

Families onboarding tasks flow

The flow for families and students was designed to provide:

  • Seamless and intuitive navigation through checklists and tasks.
  • An easy way to identify next steps and complete the process.
User flow for families completing onboarding tasks
User flow for families completing onboarding tasks

Service flow

The service flow was designed to meet:

  • Families' assignments throughout specific grades, campuses, start dates, groups, and other departments as needed.
  • A place to create checklists and tasks for specific onboarding departments.
  • Tracking of families' progress throughout the onboarding process.
Admin service flow diagram
Admin service flow diagram

Sketch to success

With the strategic plan set up, we started the wireframes to validate the main product structures with the devs and the design team. Our primary goal was to validate whether the chronological order of tasks and checklists was clear from the students' perspective, and to ensure that the hierarchy of the administrative flow functioned smoothly.

Wireframes for the onboarding interfaces
Wireframes for the onboarding interfaces

Prototype

Families onboarding interface

We began working on the families onboarding interface. Our main objective was to offer a more streamlined and organized way of dealing with checklists and tasks, which would improve the overall progress of the onboarding process and keep everyone up to date on the status of each task.

The key parents' and students' solutions were:

  • Separated tasks for parents and students.
  • All the tasks located in the same place.
  • No more duplicate information.
  • Earlier access for students and parents.
Families checklist interface
Families checklist interface

Admin's onboarding management interface

Building the administrative interface was a challenging task due to the complexity of the internal team's workflow in managing the checklists and tasks of the onboarding process. We had to work closely with stakeholders to make crucial business decisions while overcoming several technological limitations.

Despite these challenges, we created a core set of features that would streamline the onboarding process and make it more efficient for both the internal team and families.

The key administrative solutions were:

  • Ability to assign users to specific groups.
  • Ability to monitor parents' and students' progress.
  • A way to separate tasks between parents and students.
  • Ability to monitor group status.
Administrative home interface
Administrative home interface

Families report

The families report serves as a hub where the internal team can add or edit families' information to join a campus and onboarding group. In addition, the admin team can use this report to monitor the onboarding status of each family.

Families report interface
Families report interface

Creating checklists for families

Once families have been added to an onboarding group, checklists and tasks can be created, and families will soon be able to start the school's onboarding.

Create a checklist interface
Create a checklist interface

Usability test

With the interfaces completed, a usability test was conducted with the administrative team to validate the service flow. Overall, we addressed minor improvements, and users considered the interface a usable and seamless experience.

★︎★︎★︎★︎★︎ Ability to add families to a campus. ★︎★︎★︎★︎★︎ Ability to add checklists and tasks. ★︎★︎★︎★︎★︎ Ability to edit checklists and tasks.
Usability test results
Usability test results

Conclusion

Business goal and KPI validation

One month after the feature launch, the team had the opportunity to validate the business goal and the KPI established for the project.

Result vs. objective
80%

of students and parents completed onboarding within one week.

Objective was 50% within one week during the first month of the MVP.

← Back to work

Refining visuals and
bringing AI into a
low‑code integration map

ClientDigibee
RoleSpecialist Product Designer
Digibee integration IDE, hero

About the project

Overview

The integration map was Digibee’s most strategic product, the core tool where project managers and developers connect systems. Competition in this space was intense, and to stand out we had to sharpen the visual interface, improve component usability, and introduce two new features: an AI assistant and a visual integration mapping tool.

The challenge

The existing integration-creation flow needed serious usability work. It hadn’t been touched in a long time, and it had to keep pace with the leading global players in the category.

My role was to enhance the key features that would keep the product competitive, and to lead the design of the new AI and visual-mapping capabilities from research through handoff.

Objective
50%

user adoption of the Visual Mapper and Smart Connector within the first two months of launch.

Discovery

Exploring hypotheses

To surface hypotheses and spot opportunities, we started with a detailed mapping that wove together the critical paths in the customer journey, the Jobs To Be Done, possible solutions for each job, and a way to validate every one of them. It gave the team a shared picture of where the product could go and a clear set of goals to aim at.

Jobs To Be Done mapping across the customer journey
Jobs To Be Done mapping across the customer journey

Defining facts and open questions

With the critical paths in view, the team defined facts, formulated assumptions, and named the questions still open. This mattered most for engineering, since it grounded the conversations about technical requirements and capacity that keep delivery on track. The key signals were:

  • Low-code users wanted a more visual document of the JSON mapping.
  • They were already mapping JSON integrations in a spreadsheet before the coding phase.
  • They struggled to find the right connector among the 60 available options.
Certainties, suppositions and doubts (CSD) matrix
Certainties, suppositions and doubts (CSD) matrix

Talking to users

With those first explorations done, we had enough to sit down with end users and hear their perspective on the project’s core topics. We ran the interviews through Marvin to organize, transcribe, tag, and document everything, a tool that made the research process much faster.

User interview documentation in Marvin
User interview documentation in Marvin

Research analysis

Marvin’s tagging let us group findings into themes; we then moved everything into Miro so the whole team could collaborate and start prioritizing. The recurring pain points were clear:

  • Mapping was hard to explain to low-code users.
  • Choosing an integration was difficult for lack of information.
  • A need to define visual mapping on CSV.
  • JOLT made the work slow and difficult.
  • Connectors were poorly organized, hard to find, hard to see documentation.
  • The integration canvas was hard to use, and the rounded-circle nodes were hard to interact with.
Key insights from the research synthesis
Key insights from the research synthesis

Ideation & Definition

Impact vs. effort

It was time to prioritize. Weighing value against feasibility together kept the decisions strategic rather than reactive. The candidates on the table were:

  • Test transformations individually, without running the entire pipeline.
  • Show input and output data for connectors, and auto-generate a visual solution when creating the mapping, the seed of Visual Mapping.
  • Improve connector organization with better search.
  • Redesign the canvas into a more intuitive, functional version.
  • Show the input and output format of each connector in a side sheet.
Prioritized items on the impact vs. effort matrix
Prioritized items on the impact vs. effort matrix

Visual Mapping flow

Before jumping into the prototype, we worked out the Visual Mapping feature flow together, including a low-fidelity prototype to explore the UI possibilities.

Visual Mapping feature flow, low-fidelity
Visual Mapping feature flow, low-fidelity

Prototype

The old canvas

The first step was to fix the integration IDE itself. Across the interviews, a set of problems with the Canvas, the place where integrations are mapped, came up again and again:

  • Drag-and-drop arrows to connect an integration were unreliable and buggy.
  • Disorganized layouts cost users several minutes just to orient themselves on first access.
  • Actions inside the execution panel were hard to locate and understand.
The old integration canvas
The old integration canvas

The new canvas

After folding in the feedback and validating each change through usability testing, the reworked canvas landed on a few core improvements:

  • New connector shapes gave a consistent visual pattern, improving clarity and the drag-and-drop experience.
  • Actions and links were organized by context so the information stayed legible.
  • The execution panel was relocated for better visual support.
The redesigned integration canvas
The redesigned integration canvas

Smart Connector, AI suggestions

The Smart Connector brings AI-driven connector suggestions right into the integration flow, giving new users a friendlier, more supportive first experience. Its highlights:

  • Makes finding the right component for an integration much easier.
  • Offers fast search across any component.
  • Links straight to the component’s documentation for full usage detail.
Smart Connector AI suggestions in a flow
Smart Connector AI suggestions in a flow

New connectors sidebar

The sidebar was redesigned to match the new canvas, cleaner and more cohesive, with usability additions on top:

  • Full documentation for each connector, accessible directly from the sidebar.
  • A favorites section to save frequently used connectors for quick reuse across projects.
The redesigned connectors sidebar
The redesigned connectors sidebar

Visual Mapping

To help low-code users who struggled with code-based maps, we built Visual Mapping, a clear, intuitive way to read the mappings inside each integration. Its highlights:

  • Users can add new or existing input and output JSON directly on the platform.
  • Once the data is in, they can build the mapping through the Input/Output Specs or the Visual Mapper, and the two stay fully synchronized.
  • Low-code users can finally read and understand the structure of a specific JSON integration.
The Visual Mapping interface
The Visual Mapping interface

Usability test

A navigable prototype let us demo to the whole product team and put end-user navigation to the test. The sessions validated the key functionality, the micro-interactions inside the Visual Mapper, and how users perceived the visual changes.

★︎★︎★︎★︎★︎ Finding how to include data in the system. ★︎★︎★︎★︎★︎ Interacting and navigating between items on Visual Mapping. ★︎★︎★︎★︎★︎ Creating a simple mapping.
Usability test results for Visual Mapping
Usability test results for Visual Mapping

Conclusion

Business goal and KPI validation

Both KPIs came in just under target, but management considered the results acceptable, and we kept monitoring and improving the product after launch.

Result vs. objective
34%

of active users used the AI Smart Connector in their mappings.

Objective was 50% of active users using the AI functionality in their mappings.

Result vs. objective
49%

of active users used the Mapper Visualization at least once.

Objective was 50% of active users using the Mapper Visualization at least once.

← Back to work

Creating an
infrastructure platform
for game developers

ClientWildlife Studios
RoleSpecialist Product Designer
WAZP game infrastructure platform, hero

About the project

Overview

My journey with WAZP started with a project already moving at full speed, an MVP was built and several features were in progress. It carried a two-year roadmap approved by management, all aimed at one thing: a platform to optimize how game developers create their game infrastructure.

The challenge

Wildlife’s strategy with WAZP was to bring small, talented game studios from around the world into the product, giving them an environment to optimize their game infrastructure with WAZP technology. The business goal was to have at least one game project created inside WAZP within three months of launch.

My goal was to build an understanding of the whole platform through strategic design, and to design every interface with user experience first.

Objective
1

game project created inside WAZP within three months of launch.

Discovery & Ideation

Desk research, finding the product vision

When I joined, several parallel products and competing opinions were clouding the roadmap. To cut through it, I ran desk research, pulling information from many scattered documents into a single document that laid out the product strategy and the possible solutions.

Once it was organized, I shared it with the product directors to validate the direction. That cleared up the doubts and let us move ahead with more focus and product maturity.

Consolidated product strategy analysis
Consolidated product strategy analysis

Journey map, understanding user needs

With the roadmap agreed on, I set out to validate the user journeys and make sure the MVP stood on a solid information architecture. I ran a dynamic session with five users to capture their full journey, their features, problems, insights, and how they felt about the current flow.

User journey map from the group session
User journey map from the group session

What the journey map told us

The journey map sharpened our understanding of user needs and let us make informed calls on what to prioritize:

  • Dropped the Game Phase Transition feature from the roadmap, since each user journey can differ from the next.
  • Improved key decisions around hierarchy features, the sidebar menu, and navigation between projects and companies.
  • Prioritized the features that mattered most: Metagame Service, Configuration, and Experimentation.
Journey map analysis and prioritization
Journey map analysis and prioritization

Information architecture

With a deeper read on the product and its users, I moved on to the information architecture, reshaping it to improve how the platform worked and how it felt to use.

Reworked user flow and information architecture
Reworked user flow and information architecture

Prototype

The old navigation

With a clear read on user needs and flows, we could finally start building the improvements, beginning with navigation, which had real structural problems:

  • Links were split across tabs, so reaching the next hierarchy of subpages was awkward.
  • Projects sat in the header at the same level as a company, when they belonged one level down.
  • Submenus had to open through a dropdown, which only got harder to navigate as the product grew.
The old WAZP navigation
The old WAZP navigation

The new navigation

The redesign reorganized navigation around how game developers actually work:

  • New main navigation links separated the functions that make sense for game developers.
  • Projects now sit hierarchically under companies, which matches how people navigate.
  • Submenus open beside the menu, without disrupting the main navigation.
The redesigned WAZP navigation
The redesigned WAZP navigation

Metagame Server

Users flagged the Metagame Server as a priority: it lets the backend deliver rewards and feedback inside a game environment.

Metagame Server interface
Metagame Server interface

Experimentation Platform

The Experimentation Platform answered users’ need for A/B testing, letting them collect meaningful data on how players use and interact with a game.

Experimentation Platform for A/B testing
Experimentation Platform for A/B testing

Usability tests

Every time we finished building a feature, we recruited at least five users to run a usability test and validate the prototype.

Usability testing sessions with WAZP users
Usability testing sessions with WAZP users

Conclusion

User satisfaction survey

After all the changes shipped, we measured satisfaction with a survey, and the result was a happy one.

Result
88%

of users rated the experience 9 or 10 out of 10 (76.5% gave a 10; 11.8% a 9; 11.8% an 8).

Business goal and KPI validation

We met the business goal, and validating the KPIs gave us a positive read overall:

Result vs. objective
4

studios created a project by April 30.

Objective was at least five games created by April 30.

Result vs. objective
3

games were created using built-in analytics.

Objective was at least two games using built-in analytics.

Result vs. objective
3h

average time to create a game’s infrastructure.

Objective was all game infrastructure created in under one hour.

← Back to work

Streamlining how admins
connect many users to
many sites at scale

ClientSiteimprove
RoleSenior Product Designer
Siteimprove User Groups, hero

About the project

Overview

Siteimprove is a digital-presence platform that helps large organizations keep the accessibility, quality, SEO, and analytics of their websites in check. Inside it, platform administrators decide who can access which sites, and for enterprise customers that can mean thousands of users spread across thousands of sites.

But access was still handled one user and one site at a time. There was no way to manage a set of users together, no bulk or template mechanism, and no clear moment to connect a new site to the right people. User Groups set out to change that: an account-level way to group users and grant them access to many sites at once.

The challenge

Managing access at scale was manual, fragile, and easy to get wrong. Admins repeated the same site-by-site, user-by-user setup, with no simple way to see who could reach which sites, compare access across many users, or swap one person for another without redoing all their permissions. Access drifted out of sync every time a site was created or someone changed roles, piling up support load and risk.

My role was to lead the design end to end, from framing the problem through research to prototyping, usability testing, and developer handoff, turning a tangle of per-item assignments into a clear, few-step flow.

Objective
25%

of medium and large accounts (50+ sites or 50+ users) adopt User Groups, with 7 in 10 admins agreeing groups make site assignment simpler.

Discovery

User interviews

To understand how access is really managed day to day, I ran a mix of 1:1 and group interviews with administrators at large US universities, including the University of Michigan, the University of Connecticut, and the University of California. These are exactly the accounts the feature targets: thousands of users, thousands of sites, and constant pressure to keep access correct.

Interview 1
Interview 2
Interview 3

Problem definition

The conversations converged on six core problems:

  • Site access can’t be managed as a group. There is no user group whose membership drives site access. It is maintained user by user and site by site, instead of being set once at the group level.
  • Adding or removing a site doesn’t update who can see it. When a site is added or removed, access doesn’t propagate to the people who should have it. Every affected user has to be edited individually.
  • Personnel changes don’t flow through to access. Joiners, movers, and leavers aren’t reflected in access automatically. Whenever a team changes, access has to be reconciled by hand.
  • Stale and orphaned access accumulates. Users who never logged in, or haven’t in years, keep their access, and there is no straightforward way to find and clean it up.
  • Bulk assignment is repetitive and hard to discover. A bulk path exists, but admins don’t know it’s there, and even when it is used it still takes many manual steps.
  • Per-user assignment doesn’t scale. At hundreds or thousands of sites, provisioning access by hand is slow, heavy, error-prone work.

Ideation & Definition

Feature logic

Before diving into flows, I mapped the feature’s core logic, the big-picture rules of how groups, users, and sites relate, so the product manager and I shared one mental model. It wasn’t a complex artifact, but validating it early meant everything after it rested on agreed foundations. It was confirmed without major changes.

Feature logic mapping
Feature logic mapping

User flow mapping

From there I drew the user flows at a high level, focusing on the main paths rather than every attribute, edge case, or small detail. The goal was to validate the shape of the experience, how an admin moves from creating a group to adding users and sites, before committing to the detail.

High-level user flow mapping
High-level user flow mapping

Design structures

User Groups also became a chance to set a broader standard. Much of the Settings area it lived in had aged, and its patterns had drifted, which made it hard to say what the right structure even was. So we used User Groups to define the new pattern, with the other Settings tools expected to adapt to it over time. I worked alongside another designer building patterns across those features: together we mapped the current structure of each one, then created more standardized options to shape the new direction.

Settings structure mapping and standardized options
Settings structure mapping and standardized options

Prototype

Building the experience

I built the full experience as an interactive prototype using Claude, quick enough to put a realistic flow in front of users and iterate on it directly. That let the design be validated through user testing rather than described on paper.

User Groups list

The journey starts with the User Groups list, where an admin gets their bearings: what the feature does, and which groups already exist. The priority here was clarity, making the information easy to read, surfacing the key actions up front, and keeping everything accessible. Every interface was also validated with our accessibility team, so the design meets accessibility needs by default.

User Groups list view
User Groups list view

User group creation

Creating a group opens a modal with a simple stepper for adding users and sites, deliberately lightweight so the first setup never feels heavy.

Group creation modal with stepper
Group creation modal with stepper

User group details

The details view is where a group is maintained, and it is the densest part of the experience, so it is broken into a few focused actions.

Removing users

Removing members is a distinct modal of its own, keeping a clear line between granting and taking away access.

Remove users modal
Remove users modal

Adding users

Adding members happens in its own modal, kept separate from removal so the two actions never get confused.

Add users modal
Add users modal

Bulk selection

Bulk selection makes managing many items at once practical, a necessity at the scale these admins work in.

Bulk selection
Bulk selection

Access to all sites

"Access to all sites" goes a step beyond selecting every site: it also covers any new site added later. Selecting all sites by hand only captures what exists at that moment, so sites created afterwards would be left out. This option keeps the group current automatically.

Access to all sites
Access to all sites

Design handoff to devs

Alongside the prototype, I created a handoff inside the project so engineering had everything they needed in one place.

Components

Each component came with its Fancy (our design system) code and inspect specs, so engineering could match the build to the design down to the property.

Component code from Fancy
Component code from Fancy
Component inspect specs
Component inspect specs

Spacing

Spacing was documented across the interface, giving a clear reference for layout and rhythm.

Interface spacing specs
Interface spacing specs

Flow steps

The user flows were laid out step by step, with automation showing how users move through the existing flows. That helped the backend team anticipate the commands and API work each step would need. Beyond that, the whole experience was designed to be easy to use and to navigate.

User flow steps
User flow steps
Flow automation
Flow automation

Validation

Usability testing

We ran a round of moderated usability sessions to put the prototype in front of the admins who would actually use it. The feedback was strong and consistent, and it confirmed the flow solved the problems discovery had surfaced. Every participant rated the experience between 4 and 5 out of 5.

★︎★︎★︎★︎★︎ University of Michigan. ★︎★︎★︎★︎★︎ University of California. ★︎★︎★︎★︎★︎ University of Connecticut. ★︎★︎★︎★︎★︎ University of Michigan.
Usability session 1
Usability session 2
Usability session 3

AI-assisted research operations

I also built an AI automation to take the heavy lifting out of the user-testing documentation. It:

  • Pulled the relevant participant details, user ID, company, email, and ARR, straight from Pendo.
  • Generated the full Confluence usability-test plan from a single example of how I write them, then reproduced that format for every new test.
  • Drafted the context, objectives, and problem statement for each test from the relevant PRDs and briefs.
  • Summarized participant feedback in Dovetail and back into the Confluence doc.
  • Wrote the recruitment emails for participants.

My part was to review everything and write the actual test tasks. The automation handled the rest.

Conclusion

Business goal and KPI validation

Restating the objective set at the start, and how it landed after launch:

Result vs. objective
29%

of medium and large accounts created a User Group with at least one user and one site in the first quarter.

Objective was 25% adoption among medium and large accounts.

Result vs. objective
8/10

admins agreed User Groups made site assignment simpler.

Objective was 7 in 10 admins agreeing.

I turn complex product problems
into clear, useful, scalable design.

0
Years in the design field
0
Platforms & problems solved
0
Years across UX & UI
0
Years with SaaS products

About

I'm Cassiano, a product designer based in Florianópolis, Brazil, with sixteen years in the design field. I started my career in advertising agencies and design studios, including a four-year run with my own studio, where I learned to think strategically and became a product designer.

Moving into tech, I gained a lot of expertise across B2B and B2C SaaS platforms in many market fields, coordinating design systems, leading products shoulder-to-shoulder with product teams and C-levels, and mentoring designers along the way. Lately I've been folding AI into how I work.

Today I'm a Senior Product Designer at Siteimprove, a marketing platform, working on AI design-system components and a new content-product integration.

How I work

For me, product value comes from aligning business, technology, and usability; none of them wins alone. I stay close to the whole team, from discovery through developer handoff, because the sharpest decisions come out of that collaboration.

My process flexes to each company, but it always starts with the business context and the user's real pain, not the interface.

Experience

SiteimproveSenior Product Designer2025 – Present
FirstbasePrincipal Product Designer2024 – 2025
DigibeeSpecialist Product Designer2023 – 2024
Sora SchoolSenior Product Designer2023
Wildlife StudiosSpecialist Product Designer2021 – 2022
SofplanSenior Product Designer / Manager2019 – 2021
CreativeDriveSenior Product Designer2019
ArcTouchSenior Product Designer2017 – 2019
Psomas Branding & DigitalDesigner / Owner2013 – 2017
Advertising agenciesGraphic & UI Designer2010 – 2013

Expertise

Designing AI-powered featuresAI UX patternsPrompt designEvaluating & curating AI outputAI-assisted workflows 1:1 interviewsGroup interviewsSurveysCompetitor analysisUsability testingJourney mappingSynthesis & insight generationInformation architecture Service blueprintingCurrent-state & service flowsSystems mappingDesigning complex / technical products Business & design goal alignmentStakeholder & C-level relationshipsProblem framing / product thinkingDefining & validating success metricsPrioritizing under constraintsStorytelling & communicating decisions MentorshipHiring & interviewing designersDesign team onboardingTeam performance & KPIsCareer developmentFacilitation (workshops)Design critiqueCross-functional collaboration (eng / PM) TypographySpacing & layoutVisual hierarchyInteraction designPrototypingResponsive & mobile designAccessibility Component creationToken architectureGuidelines & documentationContribution / governance modelDesign-to-dev handoff