Maureen Kelly
Low-fidelity prototyping lets me try a lot of ideas quickly, without thinking twice about scrapping things that aren't working. Wireframes are also great for getting early feedback, since there are no aesethetic details for reviewers to get distracted by.
I'm not choosey about wireframing tools. I generally use presentation software (e.g., Keynote, PowerPoint, Google Slides). It's easy to share broadly and lets me test-drive some basic interactivity.
I love creating high-fidelity prototypes, and have even rolled up my sleeves and done some front-end programming in the production code base.
To me, HTML prototypes are where a design really starts to come together. They help shake out details like scrolling behavior and transition effects. They give stakeholders a feel for the interactivity of a design in a way that static mockups can't.
For the last few years, my design work has been focused on a data analytics tool that lets users search and visualize log traffic:
Protest Finder is a personal project I've tackled during the first few months of 2025. I built the site from the ground up, with help from ChatGPT for the backend work and API integration.
It's been an interesting learning experience—both in terms of stretching my programming skills, and in learning more about ChatGPT's strengths and limitations.
Users liked the simplicity of SentinelOne's navigation, but as the product portfolio expanded, the nav wasn't scaling to fit the new products in a usable way.
After a failed overhaul, I tackled a more modest redesign that kept the simplicity while fixing the scalability problem.
While I was at Scalyr, we explored extending the product from log analytics into a more complete observability solution by adding support for tracing.
I created a never-before-seen product styleguide for Palo Alto Networks products, many of which came to the company through acquisitions and bore little resemblance to each other.
The process involved auditing existing products to identify common patterns and UI needs, creating interaction designs that spanned multiple use cases, working with the visual designer on appropriate styling, and creating a working reference implementation in HTML for developers to use.
I specialize in designing complex software that helps experienced users perform important business tasks. This particular project explored how to help security analysts visualize a malware attack, with enough context to help them understand the scope and impact.
I redesigned GlobalProtect, a MacOS and PC utility that secures endpoints.
The product had the funtionality users wanted, but our sales team reported they were losing deals because the UI was clunky. Some quick user research revealed that the complexity in the original UI intimidated users didn't make them feel secure. My redesign brought the idea of security out front and demoted complex controls that few users needed.
oDesk's old image uploader didn't help our users look their best. Whatever you uploaded, we just cropped a square out of the middle—which might mean you lose an ear, or the logo you spent the whole weekend designing ends up looking like this...
Not good. The new uploader makes it easy to select the part of the photo you want, includes some fun error states, and is smart enough to know that even though personal portraits can be square, logos tend not to be.
oDesk's old bank account form was just plain mean. It made you enter your bank's name and city. (City? Whose bank is in just one city?) And then you had to enter the routing number, and we gave you a stern little lecture about double-checking it to avoid delays and fees.
The new form shows you where to find your routing and account number. And we look up the bank name and location for you, which makes it much easier to confirm that you entered the routing number correctly.
When users first sign up for oDesk, we used to greet them with a list of demands ("Post a job! Add your payment method!") and an array of options, because who knew what users might want to do?
The redesign meets new users where they are. They're new; they have questions; they're not sure they're ready to dive in. And above all, they need oDesk to take the lead in showing them how things work and guiding them through the experience with clear, simple calls to action.
The firewall's Application Command Center (ACC) was intended to help users visualize network traffic by aggreating log data and letting users drill into areas of concern.
Unfortunately, the ACC intimidated users, who often simply ignored it. We wanted a new version for cloud users, who would be less likely to receive training and more likely to be overwhelmed.
The product manager created requirements to guide the redesign. Unfortunately, the requirements were as intimidating as the original UI. He skipped over the part about what we were trying to accomplish and dove into details of what data to show on which panels.
The PM also created a complete set of wireframes for seven different screens, each representing a "vector" of the data (e.g, threats, users, applications, etc). I don't think he realized that he was bypassing UX completely—he just thought of this as the requirements, and figured UX's job was to pretty things up.
The junior designer who was initially assigned to this project was torn between executing what the PM wanted vs. finding a way to improve the underlying design.
I was asked to get involved when it was clear the design wasn't moving forward. The PM and the designer both wanted the design to be better but weren't sure how to make that happen.
My first step was to take a giant step backward. I met with the PM and a senior PM who had designed the original ACC, then put together a quick deck summarizing design goals and success criteria. I kept this extremely high-level since we were trying to move fast. The project was well behind schedule at this point and we needed to get some traction quickly.
I also had several detailed sessions with the senior PM, to learn how people are using the current ACC—what common tasks they need to perform, what was working well, and what wasn't working well.
I started cranking out designs and reviewing them with the PMs every day or two.
I did these mockups in HTML—partly because I already had HTML templates ready to go, and partly because I knew this design was going to hinge on interactivity. I haven't found a better tool than HTML for playing around with interactions in a web-based product.
At the end of the two weeks, I handed this new approach off to the original designer. I walked him through the thinking behind it and discussed some remaining open issues, so he could work through further detail details and work with PM and development to implement the design.
Users liked the simplicity of the SentinelOne nav, but as the product portfolio expanded, the nav wasn't scaling to fit the new products.
The console was initially built for endpoint security. But as new products were added, we added new icons on the left—like Ranger, shown here. This meant that:
Before I got involved, there was an initial redesign that aimed to overhaul the nav to support 'n' products.
When it was eventually user tested, the results weren't good. Users found the new system confusing. They complained about having to hit "Back to all pages" to get anywhere. It was hard to move to siblilng pages.
When I got involved, the goal was to "de-risk" the project—accommodate new products that were being added to the console the following quarter, while keeping the ease of use people expected from SentinelOne.
My guiding principles:
I spent a couple days creating wireframe-level mockups of a few different approaches.
The VP of UX and I set up some quick, individual feedback sessions with internal stakeholders we thought would be good proxies for users (e.g., designers, PMs, and SEs).
Based on the internal feedback, I created one design for testing with external users. I worked with a fabulous user researcher, who planned and facilitated the sessions.
For this protoype, I created the nav in HTML, with screenshots of existing product pages in the content area. When the user clicks in the nav, the prototype shows the corresponding screenshot.
A few highlights of this design:
I continued to rev the design based on the user testing results and continuing feedback from other designers and stakeholders. Our central design system UX team made some visual design changes. Here's the final design that went live:
Main changes:
After the initial launch, as the product continued to grow, we decided to add collapsible category headers to the left nav, to keep its content organized.
