No Offense but… F*ck Sketch

Chris Feix
3 min readJan 24, 2017

I’ve been designing Photoshop, PowerPoint, paper, and HTML prototypes for two decades now. Wire frames (or is it wireframes?), card sorting, mock-ups, style guides… they are all good ways to build/redesign a product. But if you want to truly be as proficient as possible, just skip all the bullshit and get to building.

Courtesy of Nina Wei

Sketch

When I first dabbled in Sketch, it was a new guy that introduced it to me. Sometimes when you’re asshole deep in projects you don’t get to experiment with new tools. You use the ones that you know work and get to fucking work.

But this guy was new, not yet feeling the heat that runs down your neck when you’re 2 months past your launch date. He was really proud of his newfound toy and wanted to share its hipness with the group.

I immediately fell in love with it; but wasn’t going to learn something new… that was a young man’s game. At this point I was a conductor of a great design/development symphony. Conductors don’t jump on the sousaphone and blow out solos.

Photoshop Replacement

I’m not going to go into all the great reasons you should replace Photoshop with Sketch, Google it. What I will say is three things:

  • wire frames are productive
  • user testing is productive
  • mock-ups are for selling, not building

Let’s be honest, when has your product ever looked like the mock-up by the time you’re launching?

Stop Screwing Around and Build the Damn Thing

Like I said before, I’ve been doing this for decades now. It wasn’t until a few years ago when I started my own business that I started tracking productivity. Here’s what I found…

Obviously you start every process with things like, napkin drawings, maybe a wire frame or two, competitive (if there are any competitors) analysis, etc. But when I started the design/development stage with mock-ups, I was less likely to thrill my client and way less likely to launch quickly.

3 out of the 4 projects that fell both above the happiness average and the below the launch time average were HTML prototypes using an existing foundation.

Foundations

A few words on foundations (Bootstrap, Material Design, Foundation, etc.)

I’ve never used an entire foundation; so I end up taking a lot of time to strip out the bulky JS & CSS that’s not being used, but being loaded… ugh. I have a nifty workaround for this; but that’s for a later article.

I’ve always added brand promise to my foundations. Basically this means when you look at my products, for the most part it’s impossible for users to tell it’s based on a foundation. They look hand crafted. This also takes time.

Foundations use common interface parts. There will come a time when you need to build one from scratch; but 99% of your parts are taken care of. This saves time.

NO ONE KNOWS IF A PRODUCT WILL BE USED UNTIL PEOPLE USE IT.

It doesn’t matter if you did focus groups, prototype testing, monitored testing, demos, got VC money shoved up your ass — until you put at least a beta product in the marketplace, you’ll never know if it’s a viable, lovable, worthy product. Getting it out there as responsibly fast as possible is the key to success.

Fucking Developers

Using a foundation to start the design process allows you to actually click around (like Axure, Balsamiq, etc.). It also allows you to immediately hand over HTML/CSS/JS to the developers.

This is where the budget gets gobbled up in traditional projects. Everyone knows these guys are playing WOW for 4.25 hours a day. That’s why they sit with their backs to the wall. †

Don’t give them a reason to start “designing” too. Hand them the CSS and they’ll use it. I promise.

Please tell me I’m not the only person that thinks this way. Feel free to share below…

You know I’m only teasing you. I love developers. Peace and love.

--

--

Chris Feix

Entrepre-holic. UX & Business Strategist. Coined several obscure memes.