Over the past few months, I’ve been developing a narrative card game called Tararot. It began as a richly layered storytelling concept—with roleplaying elements, petitioners, quests, and a court of palace figures loosely mapped to the Major and Minor Arcana—but I recently found a breakthrough by going in the opposite direction.

I created my strategy coaching website as both a professional offering and a thought platform. The idea began with a simple question: what if I put out a shingle as a strategy coach? I bring three strengths to that role—I know a lot, I’m a good listener, and I deeply understand what it’s like to be a round peg in a square world.

Tarad.io is a website I made that broadcasts my MP3 collection.

Today, September 1, is the start of something I’ve been building toward for a long time: the Taralmanac. It’s my experiment in giving each day of the week a living rhythm — not just boxes on a calendar, but a set of eight touchstones that mix myth, history, and practice.

At my most recent job I worked on a comprehensive program for researching and designing my product's longitudinal patient view. For this project I worked on interviewing users to determine what they most wanted to see, and then using that research to propose a systematic redesign to improve the existing experience.

In this blog post I will describe how I manage a high volume of projects and design requests to ensure everything is processed, communicated, and filed. I designed this system and tweaked it until it worked flawlessly. It saves so much time and I can't imagine going back to not using Trello ever again.

At my most recent job, I worked on a SAAS product aimed at oncology care teams to help them visualize their patient's data and make decisions. In this blog post I will discuss the areas of this product that I worked on.

The goal of this project was to update an airline check-in kiosk with their new branding as well as simplify and refresh the user experience. I was the lead interaction designer on this project, working closely with my colleagues in visual design, user research, product management, and development.If you have used this check-in kiosk recently you have used something I worked on!

I saw this image and I thought, oh this has some good UX principles, so I decided to write them down. This is about how good user experience helps people get their work done quickly and painlessly.

Before I start designing anything, the first thing I do when starting out on a new project is investigate the true purpose of this product and its actual users. Beyond what marketing is saying and what the engineering team is excited to build, who is actually using this product today and what are they using it for? How exactly is it used, and by whom, and why? Or if the product doesn't exist yet, who do we want to use it, and what do we want them to use it for? The basis for a sound UX strategy for this product depends on accurately identifying these things. Although these questions seem like obvious starting points, the answers are usually not just available for the asking. I have to go digging for them, and over time I have learned how to do this.

In high school I had a social studies teacher who wasn't really respected by the other students due to his old-fashioned and gruff mannerisms and onerous homework assignments, like outlining chapters in the text book and visiting the grocery store to contribute to his personal longitudinal study on prices. But the opportunity to learn how to outline and organize information explicitly and rigorously has been priceless to me in my adult life and I will always be grateful to Mr. Packard for his single-minded dedication to this thankless but critically important undertaking. In this post I will describe how to properly structure a hierarchy based on those original lessons as well as what I have learned and practiced in the years since.

As the lead interaction designer on my company's design system project here is a bit about the work I did to redesign our library's website and content strategy to create a single source of truth for designers and developers to produce consistent & beautiful products.

The purpose of creating any kind of digital experience is to provide an interface for collecting some information so it can be processed and returned. The job of the UX professional is to ensure that this experience is at least able to be used, and at best, a pleasant experience that the user will return to. Like many other design professions, we create models to simulate this input and output of information to evaluate whether or not our design will meet those goals. However many common UX design tools don't allow for a realistic modeling of the experience being designed because they provide limited options for how we can simulate information going in and out. Therefore the information we gather from testing these models should be evaluated in terms of how realistic the simulation is and what information is lost from testing an inaccurate simulation.

The design brief in this case was to create a simple user experience where a business user, such as a manager in a busy warehouse, could type any natural-language query into a box and get answers back. They wanted the user to have the ability to do simple customization of their result, easily share their results with others, and save them for later. I envisioned a simple, one-screen experience with which the user could get answers to their questions without being slowed down by navigating or clicking. When the user types in the box, the answer to their question appears below, and they can fine-tune their answer by just writing in the box.

API management is software that companies use to enforce access rights to their APIs. I worked on the UX for the customer-facing admin portal for one of the industry’s leading API management solutions. I was on a small UX team and then the sole UX designer from ~2015 to 2018. During this time I designed many new features and UX upgrades, including a site-wide UX overhaul to enforce consistency and proper information hierarchy. I was also soley responsible for user research such as customer interviews, surveys, and usability testing. Before we started working on our “Organizations” feature, our enterprise customers could create APIs and API packages which could then be accessed, modified, or deleted by any employee with an administrator account. The design challenge was to design a feature which would let customer administrators define Organizations and sub-organizations, define ownership of system objects like APIs, and then indicate which users had access to which Organization.

These are some of the things I look for when designing and when evaluating a design.

Any project is just a series of questions that eventually get answers. In my work I have some questions that I am responsible for asking, some of which I get the answers from other people, and some of which I come up with the answers myself and then validate, depending on the project and who I'm working with. Here I have tried to list out some of those questions.