I worked on many projects in my few months here, from patterns to full features to iterating on the design system. I can't show you everything but I picked two key projects form my time here that showcases the range of the projects I had the pleasure to drive. 🐺
Duration: January - August 2023
Role: UX Designer
Type: Internship
FOREWORD
This project is more based on pattern definition and design compared to the Unified Content Library project, which is focused more on detailed screens and the design of a new product and features. The saved filters process was extremely heavy on validation research and interviews with users, and is very focused on defining success criteria and making sure each use case of these new filters are addressed so that the user experience is seamless.
BACKGROUND AND PURPOSE
Lost efficiency. Many use cases across AWN products have very robust filtering requirements, where users have to manually adjust a plethora of filters to whittle down the data into a digestible state. And that can be a lot of filters! This isn't only tedious, but also leads to added inefficiency in the workflow that can lead to lots of wasted time especially when multiplied across the entire userbase. We are trying to address this issue by looking into ways to allow users to immediately save and access filter sets.
RESEARCH
What I did first was to try and dig deep into the Current State of the filters at AWN to understand the pre-established patterns of the product and how this new feature can fit into it, along with making note of ways the user experience may be improved in general. What was important for me to remember is that this ticket is not re-inventing the current filters — AWN has a robust design system and many established patterns throughout their products already, and we want to play within that court. This limited my options quite a bit, especially when I was researching competitors and what was already out there (namely Qualitrics, Notion, and Linear).
My current state research involved:
A critical part in my research was determining the use cases of how filters are implemented across each of the products currently. For this, a workshop for each SME was set up with their respective products to determine individual use cases of filters and whether the saved filters function will be necessary for each case. This helped narrow the scope and focus and helped define exactly where the function will live.
RESEARCH
SMEs were prompted with a template to complete a highlighting the ways filters are currently used at AWN today. Screenshots of filters with context and pain points for each product were collected.
Other SMEs and users were pinged to give context on their specific products to get a more wholistic view on how filters are used and integrated and how they may be improved.
Purpose:
Outcome:
The use case workshop looked a little something like this:
(Except there were about 12 of these frames as we had one for each product under each SME. Some details are blurred for privacy purposes.)
RESEARCH
IDEATION
These flows are to capture the save filter, view filter, edit filters, and delete filter functionalities. Efforts were made to not draw too much attention or to make the design too salient on the interface itself, in order to not make the user feel as if these were necessary steps. These were developed in conjunction with a future state journey map (not pictured) to give me a more holistic view on interaction and user workflows. This step was extremely helpful in giving insight on how to proceed to next steps.
(User flows for saving filters and editing saved filters.)
IDEATION
Referencing the above flows, I started putting together rough wireframe sketches. These sketches were quick and rough, to list out all possible options in order to visualize them and immediately rule out possibilities that weren't feasible:
(Some sketch exploration before I dug deep into cleaning and finalizing components and patterns on Figma.)
DESIGN HIGHLIGHT
Goal: Intuitive, Invisible, Effortless
Designing the user experience and layout around the way users will view, edit, and apply filter sets seamlessly was a particularly challenging part of the design and was the part that went through the most trial and error with design reviews and iterations. Competitors all approached this vastly differently, and none of them seemed to fit perfectly into established AWN patterns.
Design can’t be done in a vacuum. While the saved filters pattern will be an important QOL update to users, it is not the main purpose of the filterable page. Designing a flow that didn’t demand too much attention away from the main focus required me to put my thinking cap on.
COMPONENTS AND PATTERNS
Pattern: Always located bottom right corner of the filter bar
COMPONENTS AND PATTERNS
Pattern: Saving on an existing filter set overwrites the previous settings
COMPONENTS AND PATTERNS
COMPONENTS AND PATTERNS
Pattern: Saved filters will be separated from the rest of the filter bar with a divider
FINISHING OFF
Goal: Ease of Implementation, Understandability
To make sure everything was hitting the mark, I called a few key users from different teams to test the patterns in typical smoke tests.
To minimize guesswork during dev handoff, I also made example use case flows in Figma, so devs know how these elements will look in each one of AWN's products (the one's we indicated will need this function, as we established in the SME Workshop.) This also involved UX Design Guidelines and a lengthy documentation file on Confluence just to make sure we're speaking the same language. Devs are users too! I worked on making everything as easily understood as possible -- having designs implemented incorrectly would be a usability nightmare!
REFLECTION
In an ideal world where I have more time with the company, my next steps would be to oversee the launch of these saved filters across internal tools and monitor the success. As this is a new feature, I’m curious about how intuitive the flow is. I would’ve loved to analyze initial interactions through HotJar to see where the flow could be improved and iterate upon those findings. I also would’ve loved to analyze the effectiveness of saved filters as a whole in speeding up the workflow of engineers. The saved filters project introduced me to more robust use case research than I was used to typically doing in my previous projects and I’m extremely grateful for the experience I was able to gain in this opportunity.
FOREWORD
I wanted to showcase this project in particular as it took a completely different structure compared to the Saved Filters project, where lots of pre-planning and personal research went into the structure of the final patterns. The Unified Content Library (UCL) ticket was more of a fast paced design process where I had to hit the ground running. While this isn't traditionally what is seen in these case studies which have very defined and detailed design processes, there are many cases where jumping right in is necessary as well.
BACKGROUND AND PURPOSE
The UCL is a new feature in the Data Explorer of the AWN Managed Risk. It is a solution to the disarray of risk information the security staff needs to hunt down to address customer issues, and a portal for customers to search their own necessary data instead of contacting Security Services (S2) each time. The need to check multiple sources leads to context switching, increased engineering effort, and therefore increased wait time for customers. The UCL solution will decrease the load on our own staff along with improving QOL for customers. Any reduction in the time S2 takes to address customer tickets is a win.
SETUP
Research on this project was on a much smaller scale than the saved filters project. A big part of this was speaking with key members of the S2 team to understand their workflow and understand which features would be most important for them to do their job most efficiently.
PLANNING AND RESEARCH
Through this we established an MVP of just the search and details page initially, and the other defined pages will remain out of scope until they are implemented at a later date.
IDEATION
There were 8 wireframe sketches that were created by the product team for each page that was determined to be a part of the UCL in pre-planning. Out of the 8 pages (overview, browse, catalog, etc.), only the Search and Details page were determined to be the MVPs of the project, and is what we are focusing on. For full context, I created mockups for all defined pages to best sort out how they will all be linked together to be implemented at a future date. The MVP wireframe examples are:
(Low fidelity wireframes for the UCL MVP functions.)
IDEATION
The brunt of the work was translating those lo-fi frames into the existing AWN design system with respects to established patterns. This meant I had to take note and flip through past and existing designs and patterns to make sure the components I adhered to adhered to them. This meant I had to tweak the designs away certain interactions and layouts in the lo-fi frames.
Here's a little peek at my designs for the holistic experience in the UCL, including all the interactions and functionality as initially outlined in the planning phase. We decided to just go forward with development for the MVP pages first, but it was nice to have everything to visualize the entire experience, and having everything definitely helped with decision-making during product meetings and design reviews. I won't be able to go in depth on everything as much of it isn't even in development yet, but I hope I'll be able to show off the designs in the future!
(Frames, states, notes, and UX guidelines for the UCL.)
DESIGN
These are a few of the final frames for the MVP. I've opted to only include the base states of each in this case study, so you won't see every state possible for these pages.
The next steps at this point was getting everything validated and running the designs over members of the S2 team that will be using it the most at first.
The MVP, the details and search page, will be initially pushed internally to S2 and opened up to MR customers down the line. It allows the user to filter and search their risk data and see all important data related to it instead of having to hunt down each individually.
REFLECTION
What I would've done next involves a lot of data collection and testing. I would have loved to research on the ways this feature increases efficiency and decreases time spent by S2 on customer inquiries. And further in the future I would be ecstatic to learn the statistics around customer requests after it gets opened for customer use. And of course, iterate, iterate, iterate. I didn't have the chance to make a prototype for testing this time, but my next steps given I had more time would be to do moderated testing with S2 members with a prototype and iterate upon those findings.
An internship doesn't give way to much flexibility overseeing the development of the projects finished during the term. It always makes me a little sad I won't be able to see each design come to completion and iterate on the product!
Illustrated and Designed with ☕ by Lily Ding