"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 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 enables users to scan mobile applications for security holes that could allow hackers to gain access to critical information.
While I was at NowSecure, we rebuilt the product from scratch, tackling years of technological debt. I worked with individuals, from the CEO on down, including product owners, sales engineers, project managers and developers to redesign the entire product and key workflows. Along with the product but also I developed a full design methodology in Figma. The design system streamlined the design process, enabling faster iteration and more efficient cooperation.
We intended to improve the capabilities of NowSecure's platform by adding MASVS compliance testing. This new tool allows users to compare their mobile applications to the Mobile Application Security Verification Standard, which is widely regarded for its comprehensive approach to mobile app security. The incorporation of MASVS testing had three main objectives:
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.
I spent a good deal of time with a member of our team, who was also a contributor to the MASVS standard, learning about the standard. This helped me communicate to others on the team the what and the why of the standard and built trust in the design and direction.
I spent a good deal of time with a member of our team, who was also a contributor to the MASVS standard, learning about the standard. This helped me communicate to others on the team the what and the why of the standard and built trust in the design and direction.
Various competitors and their workflows.
It became clear from user interviews that different user types needed to be catered for in the design. Initially, the MASVS Report would be a high-level executive summary. Revealing to the user how the application performs in regards to to the MASVS standard testing groups. It seemed reasonable to let users go farther after that. To drill down on the same page. Both the development leaders and the project managers benefited from this. The viewer can then drill down to more specific information, such as the individual findings, inside the same report and context. What is acceptable and, more specifically, what re
Apps.
Security Report.
Package Details.
MASVS Report - High level Executive Summary.
Testing Groups.
Inline Findings.
Findings Tab.
