made by Jefff

Product designer & maker of web stuff.

I’m a Denver-based nerd, product designer, front-end tinkerer, husband and father. I’m also a lover of garage rock, Led Zeppelin vinyls, minivans, Tolkien & Discworld, and my collection of colorful pants. I have 12+ years of UX/UI design, front-end (HTML, CSS & JavaScript) experience, and am dangerous enough when it comes to Ruby/Rails and PHP.

I make products that help people do things they cannot easily do otherwise (like Find Your Newsletter, SaaS Weekly, imgRszr, or Betalist). I love product design because it lets me dive into user research, interaction design, visual design, and product management.

To me, product design is about creating something of value; something actual people will want to use. It’s the process of making the product better and better everyday. It’s learning what your users are doing, where they are struggling, why they are struggling, and how to alleviate those struggles, where possible. It’s also learning how they use your product: on Windows, mobile, low-bandwidth access, etc., and then designing for these scenarios.

Product design is almost never about making beautiful things. The word beautiful permeates the digital product world far too often; and it does nothing to help anyone derive significant value about a product. Let’s rather make something with meaning than with beauty.

Find Your Newsletter

The best newsletters on the web.

Finding great newsletters can be better. Plus, they are a great way to consume content you might not otherwise ever find.

Saas Weekly

Onboarding in SimplePractice

Welcome the customer, get to know them briefly.Figure out what their high-level needs, Jobs-to-be-done, are.Congratulate them for making it this far.Use progress indicators to keep them hooked and engaged.

Resulted in a 25% increase in paid conversions.

betalist

User testing with your actual customers.

Don’t waste anymore effort trying to recruit users for each test. And there’s no need to manage multiple lists of testers, in multiple places.

Highrise Tasks

The ProblemOverdue tasks are a huge point of pain for users of task systems everywhere. People love starting new task systems (Things, Asana, whatever), but once you start collecting old/overdue tasks people start throwing away/ignoring/starting over.

My SolutionNote: this was a design exercise, I put my best effort forth with all that I knew at the time. That said, at a high-level, for Overdue tasks: break out the list into groupings based on their Category. Plus, add in bulk editing of tasks, giving the user a quick way to dismiss loads of tasks that are not critical, or might be long gone. You can also bulk update (i.e. adjust due dates, assingees, etc.) loads of tasks at the same time. Any time you add bulk editing for actions, you also need to add in undo support for these as well. Supporting mistakes in UI is critical to reducing anxiety around updating tasks. Along with these new additions to the overall system, I wanted to add in a Deleted view to allow for more power user support.

I also introduced a new concept of Ongoing tasks. This type of task can cover a lot things: at it’s most basic it’s for tasks that are important for the user to eventually get done, but not priority enough to assign a due-date to it (or after it’s been languishing as Overdue). Or, they are tasks the re-occur on some basis.

Finally, I also wanted to introduce the concept of Task Capacity. This concept would help to alert the logged-in user, as well as their superiors, about their actual workload based on what is assigned to them. Having a measurable way to see their capacity feels like it could be really effective in reducing burnout or frustration, as well as for bubbling up workloads.

I was offered the job @ Highrise, but I decided to stay local. Thus, my efforts were very well received by the team. 😃

What I didI researched, iterated, designed and built the front-end for this prototype.

Misc. from Tradesy

The ProblemGetting help on a website can be overwhelming, and often is an afterthought from a design standpoint. At Tradesy, we knew that our current solution (like so many others) was lacking, as well as it was actually creating a bottle neck for our Member Care Team.

Our SolutionWe focussed on designing & building a solution that freed up our Member Care agents to help out our members who really had large issues, and to allow our members with small issues to get the help they needed by themselves, and thus get back to more important things in their lives.

Using Zendesk’s API, we pulled all the content onto our site to create a seamless experience for our members on tradesy.com. If a member is logged in, we can better tailor the types of suggested articles to help them, as well as if they need to contact us, we automatically pass over all the necessary data to our Member Care team without the member needing to do or provide anything else.

We also designed and built a new “short answer” concept that we are truly proud of. A member who has an issue drills down from the new Help homepage into a chosen category, and gets to a list of questions relating to their issue. Inside each question, is a summary of the question (i.e. the short answer), that should be salient enough to answer 99% of our users issues. If it’s not, then they can read the full article, or they can then contact us.

What I didI designed and built the front-end, and integrated the API code necessary for this.

The ProblemFiltering to the right set of products on an eCommerce site is so paramount to a shoppers success, and we’ve known for a while our current filters don’t cut it. There is no way to bulk apply filters: each filter you applied reloads the page. This leads to mass user frustration, and less satisfaction with the results of using our filters. The current filters also lack large, easy tap targets, and suffer from poor UX in general (i.e. using them is confusing and unpredictable).

Our SolutionWe set out to build more intuitive, and more predictable filters to help our members find what they wanted to. The result (not in production yet, but in user-testing) has proven to do just what we wanted it to—it’s allowed our users to, in a stable manner, filter down to the right set of items quicker and easier.

Along with making the filtering process itself more intuitive, we also looked at the types of filters we have, their existing usage data (to help inform ordering), and how we could improve upon the types of filters available for a given result set.

What I didI designed and built the prototype, and ran user-testing sessions.

The ProblemStart-ups struggle to generate extra revene outside of their original business models. For large marketplaces, it’s common to eventually introduce ways for sellers willing to spend a bit more, to get more out of the marketplace. We felt that in 2016, given our current size, scale and traffic of daily sellers, it was the rigth time for us to do this with Promoted Listings.

Our SolutionStill in development, we’ve put a lot of thought and effort into designing an advertising system that would help all our sellers succeed. On Tradesy, we have all types of sellers: pro-sellers, power sellers, and casual sellers. We wanted to build something that all our sellers, if they chose to participate in, could find success with.

What I didAn ongoing effort that I researched and worked on initial designs / front-end builds for.

Transactional Email Standards

The ProblemEmail, even in 2016, is still so important to a business. Transactional emails are often overlooked, or are considered outside the normal scope of design standards. From inconsistent type treatments, random item cards, to different footers; we needed a holistic approach to bring our email branding full circle.

Our SolutionWe started by looking at our two main member flows: buying an item and selling an item. From this we were able to identify all the types of modules that could be used in a transactional. We chose to use system fonts so that we could allow the operating system to best optimize these (even in 2016 custom fonts in emails are not very well supported). We then moved all content to a single column format, to allow for easiest readability and maintenance of the templates.

These emails work and look great in all clients: Outlook, Gmail (yes, even Gmail for mobile), and everywhere in-between.

What I didAn ongoing effort that I researched and worked on initial designs / front-end builds for. I also built and tested the template for proper support in all major email clients.

Some mini-projects

Yak app

A friend and I were tired of not really knowing how to get good ideas of what next to read, binge watch, etc. So we decided to do something about.

Meet yak: an iOS app where you can get reviews of books, TV shows, movies and music from friends that help you find what to love next.

What I did:Wireframes and design.

Coming soon to iOS.

Tradesy Mobile Improvements

Death to the 🍔.

Used on over 4.6 million visits since we released in August 2015. I killed the off-canvas menu, and simplified the navigation for our mobile users. The result: increased engagement, but more importantly, conversions.

I built a custom registration and login screen to do away with modal windows. These are much more stable and predictable; and lead to better form completion. For the most part, this entaled only chrome edits.

Update: I added a new view for accessing your account management, as well as a new view for in-app notifications. Tablet web is also fully supported now, as well.

LeagueApps Mobile Framework

📱 FTW.

Update: now serving 7-8 million uniques per month on mobile alone.

The LeagueApps platform served over 16 million views in 2014, and 8 million of them were on a mobile device. So, we optimized the templates and assets to give their mobile users the best possible experience.

I also built a custom mobile eCommerce feature which allows members to purchase product(s) associated with that program.

LeagueApps Email Templates

In 2014, we’ve sent over 2.5 million emails.

These are all automated, or notification–based emails, but they contain important information for our customers customers (i.e. the game participants). So, having them look right in all programs was uber important. And, we nailed it. These work in Outlook, Gmail, and everywhere else.

Dads’n’Shows

Listenin’ to

We all have our favorite bands, right? But who are our favorite bands: favorite bands? Inspired by my passion for music, and the bands I love. I wanted to not only share those bands with others, but also get to know bands that inspire them, as well as bands they might be currently digging. Also built & run on Github Pages.

Littleonce app

Capture your child’s moments everyday, and share them with only who you want to. Littleonce is a simple, secure, fun daily journaling app for your child. Just take a photo, add a description to preserve the memories forever, and post it; that’s all. A Ruby on Rails app, I designed and built the UI & front-end, and did a fair amount of the Rails work, with a bit o’ help from a friend.

Available on: iOS, Android, Windows, Web

Playsomethin’ app

The simple, fun way to find local sports leagues. With new members registering each day, this is the easiest way to find all the best sports leagues near you whenever you want. Powered by Scala, I designed and built the UI & front-end.

Available on: iOS, Android, Windows, Web

imgRszr app

A simple way for non-tech savvy folk to resize and optimize images for use on the web. A Ruby on Rails app, I designed and built the UI & front-end, and did most of the Rails work.

Submitted on May 17, 2017

I am sharing a recent design challenge I was given for a possible role: update the pricing page. I had a week to complete and deliver my solution. I wanted to focus on three things: increasing conversions, adding a new price point, addressing pricing more holistically for new users.

Submitted on April 22, 2017

I am sharing a recent design challenge I was given for a possible role: design an ATM for kids. I had 3 days to complete and deliver my solution. I specifically wanted to shy away from almost any visuals, and focus solely on the concept and the story.

Mused on October 15, 2015

Continuing in our updates to mobile web traffic for Tradesy.com, along with our navigation updates, we killed modals for mobile visitors. Again, as many web sites often do, we used (& still do) modals a lot. Like A LOT. But for our mobile web visitors, it was just a very awkward, unpleasant experience.

Mused on October 15, 2015

Everyone knows that mobile traffic has surpassed desktop traffic; especially when it comes to eCommerce. In 2015, Tradesy.com’s traffic experienced the same pivotal moment in April. Our current website was built like many other websites: responsive to work across all browser widths. This also meant that, like many other sites, we had a 🍔 menu. There have been many studies done on whether the hamburger menu works or not, but internally, we knew the hamburger was a bad solution to a complicated problem.

Mused on February 18, 2015

The title kinda says it all: Don't lose focus. Either of what you want your users to do on your site, but more specifically, don't lose the oft forgotten pseudo styling for interactions. CSS resets are great, but often times you'll reset default browser styling that, unless properly redefined, is critical to helping your users when interacting with any type of website.

Mused on February 16, 2015

We designers are trying our damndest to kill the web. And we've been doing it since web design became a thing. Think about this: the responsive web is something we had to make because we broke it. The web, in its very own nature is responsive.

Mused on March 20, 2014

Mused on March 11, 2014

Seriously, fuck ’em. They have no place in professional design, and definitely not in web design. Why would they? They pay no attention to the specifics of the project at hand, nor those affected by said project.

Mused on June 12, 2013

We've been doing it wrong since the beginning. And no, I'm not referring to life in general, though the argument could be made for that. I'm more referring to what we deliver to clients in the design phase, and what they end up getting in the prototyping / development / deliverable phases.

Mused on April 29, 2013

Developers everywhere fear older versions of IE, its's a fact, and it's a fact for good reason. Supporting IE 8, 7 and possibly even 6 makes building the web unfun. But, for some business verticals and clients, it's a necessity, as for some of them, their users still traverse the web with these older, archaic browsers. And, there is not much we can do about this, outside of a few hacky-type things.

Mused on March 16, 2013

Somewhere recently I’ve noticed a disturbing trend: services like Spotify, Rdio and the like, are not as wonderful for the artist as the public assumes. At least, a trend in as much as the information has been presented in these articles. First, a disclaimer—I use, and have used Spotify for as long as it’s been available in the US.

Mused on March 07, 2013

I'm probably weird, but I want no images. Not only for page speed reasons, or for retina/non-retina reasons; but for the simple fact that getting images right is very hard. And, unfortunately, very often we get them wrong.

Mused on February 27, 2013

Yep, it is hard. It's not just I don't like green. Or it's not just that looks cheap. And it's definitely not ’It needs to pop more’. It takes practice, of a sort. It takes practice after you build a solid foundation of understanding design principles. It's just like any other profession; we should not jump to conclusions about something we don't really understand.

Mused on February 25, 2013

While working on a recent project, I (re-)discovered the issue of client misunderstandings and perceptions of browsers and rendering. While a lot of people have talked about this, and tweeted about it, and mentioned that this is part of what we do, it's not where it needs to be yet. I don't know what the actual solution is to bridging the gap, but I'll run through some scenarios and how I might handle them.

Mused on February 20, 2013

Everyone knows responsive web design (henceforth RWD). Well, people in the web industry, and those working closely with web folk; they pretty much all know what that term implies. And they all probably have their own opinions about whether it's good or bad, or at least going in the right direction. But what about responsive email design?

Mused on February 19, 2013

I recently updated my site to use Jekyll, markdown, and Unicode icons. There are, of course, still some images, but only as necessary. Portfolio samples and 4 header images to give the site some character. However, I decided to dump a lot of tiny details in buttons and whatnot in favor of just focussing on content, and speed. The images I do use are pretty well optimized, but being that they are portfolio pieces, there's only so small I was willing to go.

Mused on February 11, 2013

This is something I don't do often enough for sure. Some of this is laziness, but some of it is just budget constraint. But this is one of the most important parts of creating success; whether you're building a new product or working on a client project.