"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. 2020
Spring from Capital One is a website dedicated to providing small businesses with discounts on goods and services.
While Spring is a free service, it requires visitors to sign up and log in before revealing any discount codes or links. Existing Capital One customers automatically have access by logging in with their Capital One online credentials.
Although compiling discounts on a site or application is not unique, Spring sets itself apart by having a deals team at Capital One that negotiates discounts often superior to those found elsewhere.
Spring's homepage experienced an astonishing bounce rate of 97%. Such a high bounce rate is unacceptable even for blogs or news sites, where users often visit for a specific purpose and then leave.
In light of these statistics, we realized the challenge ahead and established the following objectives.
Spring soft-launched in 2017, but its formal national launch wouldn't occur until late 2020. One issue was that the copy did not clearly convey the purpose of Spring to users. Additionally, there were no examples provided to reinforce its purpose. These were some of the pain points that needed to be addressed.
The basic UX process can be thought of as research, ideation, design, and testing; however, each of these stages contains multiple facets, and not every UX challenge is the same. Depending on the problem, you might need to go through a more expanded process or, conversely, a trimmed-down, more focused one.
For Spring's homepage bounce rate problem, the process started with a UX audit of the entire site. While this involved looking at more than just the single page in question, I was new to Spring and needed to understand the site as a whole to deliver relevant insights that could potentially be carried throughout the application.
The UX audit provided a critique of the homepage, noting mistakes in UX best practices and a lack of content to inform users exactly what Spring has to offer. Just as importantly, it provided key information by defining personas and customer journeys, as well as evaluating competitors.
Upon joining the team, I conducted a comprehensive audit of the Spring product. This helped me better understand how a change on one page might impact the rest of the site.
Our UX researcher and I conducted a series of qualitative tests on the homepage to gauge users' understanding of Spring. I believe that visitors need to understand what the product offers in a concise and compelling way to encourage them to take the next step and drive adoption.
We discovered that visitors were having difficulty understanding the purpose of Spring. Above the fold, there were only catchy but somewhat cryptic marketing blurbs, which kept our marketing department happy but didn't assist users. We followed our initial tests with a series of straightforward comprehension tests, which confirmed that the page's copy wasn't effectively conveying the product's purpose.
Furthermore, the main call to action was cryptic, as the button label didn't inform users where they would be taken. Considering these elements, it was easy to empathize with the users' confusion.
I love the immediacy of sketching; not relying on anything digital is truly freeing and allows ideas to flow quickly. Sketching often involves numerous iterations, again because you're not held back by a digital platform. In these situations, the eraser or a new sheet of paper can be a powerful ally.
These are just a few sketches for demonstration purposes; however, it's not unusual to create two, three, four, or even five times as many.
We refined several options into 2D, architectural-style representations of the design. I found that the main advantage here is allowing stakeholders to focus on the content and flow. Without color distractions, there are fewer elements to divert people off topic. After reviewing these, it was easy to determine the next step we wanted to pursue and validate.
Wireframes serve a vital purpose; the focused attention and feedback you receive from stakeholders during this phase are often extremely helpful.
I created the mockups in Figma, which enabled me to utilize the official Capital One design library called 'Gravity' for basic elements and responsive grids. We also needed to develop our own separate design library for our product, incorporating UI elements specific to it. We wanted the product to align with its siblings yet be distinctive in certain visual treatments and micro-interactions.
Applying insights from the research phase, we updated existing content and added new copy to communicate clearly and directly what Spring offers to users. The call to action, aligned with the new copy, featured a clear label informing the user of the next step.
By aligning with the corporate design system, we were able to leverage the trust already established by the corporate brand.
High-fidelity mockups are reviewed and critiqued by the product experience group, leading to additional insights and ideas.
Test, test, and then test some more. While we have made significant improvements to the bounce rate, iteration and A/B testing continue. As a designer, once I start working on a problem, it's hard to let go. For this project, I will keep discovering and testing. I believe that data-driven design is highly effective and addictive, which is the stage we are currently in.
This interaction shows the user going from the homepage to the merchant offer.
FireEye's HX, commonly known as Endpoint, is a product designed to monitor computers—or hosts—for signs of cyber attacks. Each host has an agent installed that monitors various types of events and saves them for review.
The Endpoint workflow enables security operation centers (SOCs) to confirm threats, isolate affected hosts, and examine a host to determine the exact nature of a threat, whether it's an automated attack or initiated by a human threat actor.
When the agent detects a possible compromise, it creates a triage package that logs events occurring before, during, and after the compromise.
When an alert occurs, time is critical. Analysts need to quickly ascertain what happened and when. They must identify who was involved—was it a sponsored threat group? Was the attack successful, and how widespread was it? Previously, the Endpoint application required numerous clicks to find essential information. Users often had to leave their investigation to navigate to other parts of the application to perform queries or exit the application entirely to find crucial information elsewhere. In short, it was taking analysts too long to conduct an investigation, and the process was cumbersome.
We needed to keep analysts within the context of their investigation as much as possible. To achieve this, several pain points had to be addressed.
Viewing an alert's Triage Summary was revolutionary when it was first introduced, but as attackers became more sophisticated, the tools to combat them needed to evolve.
A typical, simplified UX process can be thought of as consisting of research, ideation, design, and testing.
To illustrate the process, we can see that multiple revisions may occur during the ideation, design, and testing phases.
The Triage Summary is intended for a select group of analysts with highly specialized knowledge in cybersecurity. When conducting research for the Triage Summary, we needed to interview these analysts to identify their pain points and needs.
Fortunately, the work on the Triage Summary coincided with FireEye's annual Cyber Defense Summit, allowing us access to a large number of analysts.
When viewing a Triage Summary, analysts generally have similar goals:
The primary pain point most often repeated is that it takes too long to determine if an attack was successful. The main culprit is that analysts need to leave the product to gain additional insights about pieces of intelligence, most commonly IP addresses or domain names. Other contributing factors include the lack of context around the host they are viewing in the Triage Summary—such as its location, operating system, etc. Additionally, the processes in the Triage Summary have parent-child relationships but aren't displayed as such. Finally, there is a need to simplify the information presented in the swimlanes of events.
Analysts can derive a wealth of insights from the Triage Summary timeline of events. Therefore, exploring how it was visualized and assessing its capabilities—or lack thereof—became our starting point.
One of the pain points we gathered from the analysts was that the existing swim lanes of events were limiting, and they wanted a more intuitive representation in a single linear timeline. With this approach, we could add inline contextual information, making it even more useful.
The list of processes in the Triage Summary wasn't intuitive because they involve parent, child, and sibling relationships that, according to best practices, should be represented in a tree fashion.
Given the new visualizations we wanted to introduce, we explored refining the layout of the Triage Summary. One approach involved entirely flipping the content orientation. This allowed for side-by-side exploration of events, making it much easier to sync the information between the graph and the details in the tables.
We initially considered using the existing layout to reduce development time; however, after wireframing different options and realizing a clear direction in which to proceed, we decided to change our approach.
We also wireframed the contextual pop-ups, exploring various layouts, as these would be key to keeping the analysts within Endpoint without needing to leave and obtain these insights from other tools.
The final design incorporated numerous enhancements to provide our analysts with a more thorough examination of potential attacks.
We made the UI more intuitive by:
We made the Triage Summary more insightful by:
We enhanced the Triage Summary's capabilities by:
High-fidelity mockups were created and reviewed by the design staff and the analysts who assisted in the research.
Mockup of the contextual modal with additional insights. These insights can be anything from an executable to an IP address used by a known threat actor.
Although the Triage Summary is only a small part of the entire Endpoint application, it might be the most critical area because it allows our analysts to determine if an attack was successful, who executed it, what actions they took, whether they exfiltrated any sensitive information, the extent of the potential damage, and provides the ability to stop the attack.
Previously, our analysts were cobbling together information from a variety of sources, but now they have a more comprehensive 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 obtain additional insights.
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 empowers users to scan mobile applications for security vulnerabilities that could allow hackers to access critical information.
During my time at NowSecure, we rebuilt the product from the ground up, addressing years of technical debt. I collaborated with individuals at all levels—from the CEO to product owners, sales engineers, project managers, and developers—to redesign the entire product and key workflows. In addition to the product overhaul, I developed a comprehensive design methodology in Figma. This design system streamlined the design process, enabling faster iteration and more efficient collaboration.
Our goal was to enhance NowSecure's platform by incorporating MASVS compliance testing. This new tool enables users to benchmark their mobile applications against the Mobile Application Security Verification Standard, which is widely recognized for its comprehensive approach to mobile app security. The integration of MASVS testing aimed to achieve three main objectives:
While the basic UX process is often thought of as research, ideation, design, and testing, each of these stages contains multiple layers and complexities. Not every UX challenge is the same; some may require a more extensive process, while others might benefit from a streamlined, focused approach.
I dedicated considerable time collaborating with a team member who was also a contributor to the MASVS standard. This deepened my understanding of the standard and enabled me to effectively communicate its purpose and importance to the rest of the team, building trust in our design decisions and direction.
I spent significant time working with a team member who contributed to the MASVS standard, immersing myself in its intricacies. This helped me convey the standard's objectives and significance to others on the team, fostering confidence in our design approach and overall direction.
Various competitors and their workflows.
It became clear from user interviews that different user types needed to be considered in the design. Initially, the MASVS Report would serve as a high-level executive summary, revealing to the user how the application performs with regard to the MASVS standard testing groups. It seemed reasonable to allow users to delve deeper after that, drilling down on the same page. Both development leaders and project managers benefited from this approach. The viewer can then access more specific information, such as individual findings, within the same report and context.
Apps.
Security Report.
Package Details.
MASVS Report - High level Executive Summary.
Testing Groups.
Inline Findings.
Findings Tab.
