I am a user experience professional with strong qualifications in research, prototyping, and design to deliver production-ready solutions quickly.
I am a web development expert with over 20 years of experience using code to solve problems with systems, accessibility, localization, and performance.
I am a thought-provoking educator who has taught hundreds of students the applications of user experience and engineering methods.
What if a design system was truly focused on user needs; both for those using the product and the ones building it. What responsiblities would it have? What should it contain and how would it be made to help people achieve their goals? In this project, I explored how engineering tools and architecture can help support anticipated design needs.
I've been creating and working with design systems for a few years now and I've gained a great deal of knowledge and experience in that time. It seemed important to document all of the concepts that I found useful or interesting and share them with others. Often my peers and I are unable to do exactly what we want to do because of the organizations we work with so this was meant as a guide to my beliefs in design system architecture.
As a design systems architect, I want to describe my thoughts in design and engineering as a documentation site without business influence.
One of the biggest mindset shifts in this project is the idea of "intents". These are variables that describe the intent of the designer to describe a part of the UI. Instead of assigning the background color red directly to a button with a dangerous action, a variable (ie. an intent) called "action critical background-color" is used instead. What makes these variables special is the naming framework designed to be scalable for future UI components. The framework aims to describe general design concepts that can span across multiple components.
Several tools were also built to help inform the design process. A color contrast system was made to decide on the correct colors to use for light/dark mode. Additional functional components were made to help identify other accessibility concerns like Irlen Syndrome. Many of these can be interacted with using controls found around the site to experience how certain values would affect the UI. The site is also a Progressive Web App (PWA) with offline capabilities.
You might think that checking the weather is a solved problem several times over. However, nearly all weather apps do the same thing; they provide absolute numbers. This solution aims to provide weather data relative to the user so they can make more personalized decisions on how to prepare for the new day.
If you ask this to many people, a common answer is to prepare for the day. If it's going to rain, we might need an umbrella. If it's going to be warm, I might not need a jacket. We check the weather on any of the current weather apps today and it tells us there's precipitation, or a number of degress that the high temperature will be.
If it's 60 degrees today, what does that mean? Is it hotter than it was yesterday? How can you tell? Most often, without looking up historical data, your weather app doesn't tell you. You have to remember how 60 degrees feels and if you need a jacket or not.
As a person getting ready to go out of my home, I want the weather to tell me how much it has changed.
The solution is very simple. We save the forecast data from yesterday and compare to today. If there's a signifigant change, we notify the user with the qualities that have changed and by how much. They can make the determination on what to do with that information (bring an umbrella, wear a jacket).
The interaction is a simple button that asks for permission to lookup the user's location (or optional postal code input), and the result is a link to their area's weather feed. A user subscribes to a notification feed for weather in their area and they'll begin getting notified of signifigant changes.
Sometimes a single button can prepare you to tackle the coming days better than you did before.
Just about every website uses icons to help convey information and wayfinding. Some of the smallest components of a page are also the most difficult to manage in a simple and performant way. This project provides options for developers to maintain these assets easily.
While building the DAMATO Design project, I found a challenge in managing icons that I once tackled before within my time at Compass. There's a lot of ways to render icons within a webpage or across a website. I wanted to create something that could be used in many ways depending on the architecture of the website.
As a engineer, I want a reliable way to manage icons on a page and style them using CSS.
There are several ways of providing an SVG icon (or really any SVG) on a page to allow for CSS to modify it later:
- Inline SVG markup exactly where the icon is expected.
- Using a reference sheet that exists on the same page and reference where the icon will be rendered.
- Referencing an external stylesheet with the icon within the same domain as the page and reference where the icon will be rendered.
There's some problems that can occur with the second and third approach above which happen when using Shadow DOM or trying to access SVGs across domains. I wanted this project to have solutions for these problems as well. The result handles normal use-cases along with other edge-case usage and is successful in applying SVG icons on a page in multiple ways easily. This was also my first contribution to the open-source NPM eocsystem so I also ensured to add several connected services to highlight build quality and test coverage.
How many clicks do you need to get to the arrival time of your train? This project tries to reduce the number of decisions to make when the next train is expected to arrive near a user's location. Think it's easy to find the time? You might be surprised.
Sometimes people get paralyzed by choice. This is common in navigational patterns with many options that a user can choose from. If we instead consider removing some choices from the main navigation, users may direct themselves toward their goal faster, thereby creating a better experience. This project is an exploration on how much navigation can be removed to get to a very specific user need.
As a person getting ready to commute in New York City, I want to know when the next train is arriving for the line I take most frequently at my location.
The problem has a few asks; the user wants:
- The time(s) of the next arriving train
- For a specific line
- At their current location
A common solution would be to provide an app that allows the user to choose the line from a menu, choose the station that is closest to them and find the next arrival time from the given schedule. Oh, and don't forget what direction they will travelling in, that's another choice the user needs to make. How can reduce the steps?
We certainly can take out a step with geopositioning; the app can determine the closest station but perhaps we remove another step. However, can we remove the selection menus entirely?
Almost! The solution is to provide a dynamic URL scheme;
https://SUBWAY_LINE.willarrive.in that a user can favorite in their web browser where
SUBWAY_LINE is the number or letter that represents the subway to which the user needs the schedule. Examples:
The only selection the user needs to make is the direction they are traveling. Certainly, if the user is at a terminal, we can simply provide the only direction we expect them to travel in. For stations located in the middle of the line, even the most accurate positioning will be confused within a subway station with some direction from the user. This ask has very little congitive load, since the choice is presented as either this way or that way (eg: uptown or downtown, Manhattan-bound or Brooklyn-bound).
Removing choices for the user can mean the difference between getting to an appointment on time or seeing the doors close from a missed opportunity.
When engineers write documentation, they often write code twice. Once as inert documentation and again as executable code. This project aims to surface the real comments and code together as the final documentation. This is also a home for useful techniques I find in front-end development.
One of the parts of the product development process that is often overlooked is quality documentation. So much time is spent curating the best experience or delivering performant code that many forget to provide resources into this task. Granted, it could be said that the best experiences do not require documentation but in the world of development, being verbose might mean more code.
To create documentation for engineers, it is often rewritten or curated as a translation from the source code. This takes time to edit and methods (eg: Markdown) have helped speed up the process but can we just use the code we've written as the documentation?
As a person writing code, I want to provide documentation without rewriting what was written as documentation.
The solution was a proof-of-concept to document the code within the code using JSDocs (ie: comments that live with the code) and having a process that runs to combine the commented documentation with the code itself. Examples are written as testable code to provide quality code coverage.
Enhancing the developer experience is important to keep focus on when creating performant quality products. This allows teams to move fast without breaking things and instead providing clarity for future collaborators.
How do you create and maintain a consistent experience across a global brand which needs to be accessible, localized, and performant across several brands? GoDaddy has more challenges than I could have imagined when I started my journey in design systems.
A well-recognized internet company for over 30 years, the GoDaddy brand is a challenge to tame. I was brought on board to help scale an existing system of providing resellers and private labeling to allow for more customizations and experimentation. The new system allows for not only the compnent library to accept different values of color, typography, and roundness but also allows for feature developers to leverage the system for themselves and create new feature specific components with the same style. The system is also expandable to other style properties such as spacing and elevation in the future.
I am also involved in several initiatives around accessibility and localization; both important topics for a globally influential brand to adopt. I have also created a team of amabassadors which represent each product to facilitate feedback on the needs for these product which help inform what the platform offers. Future plans include embedding metrics into design system offerings and reporting inconsistent or undesired usage of design system resources. The north star for this system is low maintenance while keeping everything up-to-date.
Teach a person user experience and the world will benefit. I facilitate a course that begins a student's journey into user experience at Parsons School of Design. The subject matter centers on gathering facts in different approaches to make data-driven product decisions that meet user needs.
Learning about user experience research is a great way to start on a journey in product development. A good idea can become better when really understanding your audience and making decisions based on feedback. This course teaches the basics of UX research by way of video lessons and discussion boards. Students either pick a hypothetical project or begin research on their own ideas. Student then begin preparing their research presentation with user personas, competitive analysis, and journey maps to help inform their product. Each week I provide feedback on their projects with recommendations on other areas to include or questions to consider. The important focus is to find the truth, not to validate an idea.
Every student is different and understanding that fact is a key to effective teaching. My unique method uncovers skills and strengths that the student has which will help make better product in this new digital world. We focus less on what the job wants you to know and more on what you want to achieve.
Teaching has always been a passion of mine and it's important to me that people also find their passions. While code is a booming industry with a lot of opportunity, it's important to find the right career for each individual. Sometimes the concepts that I teach will never interest a student and it's important to recognize this early. It's not about enrollment, it's about impact.
My teaching methods take real-world, everyday concepts and then write code to describe them. In other words, creating an
add() function is mostly useless. Instead we talk about warming up pizza in the microwave and that the appliance can be considered a function with inputs; returning edible food as a result. This approach is useful for people just learning about code for the first time so they can start thinking conditionally or about orders of operations and less about getting the syntax right.
From being responsible for the CSS across the platform to creating the framework-agnostic global navigation for our products, I earned influence across the organization from nearly every angle. A leader among design and engineering teams and well known throughout the company as a person who delivered quality results.
I was originally hired as a front-end developer to work on the Agent Experience team. After making connections with co-workers and understanding the needs of my teammates, I transitioned to the UX team as their first UX engineer; initially working on prototypes and design tooling.
Later I was responsible for the global navigation of the internal site which was to be injected into every application. It was important to understand the current state of each individual application; as they were built by different teams in various methods. The final deliverable was able to be rendered on the client or server. It was also framework-agnostic; able to be included in legacy and modern applications.
I also mentored the engineers in the brand and marketing department in ways to align with our existing engineering model and to upgrading existing technologies to better support the needs of the business.
Toward the end of my tenure at Compass, I grew the Design Systems team to include product designers, content writers and additional UX engineers. I led the team to consider novel ways of supporting our designers and engineers in creating a consistent look-and-feel for Compass and the internal tools for real estate agents. Much of my work continues to exist on the site and within the application today.
A side project leveraging modern development techniques at the company turned into a full site-wide application rewrite. I was able to prototype workflow possibilities faster than other teams could fully realize the potential. This was only the beginning of my responsibilities to come.
I was hired at Itemize to take their web application to the next level. It was originally an aspx-driven product which desprately needed an upgrade to use single-page application techniques. The team also didn't have a designer so I was also able to leverage my design experience to help inform product managers and contractors overseas on other design needs.
After finishing the smaller data-visualization project in the first month, I began rebuilding their consumer-facing web application from scratch. The project was complete and ready for production in about 4 months. Then I set my focus on improving the internal processing tools that were used daily by the auditors. I collected their feedback and made improvements to the experience to help them work faster and more accurately. I also built metrics dashboards for the marketing department to track users and usage across the globe.
Over the coming years I led the product development lifecycle reporting directly to the CEO; collaborating with the rest of the engineering team. I was also involved in the hiring process for senior members of other departments being recognized as a cultural influence for the company.
After finishing my Masters degree, I was asked by the chair of the Communication Arts department to teach new students about live event production as I had experience in the entertainment industry prior to college. Together we created a curriculum that continues to exhibit how much being prepared can affect the value of the final outcome.
I was first full-time instructor for Globesville, a student-run media channel originally on the Old Westbury campus. Students were grouped into teams that would produce their own weekly shows to be streamed live on our website for the majority of the semester. Grades were determined by production quality, engagement, and content. The end of the semester concluded with a marathon show where each team would need to work together to produce several hours of content to be live for the entire school day. This highlights the importance of collaboration and preparing for technical difficulties. Understandng how to work in a live production environment helps students understand the importance of prepareness for endeavors beyond media.
When organizing a competitive event, directing your competitors to a gaming area is a challenge. The event will likely have many distractions; time is lost trying to locate them and record results accurately. This project was an attempt to solve this problem with a little bit of technology.
I've ran video game tournaments for a few years and one of the biggest things that will slow the event down is finding the people who are in the next match. After the first hour, many people begin taking breaks or watching other matches. Searching for the people in a tournament bracket becomes the most difficult thing that day to keep the event moving.
As a tournament organizer, I want to contact participants about their matches without searching for them throughout a venue.
The important part for me was that I didn't want the participants to need to download an app. I wanted the system to just work with their phone through SMS. I made a system that describe the stations where matches would be held and allowed the competitors to text the results of the match back to the organizer. There were checks in place to ensure the results were accurate and results would automatically be uploaded to bracketing software. As long as the competitors engaged with their phones, the system would automatically run the tournament.
This was the first project where I needed to learn backend technologies and admittedly this was a huge undertaking. I needed several database tables and needed to make calls to the Twilio API to send and receive SMS messages accurately. It was a great learning experience and ultimately helped me understand the requirements of an entire development stack.