"I just plunged my first toilet"
is not something you want to hear your 8 year old say.
Hello all!
My name is W.G. and I am a designer who has had the awesome privilege of working with some great companies like Capital One, FireEye and NowSecure.
I’m a seasoned UX design professional with over a decade of experience in the field. Always keeping my skills sharp, I stay at the forefront of design tools and trends. A passionate early adopter of Figma, I’m driven by all elements of design: from crafting impactful design systems to refining seamless product workflows.
I can't thank you enough for stopping by and checking things out.
Please contact me if you have any questions.
Thanks again. WG
All rights reserved. 2025
Spring from Capital One is a site dedicated to bringing discounts on goods and services to small businesses.
Spring is a free service but requires visitors to sign up and log in before a discount code or link is revealed. Existing Capital One customers by default have access to Spring as they can log in using their Capital One online credentials.
Given a site or application which compiles discounts isn't unique in itself, Spring is different in that a deals team at Capital One negotiates discounts which are often better than those found elsewhere.
Spring's bounce rate for the homepage was an astronomical 97%. A bounce rate this high isn't even considered acceptable for blogs or news where users often go for one specific reason and leave.
Give the current statistics we had our work cut out for us and we established the following objects.
Spring soft launched in 2017 but it's formal national launch won't be in late 2020. What copy tells the user what the purpose of Spring is? Where are examples that would help reinforce the purpose? These are a few pain points that needed to be addressed.
The basic UX process could be thought of as research, ideation, design and testing however there are a multitude of facets to each, facets within facets and not every UX challenge is the same. A UX problem could require you to go through either a more expanded process or just the opposite, a trimmed down more focused process.
For Spring's homepage bounce rate problem the process started with a UX audit of the entire site. While this is certainly looking at more than the single page in question, I was new to Spring and I needed to understand the site as a whole to deliver relevant insights that could potentially be carried through out the application.
The UX audit provided a critique of the homepage, noting mistakes in UX best practices and lack of content to tell the user just what Spring has to offer but just as importantly it also provided key information by defining personas and customer journeys as well as evaluating competitors.
I conducted a complete audit of the Spring product when I first came on board, this helped to better understand the impact a change on one page might have through out the rest of the site.
Our UX researcher and I ran a series of qualitative tests on the homepage to help gauge the users understanding of Spring. It's my belief that a visitor needs to be able to understand what the product has to offer in a concise and compelling way in order to get them to take they next step and drive adoption.
We found visitors were having a difficult time understanding the purpose of Spring. Above the fold there was only catchy and somewhat cryptic marketing blurbs which kept our marketing department happy but wasn't helping users. We followed our initial tests up with a series of bare bones comprehension tests which confirmed the copy of the page wasn't conveying the purpose of the product.
Further more, the main call to action was cryptic as the button label didn't tell the user where they would be taken to. Combining these elements it was easy to empathize with the user's being confused.
I love the immediacy of sketching, not relying on anything digital, this is truly freeing and can allow ideas to flow fast. Sketching can often involve quite a bit of iterations, again because your not held back by a digital platform. The eraser or a new sheet of paper can be a powerful friend in these situations.
These are only a few sketches for demonstration purposes however it is not unusual to do 2, 3, 4, 5x as many.
We distilled several options down to the 2D, architectural type, representations of the design. I found the main benefit here is allowing the stakeholders to focus on the content and flow. There are no color distractions to get people off topic. After reviewing these it was easy to determine the next step we wanted to take and validate.
Wireframes serve a vital purpose, the focus from stakeholder and feedback you receive is often extremely helpful.
The mockups I created were done in Figma which allowed me to use the official Capital One design library known as 'Gravity' for basic elements and responsive grids. It was also necessary for us to establish our own separate design library for our product which has UI elements specific to our product. We wanted the product to align with it's siblings yet be distinctive in certain visual treatments and micro interactions.
Using what we learned in the research phase we updated existing and added additional copy to tell the user clearly and directly what Spring has to offer. The call to action, inline with the new copy, had a clear label letting the user know what the next step is.
Aligning to the corporate design system allowed us to leverage the trust that has already been built there by the corporate brand.
High fidelity mockups are reviewed and critiqued by the product experience group yielding additional insights and ideas.
Test, test, then test some more. While we were able to make significant improvements to the bounce rate iterating and A/B testing continues. As a designer once I start working on a problem it is hard to let go and for this project I will continue discovering and testing. It's my belief that data driven design is highly effective and addictive which is the stage we are now in.
This interaction shows the user going from the homepage to the merchant offer.
HX or Endpoint as it is more commonly know from FireEye is a product that monitors computers or hosts as they are known for signs of cyber attacks. Each host has an agent installed that monitors different types of events and saves them for review.
The Endpoint workflow allows security operation centers(SOC) to confirm threats, isolate affected hosts and to examine a host to determine the exact nature of a threat which could be either an automated attack or a human threat actor.
When the agent alerts to a possible compromise a triage package is created logging events that occurred before, during and after the compromise.
When an alert occurs time is of the essence. Analysts need to know what happened and when. Who was involved, was it a sponsored threat group, was the attack a success and how wide spread. The Endpoint application at the time involved a lot of clicks to find essential pieces of information. The user would often have to leave the investigation to go to other parts of the application to preform queries or leave the application altogether to find essential information in another application. In short, it was taking analysts to long to conduct an investigation and the process was cumbersome.
We needed to keep the analyst in the context of the investigation as much as possible. In doing so several pain points needed to be addressed.
Viewing an alert Triage Summary was game changing when first introduced but as the sophistication of attackers grew the tools to fight them needed to evolve.
A typical simplified UX process could be thought of as research, ideation, design and testing.
To put a visual to the process we can see that there can be multiple revisions in the ideation, design and test part of the process.
The Triage Summary is intented for a select group of analysts who have very specialized knowledge in cyber security. When conducting research for the Triage Summary we needed to interview these analysts to determine pain points and their needs.
As luck would have it the work on the Triage Summary coincided with FireEye's annual Cyber Defense Summit gathering and it allowed us to have access to a great number of analysts.
In viewing a Triage Summary analysts have by in large similar goals...
The primary pain point which was most often repeated is that it takes to long to determine is an attack was successful. And the primary culprit is the fact the analyst needs to leave the product to get additional insights around a piece of intel most commonly ip addresses or domain names. Other contributing factors include the lack of context around the host they are viewing the triage summary. Where is is, what is the OS, etc. Then the processes in the triage summary have parent child relations bust aren't displayed as such. Finally looking at the swimlanes of events is it possible to simplify this information.
Analysts can gather a great deal of insight from the Triage Summary timeline of events so exploring the way it was visualized and it's capabilities or lack there of was a starting point.
One of the pain points we gathered from the anaylyst was that the existing swim lanes of events was limiting and they wanted to see a more intuitive represntaion in a liniear singular timeline. With this approach we could add inline contextual information that would again make it more useful.
The list of processes in the Triage Summary wasn't intuitive in that they are parent, child and sibling relationships which in best practive should be reprsented in a tree fashion.
Knowing the new visualizations we wanted to introduce we explored refining the layout of the Triage Summary one of which would flip the content around in orientaiton entirely. This allowed for a side by side exploration of events which made syncing the information in the graph and detail in the tables much easier.
We explored using the existing layout to reduce development time however after wireframing different options and realizing a clear direction in which to proceed.
We also wireframed the contextual popups, exploring various layouts, as these would be key in keeping the analysts in Endpoint without needing to leave and get these insights from other tools.
The final design ended up with numerous enhancements to give our analyst a more thourough examination of a potential attack.
We made the UI more intuitive by...
We made the Triage summary more insightful by...
We made the triage summary more capable by...
High fidelity mockups were created and reviewed by the design staff and the analysts that assisted in the research.
Mockup for the contextual modal with additional insights. These insights can be anything from an exicutible to an IP used by a know threat actor.
The Triage Summary is only a small part of the entire Endpoint application but it might be the most critical area in that it allows our analysts to determine if an attack was successful, who did it, what did they do, did they exfiltrate any sensitive information, how wide spread the potential damage was and the ability to stop the attack.
Previously our anaylyst were cobbling together information from a variety of sources and now they have a more complete way of viewing and dealing with an alert.
With our improvements the product is more capable while saving valuable time. Ultimately this effort has allowed our customers to better protect themselves in an increasingly dangerous online world.
Here you can see the user clicking on an event in the timeline to get additional insight.
Metricly provides analytics that allow organizations to proactively address performance issues across applications and IT infrastructure.
While I was with Metricly we pivoted from being an on-premise software solution to a cloud based SaaS application.
Rebuilding our product from scratch, I not only did the design for the entire product but also drove the adoption of supported CSS frameworks and created a comprehensive design system.
Our user were creating dashboards however, when using just the metrics provided by AWS, the dashboards quickly became large and required a great deal of experirise to intrepret.
We needed to make the dashboard experience simple and straight foward but to do this we first needed to add the 'computed metric' feature.
Add a computed metric feature to the product. Creating a computed metric should be easy and intuitive yet powerful with a wide range of options.
Simple computed metric formula examples that could be beneficial to a devop environment.
The basic UX process could be thought of as research, ideation, design and testing however there are a multitude of facets to each, facets within facets and not every UX challenge is the same. A UX problem could require you to go through either a more expanded process or just the opposite, a trimmed down more focused process.
As many large customers had been asking for computed metrics and it was quickly moved to the top of the backlog of features to implement.
I did some research around computed or calculated metrics to make sure I firmly grasped the the concept. I also did some cometitive analysis where other had similar features.A great many examples that proved to be helpful were computed metrics for Google Analytics.
I worked with our in house subject matter experts(SMEs) to determine the bare essentials of the computed metric feature. How will they be created? How will they be tested and how will they be ultimatley used.
Along with interviewing the SMEs I also created a survey for them to take to help stack rank the importantance of computed metrics and their potential uses.
Sampling of computed metrics survey results.
My approach to the design process usually has quiet a bit of sketching involved. After my research I wanted to build on the experience where the user could not only create the computed metric but also test it. Additional settings which occupied their own separate tab were also seen as having the ability to be further developed over time.
The wireframing stage brough the task into better focus and allowed me to explore with very little cost the different varying amounts of data that can be involved.
Defining and testing a computed metric following by saving allows it to be used in dashboard widgets, policies that affect alerting and reports.
By adding computed metrics to Metricly we saved users hours of potential eyeball calculations fraught with the potential for costly mistkaes.
Computed Metric Editor
Computed Metric Editor
Computed Metric Editor
NowSecure is a mobile security platform that helps organizations detect and remediate critical vulnerabilities in their applications. During a major product overhaul—undertaken to address years of technical debt—we introduced MASVS (Mobile Application Security Verification Standard) compliance testing as a core feature. This standard, recognized widely in the mobile security community, allows teams to benchmark their apps and ensure they meet best practices for security and privacy.
At the time of this project, I worked closely with teams across the organization—from the CEO and product owners to sales engineers, developers, and project managers—to rebuild the entire product. Part of this rebuild involved establishing a comprehensive design methodology in Figma, creating a scalable design system to support rapid iteration and consistent UI patterns.
Because of the technical debt we were addressing, the team was lean and often required each of us to “wear multiple hats,” from ideation to implementation.
During Weeks 1–2, our goal was to lay the foundational work for integrating MASVS data into our product. We needed to define clear requirements, align the design with engineering capabilities, and deliver an MVP that demonstrated value to both existing customers and prospects—all while ensuring the solution was user-centric and scalable.
The primary objectives were to:
Design Research
This structured foundation was critical in ensuring that our product was both functional and user-friendly from the outset.
Initial concise MVP
In Weeks 3–4 of our project, we initiated an internal “Alpha” launch targeting select enterprise clients and internal security teams. Our goal was to gather early, actionable feedback to ensure our design met diverse user needs before a wider release.
Our objectives were to validate and refine our design by:
Over a two-week period, we:
Key Insights Discovered:
Based on the Alpha feedback, we redesigned the user experience for the Beta release by:
Beta design with drill down functionality
By systematically gathering and acting on early user feedback, we were able to:
This structured approach not only enhanced the product’s usability but also built a solid foundation for wider adoption in subsequent launches.
In Weeks 5–6, after the initial launch, we observed that our main compliance dashboard, while rich in information, was overwhelming for new users. The layout—with multiple color-coded sections and dense text—made it difficult for users to quickly identify which vulnerabilities required immediate attention. Additionally, the “risk level” indicators sometimes conflicted with the MASVS categories, leading to further confusion.
Our goal was to iterate on the dashboard design to improve usability by:
Workflow from landing to findings
Responsive designs, from 'mega' to mobile
This iterative process allowed us to refine the dashboard, making it more user-centric and effective in highlighting critical vulnerabilities post-launch.
Following the successful Beta and subsequent refinements, we launched the MASVS compliance feature to all existing NowSecure customers. We also collaborated with our sales engineers to demonstrate the new functionality in product demos, emphasizing:
During this phase, we also continued to expand our Figma design system to support new features—like automated compliance alerts and advanced reporting.
By integrating MASVS compliance into NowSecure’s platform, we significantly improved user understanding of security standards and offered actionable insights for remediation. The simplified UI and tiered explanations built trust with both executive stakeholders and technical teams, allowing them to see immediate value in adopting the standard. This project not only enhanced the product’s competitive edge but also laid a strong design foundation for future features and improvements.
Final design fully collapsed
Final design with section expanded
The different states of the reports including the Findings tab
Thank you for reading!
