Jordan Koschei jordan koschei

Design + Code

My Interview on Interface Lovers

Jordan Koschei on Interface Lovers

Interface Lovers is an online publication that interviews product designers about who they are and what they do. It’s enlightening to hear how other designers got into their roles and learn about how they work, and I was flattered when they reached out to interview me.

I’ve changed jobs since I gave this interview, so a lot has changed, but this will give you some insight into my design philosophy and outlook.

Bonus: They ask every designer for some music recommendations, so I’m happy to say that you can now find some sweet worktunes at Designer Mix #140 — Jordan Koschei on Spotify.

My Interview on User League

Jordan Koschei on User League

I was interviewed for User League, a new online publication from Dave Martin, principal designer at Automattic.

This quote sums up what I believe about design:

I like to think of design as a form of hospitality — we’re creating digital environments in which our users will live for a time. Those environments should make our users feel comfortable and confident, and enable them to do things they couldn’t otherwise do. A good product gives the user superpowers without drawing too much attention to itself. It’s better to leave the user thinking, “Hey, I’m awesome” than “Hey, that product’s awesome.”

Thanks, Dave! Head over to User League to read the full interview.

An Anecdote on the Importance of UX Research

“Can you make sure they add sounds to the next version?”

I’m standing in an aisle of a Wal-Mart in suburban Florida, scrambling to open up my notebook as the rest of my team walks out the door onto the bus. I’m still not entirely sure what’s going on, but the guy in front of me looks frustrated, so I’m pretty sure he’s about to tell me something valuable.

It’s the end of 2015; I’m doing UX work at a small agency, mostly for Fortune 500s who are trying to make their internal tools a little less horrible to use. On this project, I’m traveling around the country with a small team, shadowing merchandisers from a brand-name consumer-goods company as they drive to different stores and stock the shelves with their product. It’s just me, my project manager, and three consultants from a gigantic consulting company.

We’ve just finished shadowing this particular merchandiser and are getting ready to leave for our next stop. I’m the last one out of the aisle, and the merchandiser we’ve been observing pulls me aside.

“I’m not sure if you can do anything about this, but I’m having an issue with our new app, and I think other people have been having an issue too.”

Read More →

Building My First Solo iOS App

Working on Interlude in Xcode

TL;DR — I’m building an iPhone app called Interlude, using the knowledge of Swift I’ve gained by working at Dwell. It’s a small project that will give me the chance to build something start-to-finish, rather than just editing an existing codebase, so I’ll learn more about the overall native development ecosystem.

Read More →

Design is a Form of Hospitality

Design is a form of hospitality.

Done well, design should be welcoming. It should invite users into the world it creates, making them feel at home. This is true for websites, apps, books, posters, album covers — you name it.

Most design is about reducing friction: reducing the friction to find information, to connect with friends, to share your thoughts, to consume more content. Reducing friction is a form of hospitality.

Not all design is meant to reduce friction, of course. If you’re designing an interface for a missile defense system, you probably want to increase the friction around hitting the big red button. Making people feel comfortable — giving them appropriate guardrails that reduce the fear of making mistakes — is a form of hospitality.

Making users feel like they know what they’re doing is a form of hospitality.

Giving users a pleasant place to spend their time is a form of hospitality.

Making tasks easier so users can get back to their real lives — their homes and hobbies and families — is a form of hospitality.

Creating mechanisms that deliberately addict your users is not hospitable.

Luring your users into behaviors for the sole purpose of generating data that you sell to third parties is not hospitable.

Purposely obfuscating the way your product makes money is not hospitable. Purposely obfuscating the meaning of your privacy policy is not hospitable.

Transparently providing a service and charging for it is hospitable.

This is why hotels are hospitable in a way that casinos are not.

Let’s seek to design hotels, not casinos.

Finding an iOS Mobile Safari CSS Bug: rgba() with CSS variables in box-shadow

Right after launching the latest update to this website, I caught a mysterious visual glitch — link underlines, which are supposed to be pink in most places, were showing up black in Mobile Safari.

iOS Mobile Safari Box-Shadow RGBA CSS Variable Bug
On the left, links in the content are underlined black. On the right, they're underlined properly with transparent pink. Nav links in the header are unaffected because those underlines are pseudo-elements with transparent backgrounds, and don't use box-shadows at all.

To achieve the accent color link underlines throughout the site, I set text-decoration: none and fake the underlines with an inset box-shadow:

box-shadow: inset 0 -2px 0 rgba(var(--brand-color), 0.5)

This works fine on Chrome, Safari, and Firefox, but on Mobile Safari it shows as straight black.

Why CSS variables?

Some background: I recently added the ability to change the accent color on specific pages of the site. On different case studies, for example, the accent color changes to match the brand of the project being discussed.

I do this by setting a variable in the front-matter of each piece of content, with the default set to the site’s brand color in config.yml. I turn this into a CSS variable in the <head> of each page.

Since I need to change the transparency of that color, I don’t store it as a hex value; I store it as RGB values, so I can use it as the first argument of rgba(), like so:

rgba(var(--brand-color), 0.5)

Finding the Solution

Some quick sleuthing shows that I’m not the first person to run into this issue — there’s a question on Stack Overflow describing the exact same thing.

The accepted answer suggests that we can fix this by making a CSS variable out of the full string of box-shadow arguments, like so:

:root {
    --color: 130, 16, 253;
    --shadowColor: 0px 10px 50px 0px rgba(var(--color), 0.08);
}

I needed transparent accent colors in more places than just box-shadows, though, so I followed the suggestion in one of the unaccepted answers instead, and made separate variables for each of the opacities I use throughout the site:

<head>
  
  ...

  <style>
    :root {
      --brand-color: rgba(194,55,97, 1);
      --brand-color-point97: rgba(194,55,97, .97);
      --brand-color-point9: rgba(194,55,97, .9);
      --brand-color-point5: rgba(194,55,97, .5);
    }
  </style>
</head>

Sure enough, this works! Now the box-shadows render properly on Mobile Safari as well as elsewhere.

It’s not as elegant as my first implementation, but hey, that’s front-end development. If it works, it works.

Apps, Stop Infantilizing Your Users

I’m getting tired of that cutesy, flat-shaded, CalArts-style aesthetic that so many apps seem to have adopted.

Headspace Website
This is the homepage for Headspace, a meditation app designed for adult humans.
Duolingo App Store Page
Duolingo is a great app. This character looks like it came from a startup promo video with ukelele music in the background.

These feel just a few steps removed from Clippy to me. Am I just getting cranky in my old age, or are there a lot of apps that infantilize their users, as if we wouldn’t be interested in a product if it didn’t look like it was designed for toddlers?

The Generosity of Making

For is there any practice less selfish, any labor less alienated, any time less wasted, than preparing something delicious and nourishing for people you love?

Michael Pollan, Cooked: A Natural History of Transformation

This quote is about making food, but I think it goes for making anything: artwork, music, or even an app.

It’s easy to get caught up in the abstract side of what we do, but it’s so important to remember that behind every email answered, line of code committed, and pixel pushed are the people we’re doing it for.

Asking the Right Questions

So much of my design career has hinged on writing. My first real exposure in the design industry came from writing opinion pieces for The Industry; my first job in a design agency came after the CEO read something I wrote and asked if I’d be willing to sit down and talk.

I’ve been writing less lately, since product work takes up most of my day and I jealously guard my personal time otherwise, but it feels good to see something I wrote in-the-wild occasionally.

You can read the post here: Are You Asking the Right Questions?

Designing for designers is like cooking for chefs

I like reading books written by chefs and food critics. One common theme is that they bemoan what happens to their social lives — nobody wants to cook for a famous chef or critic, so the dinner party invitations dry up. Who’s going to cook a meatloaf for Ruth Reichl?

On the other hand, chefs and food critics have sophisticated palates, so a chef cooking for other chefs can take risks they couldn’t when cooking for a general audience. That’s the tradeoff — more risk of criticism, but more possibility for appreciation.

So it is with designing for designers:

Pro: You can get away with things when designing for designers that you couldn’t otherwise. You can assume that your audience has nice Retina displays and powerful GPUs that can handle all the hairline typography and parallax scrolling you can throw at them. You know they’re using a standards-compliant browser — no IE7 here — and it’s likely they’re on a Mac or an iPhone.

You can assume your audience knows what common icons mean without including explainer text — not a safe assumption for a general audience — and that they’ll understand UI shortcuts like the hamburger icon and share button.

You can afford to experiment, since your audience is more likely to be intrigued than turned off by strange layouts and weird effects. Assuming we’re talking about a website, they’ll probably stick around long enough to try to figure out how you implemented anything too far outside the mainstream.

Con: Your audience will notice every out-of-place pixel, every less-than-ideal interaction, and every decision you punted on. Designers can’t turn it off – it just happens. Your audience will notice the minutia about your type choices, color choices, layout choices. Things that would pass with a general audience won’t slide with designers.

(On the other hand, designers will sympathize with other designers, so while they’re more likely to notice errors they’re less likely to be abrasive about… oh, who am I kidding. Designers love to nitpick each others’ work.)