How I design
As a corporate designer, Figma screens are only the start of the story.
Collaboration is at the heart of my design practice, both when communicating opportunity and ensuring execution.
Always look for problems that need solving
There’s always room to improve, but figuring out what’s impacting engagement, sentiment, or sales can be tough. Sometimes problems are dropped on the doorstep of designers. Sometimes, proactive probing into user or market research, analytics, and coworkers’ experiences may be necessary to highlight what needs to get done.
Once problems are identified, a designer can build a pitch or even a proof of concept to help others understand what opportunities lie ahead.
Align early and often, but thoughtfully
Design doesn’t have all the answers on its own. However, by harnessing the power of SMEs in other fields, we are uniquely positioned to paint a picture for everyone that illuminates the way forward.
Anyone impacted by a solution should have a chance to add insight. The trick is keeping the door open for input without overwhelming stakeholders through unnecessary meetings. Having a simple communication plan and adjusting it for the working styles of different departments can keep wasted hours to a minimum.
This thoughtful alignment allows emergent issues within a project to be resolved with minimal overhead.
Use constraints to help iterate
Creative constraints force designers to consider ideas beyond their gut instincts. Practical constraints can shrink the gap between desire, design, and development. When working on complex problems, both are a vital tool to break down rigid thinking and design paralysis.
Having multiple options to consider, even on tight timelines, can often be the difference between ‘good enough’ and ‘great’ design work.
Support execution from start to finish
A designer’s work doesn’t end with the approval of their design. Partnering with managers, developers, researchers, and quality engineers during the development and distribution cycle is critical. It can help those roles eliminate uncertainty, pivot quickly when unexpected issues are found, and build trust in the designers who work with them.
Teams who trust their designers to have their backs, whether they’re helping with delivery or presenting new designs to the users, are more likely to execute fearlessly and reach out to designers on their own. A strong relationship between designers and those who execute their designs strengthens all future projects.
Past Projects
Looking for in-depth case studies? Contact me.
Problem: Adding products to a catalog required partners to go through individual certification of all the small pieces that make them up (Operators, Containers, Helm Charts, etc) rather than a single certification. This complex process caused confusion for partners, often requiring manual intervention to complete, and prevented technical solutions that might certify entire products at once.
Solution: Keep as much of the underlying data intact as possible, redesign the entire certification interface to only allow products as the primary point of entry to certification. Terminology was also updated (from projects and products to components and products) to reduce confusion for both associates and partners about the certification process.
Who was involved: Partner Certification teams, CertOps, Catalog team, several data teams
Unexpected Learning: My research concluded users preferred finding their own way through the Certification process over help links due to prior experiences with genericized help. If we wanted to speed them up in the new process, we needed to surface guidance in-context.
Response: I expanded upon our design system and drafted rules to support a readiness score with detailed and actionable links to where improvements could be made by the user. This has since become the standard for catalog management. Requests to expand upon its scope to other, challenging bottlenecks in the process have been made, and my expansive designs have laid the groundwork for future additions to the certification program, including a new process for some software types called ‘validation’.
Multi-team Workflow Redesign
Technical Feedback and Logging
Problem: When a containerized product is tested, typically through a pipeline process, tests need to be reviewed by partners and the support agents who help them. Traditional logging was proving too dense to help most partners self-service even simple issues.
Solution: Simplify test details and artifact display by focusing on understandable, highly visual indicators.
Who was involved: Partner Certification teams, CertOps
Unexpected Challenge: This simplification of concerns made most troubleshooting easier but increased confusion when there were issues with the data (stale, incorrect format, missing access, etc.) due to perceived high maturity of the underlying system.
Response: After speaking with CertOps, I believe a tighter link between real-time pipeline management in the partners’ tools and this slower logging display would be an ideal solution. Unfortunately, technical constraints currently make this impossible. In the meantime, manual handling of these cases has been accepted.
Problem: When partners enter the certification flow, they were presented with documentation links but no actions to take.
Solution: Create an action-focused landing page that can expose timely and relevant information for partners to complete the certification process. This meant focusing on things like failing tests first and management of existing products second.
Who was involved: Partner Certification teams, Marketing
Unexpected Challenge: Some cards were deemed not useful from marketing feedback and partner behavioral research, or infeasible due to limitations of our data warehouse. There also were page load issues from too many complex API calls, which made the page difficult to use.
Response: The number and scope of cards was severely trimmed to what I thought would be most feasible and would have the most impact. Partnering with the development team allowed me to find a middle ground on some of these issues, adjusting the data displayed slightly to reduce the number of slow API calls or petitioning for changes to the APIs of our most high-impact items, such as failed test display.
Actionable Dashboard
Problem: Onboarding for certain types of partnership was highly manual, which put a strain on support, could result in improper or partial authorization setup for Partners, and prevented good demographic data from being collected about those Partners.
Solution: Build an onboarding option which automates those manual flows and seamlessly integrates with existing onboarding.
Who was involved: Identity management team, Marketing, affected product teams
Unexpected Finding: Although the manual processes were well-documented, those documents were out of date. Speaking to stakeholders and account managers revealed that there were many exceptions and proposed changes to the official flows that hadn't been captured in the documentation.
Response: Working directly with those stakeholders and product managers, I was able to cut out unnecessary parts of their documented workflow and speed up internal conversations about contentious areas that had been debated for some time. Parts of the full preferred setup process needed to stay manual in light of those discussions, but with the final new onboarding flow, partners could get access to basic systems without ever needing an associate.
Onboarding/Identity Management
Non-UI Projects
Problem: Data for users was highly fragmented across the backend, causing confusion about data management and performance issues in products that need to pull from multiple sources.
Solution: Develop a new, singular schema that can be maintained in a centralized location.
Who was involved: Admin SPA team, partner marketing teams, several data teams
Unexpected Challenge: Consolidating was a huge effort to the point of being unrealistic, especially when data management was handled across many different applications. It was necessary to lean on data syncing and keep at least some of the existing structure to avoid upending existing workflows.
Response: I analyzed the various competing schemas that would likely remain and provided two main data management interfaces, one for partners and one for associates managing partners, that could act as a centralized point to obfuscate remaining data woes to the user. These interfaces relied heavily on contextual links to other systems and flagging of specific data uses when fields were named unclearly. I also surfaced findings around potentially duplicated fields to the data teams, allowing them to further refine their schemas.
Data and Information Architecture
Problem: While trying to develop for new technology requiring rapid adoption (AI), engineers and designers had low clarity about what 'good' looks like. Best practices and standards were siloed within specific teams and sometimes contradicted each other, making creators feel lost.
Solution: Create centralized guidelines for anyone building AI solutions.
Who was involved: AI engineering teams
Unexpected Finding: The way people wished to consume this information varied massively depending on their role. Some wanted a browsable website, some wanted this integrated into different existing documentation areas, some wanted tests to run with minimal human oversight, some wanted recommendations exemplified in their tools (e.g. Figma), and some wanted to see these guidelines primarily delivered through a Skill or LLM agent of their choice.
Response: After aligning on engineers as a priority, I supported creating an automated option for testing as many of these guidelines as possible through existing development platforms. On the design side, I temporarily stood up a site to centralize existing recommendations, aiming to migrate that to more commonly used documentation areas without duplicating content. I'm also actively working with AI teams to find a reusable MCP/Skill solution that will allow access to that data.
AI Development Enablement
