The 5 Stages of Design

I'm a terrible designer. Hell, I'm not a designer at all. I can usually tell when a UX is good or bad, and I know what I like, but when it comes to producing designs, I'm useless. My only saving grace is that I know that and let others do the pretty.

Sometimes, though, it's easier to explain something with a picture than a bunch of words. So I bust out the Paint.NET and try to line things up well enough the idea is conveyed, but sloppily enough it's obviously not a final mockup.

In my early days at Crunched it took a few interesting conversations to get that process fine-tuned to work with our designer. I was unaware of the torment I was putting her through. Now we've agreed that...

• this is not my job
• it's still ok and moderately useful for me to do graphics every so often to convey an idea
• it's ok to laugh at them

Inevitably, though, when I present my "work", there's some trepidation about what horrors will be shown, and (legitimate) questions about whether what is seen can ever be unseen, etcetera. So today we identified the five stages of design:

1. Denial. (e.g. "WTF IS THIS or YOU CAN'T BE SERIOUS")
2. Grief (e.g. "MY EYES!!!!!!!!")
3. Mockery (e.g. "LOL")
4. Acceptance (e.g. "Ok, I see what you're trying to do here")
5. Improvement (e.g. "I'll make it pretty")

I wonder how common this is for designers.

A year and a half: a look back

It's been almost 18 months since I was thrown into the fast and furious team at Crunched and I thought I'd lay out all the many, many things I've learned.

Technology

I was originally hired to run the product side of the organization for our nascent online meeting platform. Feature development, user feedback, market research, usability, that sort of thing. As a long-time engineer, I also dabbled in some of the tech, but from the outside looking in. Part of it was my lack of familiarity with the whole stack (Ruby on Rails, node.js, CoffeeScript and a bunch of other things I hadn't used in my LAMP / Java / Windows past), and part of it was a very clear, if passive-aggressive, intimation that my tech input was not up to snuff and/or not welcome here. A few months into it, though, I inherited the whole engineering team and I had to get up to speed fast.

I'm still not completely up to speed, at least not nearly as much as I'd want to be, and definitely not when it comes to the subtleties of the front-end code (which I don't really want to deal with anyway, because browser development will make you mad). But I have learned a few things. Here are some thoughts, in no particular order.

• Github is one of the best programming tools I have ever used. The initial setup is awkward, and account/organization management sucks, but the stuff that matters is pretty damn amazing. 9/10
• Git is a lot better than svn and miles ahead of cvs. It lets you do a lot of things that are very difficult, cumbersome, error-prone, and/or impossible with those other systems. Its user interface, however, is  abysmal, its man pages are completely unintelligible, and it's a bad tool in the sense that it makes it 1) extremely easy to shoot yourself in the foot and 2) very hard to recover from said shooting. That said, once you get over the nomenclature and into a good branching hygiene groove, it's great and I wouldn't go back. 7/10.
• Trello is the best, hands-down, project management system I've used. It's not perfect, and they ship bugs almost as often as new features, but it's free (for now) and the pros outweigh the cons by a lot. Brilliant stuff. 9/10.
• Pivotal Tracker, on the other hand, is horrible. The real-time updates are great, but its nomenclature is all wrong, it forces you into one dogmatic workflow, it's very noisy, the UI is backwards (progress is bottom to top, right to left) and it does way too much stuff magically without letting you change it (e.g. you can't reorder "done" stories, which makes it hard to package release notes). I'd rather use bugzilla and sticky notes. 1/10. 
• ZenDesk may be great for customer service, but we used it as a bug tracker, and for that it sucks. The UI needs a lot of work--search isn't very good and most of the defaults are counterintuitive. I won't grade it because we didn't give it a chance to shine, but if you're thinking of using ZenDesk for bug tracking, DON'T.
• Ruby (the language) is becoming my favorite. The syntax is very expressive, and there's a bazillion libraries out there to do pretty much anything you want. It's a little slow and changes between versions are a little abrupt, but I still give it a 9/10 because it's so close to ideal in so many ways. And I'm still barely functionally literate in it. 
• Ruby (the tech ecosystem) is a mixed bag. The availability of gems is great, but package management is all over the place, and rvm is a plague upon the world. It's an awful solution to a self-inflicted straw man of a problem. 6/10.
• Ruby (the human ecosystem) is about the same. Some folks are really great (my team, Avdi, JEGII, and many others) but there's a lot of vehemently vocal douchebags and dogmatic tunnel-vision idiots who think reinventing the wheel in Ruby is a necessary endeavor because anything written in non-Ruby is by definition lame. There's also a dangerous enthusiasm for hacking all the things !!! and trying out lots of different new technologies just for the hell of it when some of us would like to actually deliver stable product and tangible value to customers rather than jack off to the shiny new DSL for generating a/b-testable webforms with automatic conversion tracking in the Rails-powered real-time analytics SaaS startup of your choice. Because who gives a flying fuck? Developers need to remember they are not their customer, by and large (unless they make a living writing tools) 6 5/10.
• Rails is clever, and was once pretty revolutionary, but now it's mostly annoying. It's headed up by an insufferable douchebag, it's bloated, it does way too much automagically, and it's almost impossible to know what the hell is actually going on in your app without a cadre of equally bloated tools and a divining rod.  The result is a bunch of mollycoddled self-centered Rails devs who have no clue about anything yet feel strangely superior and entitled to inflicting their opinions on everyone and dismissing valid questions or criticism with hackneyed dogmatic mindless hand-waving catchphrases, like zombified Moonies on Ambien, so self-obsessed they forget their primary duty is not to their own comfort as developers but to their apps' users, who ultimately pay their salaries and their Apple tithe. (note that vast hordes of LAMP devs are equally clueless and write even worse code, but at least they don't have the attitude). But every other blog post / tweet about Rails feels like a massive circle jerk and my brain needs a shower after reading them. Thankfully my team is pretty much the opposite of that attitude.

Aside: my main problem with Rails and its brainwashed proselytes is that their catchphrase, "Web development that doesn't hurt", is a false promise that misses the point. 

• It's a false promise because the painful part of web development is client-side, not server-side. Sure, Rails is integrated with front-end stuff, and its proponents are embracing tech that addresses that pain (SASS, jquery, or irresponsibly pointless and counterproductive Ruby-fanboyesque exercises like CoffeeScript), those technologies aren't Rails, and Rails' real claim to fame is for the server-side stuff--ORM, keeping business logic out of the front-end, etc. You don't need a J2EE-like behemoth of a framework to let you crank out quality, maintainable MVC stuff. You can do that in C/cgi, PHP, perl, python, .NET, whatever. All you need is a few basic libraries and decent software development skills.  
• It misses the point because every worthwhile web application lives way beyond the web layer. There's reporting and business intelligence, APIs, and lots of other things your business needs to run. Sure, you can do BI and analytics in Rails, but once you have sizable data sets you just can't anymore, and you have to either rip your web app apart or duplicate the Rails business logic in some other language to process the data that's modeled and mapped so tightly to your web-specific code. From that perspective, Rails is not nearly the step forward people claim it is, because while it (sort of) forces you to keep the business logic out of your views, your business objects are still very closely coupled with your front-end application, and if you're lucky enough to get scale, you're just as screwed with your Rails app as you were with your [other tech]-powered web app and Rails doesn't help you one bit. Of course I know you can write SOA and RESTful APIs in Rails, but if that's your counterargument then I urge you to re-read this last paragraph because you missed the point entirely.
• Lastly, Rails has made it a badge of honor and dev cred to be an opinionated dogmatic dick. And that's not forgivable.

So 3/10 for Rails.

• Sinatra is neat. Lightweight. Quick. Simple. The anti-Rails. If Ruby had become popular with through Sinatra and Sequel 7 years ago I probably would have jumped ship from LAMP back then.
• CoffeeScript. My lead engineer likes it a lot, and I have a lot of respect for him, because he's a brilliant tech mind. But for the life of me I do not understand the point of CoffeeScript, which is a Ruby-like wrapper for JavaScript. All it does is 1) add a step between you and gratification (compilation to JS) and 2) make debugging harder because the JS line numbers (which are what your browser tells you about) don't map to your CoffeeScript line numbers. The Ruby fetishism is singular and a little weird/creepy. It's not like JavaScript is hard. 1/10.
• Cloud hosting, by and large, beats owning, installing and maintaining your own hardware with a stick. This is my first gig with zero owned or leased physical server infrastructure, and it's not as bad or scary as it sounds. But not EngineYard. EngineYard is not for professional development. Their out-of-the-box database options are pathetic (MySQL 5.0 by default, and no support for failover), and they don't seem to grasp that professional web applications require automation--there's no API to add instances to your cluster (or remove them), so a human has to do it by hand in their web UI when you need scale; there's also no API to pull database backups in case you want to run automatic BI analytics on your own data outside of your production cluster and you have to do unspeakable hacks to pull those backups by script. I've also heard sometimes their backups quit running with no warning. Their email alerts routinely get sent 10+ minutes after the problem is resolved. And for a while their default setup wouldn't automatically run chef when you removed instances from your web cluster, leading to your LB sending traffic to instances you no longer owned, with hilarious results (I hear they finally fixed that). And they're expensive. So do yourself a favor and go straight to AWS unless you truly have no idea how to set up a basic web cluster, in which case you need to get help from someone who does, and that's not EngineYard. 8/10 for cloud/AWS, 4/10 for EY.

Update: Things I forgot

• Airbrake. It's a crowd favorite for catching app errors. It's also nearly completely useless, because there's no search and only rudimentary filtering, and you can't download full sets of errors for analytics. And it has cutesy relative timestamps ("A few minutes ago"). It feels like a product built by people who have never actually used that kind of product. If you're building an error log, the two most important things you need are exact timestamps (to correlate the log entry with an action or bug report) and the ability to grep, sort, count and do other basic things. Airbrake fails on those two absolutely elementary features. So I give it a 1/10 because I'm feeling generous.

Fund Raising and Venture Capitalists

My first tech job was self-funded and/or mostly profitable and it wasn't until the next job that I became aware of the venture capital industry. The past year has been rather interesting on that front and I'll summarize what I learned in a later post.

Remote Teams Are Awesome

A lot of people wonder how or whether we can make it work at Crunched with a fully distributed team. We have people all over: Georgia, South Carolina, Michigan, Canada, Seattle, New York, and Los Angeles. The product team does not have an office. We meet in person a couple of times a year (I'd like to do that more often). We're in Campfire and on Skype all the time. It works. Sure, it's not perfect, but I'll take this over the bullshit productivity- and morale-killing super-bright very loud open-floor-plan startup office you see all over San Francisco. Of course it's the team that makes it work, and my team is awesome. I'll write more about this later as well.

A new infographic

Infographics are very trendy. I've been dealing in Big Data for a few years now and thought I'd share some of my findings and contribute to the art and science of data visualization. Here's my first infographic, which shows very clearly that big is highly preferable to small.

Add caption

DVR?

Comcast is aggressively pushing their DVR service. Their hold message says "if you want to record the Olympics, be sure to double-check the times, because they may change, so you'll have to reset your DVR."

I was scratching my head the whole time.

Why can't I just tell my computer "record all the javelin events" and have it do the work of recording the right thing at the right time, without my having to make changes?

Worse still, why do I have to record anything in the first place? Why not just let me pull any event I want whenever I want on my computer?

It's not like the technology to do all this isn't available already.

MVP, done, and working

Recently at SalesCrunch we had an interesting discussion of what MVP (minimum viable product), done and working means for our web application. Like all startups, we've run into growing pains with our app's feature set, reliability and performance, some self-inflicted and some external (Apple disabling Java by fiat and killing lots of functionality on the web overnight), and I wanted to reduce the non-productive frustration and tension we  often fall into ("the app is broken!") by pointing out that unless you define and agree on specifics, every participant will have different expectations. Different expectations are bad, so it's important to always make it clear what it means for a feature to be done and working--no assumptions.

So my main goal was to make sure every product build process includes an explicit conversation about what it means for that product to be done (i.e. it has all the features/use cases/user-error protection we want) and working (the SLA it needs to meet). That discussion must happen between all the people involved in the build--product, design, business, engineering, and maybe even the end-user (or at least the end-user should have a way to provide feedback so the company can adjust their criteria for "done" and "working" in case we got it wrong).

We got to a good place with that conversation, but it was a little abstract. Then I tried to make coffee, and was given a great real-world example of what the discussion and thought process could be.

I went to make espresso. Turned on the machine, put the cup under the espresso spout, and started the brew.

My cup promptly filled with high-pressure hot water, because I had forgotten to put the coffee basket in.

You may say "well that's dumb, the brew shouldn't be able to start if there's no brewing basket, since you're never gonna get coffee". That's what I thought, briefly.

But that requires an extra feature (a sensor or switch that blocks the brew switch if the basket is missing), meaning more moving parts, build and integration time, testing, higher costs, more expensive retail price, etc.

It's likely somebody at Mr Coffee had a conversation about this and decided a distracted/stupid/sleepy person forgetting to put the brew basket in before turning on the machine wasn't likely and/or dangerous enough to warrant the extra time, complexity and cost for a machine built for the sub-$100 price point.

Until this incident, I had no issues with the machine. Today, I used it, and didn't get coffee out of it. So one could argue the machine is not done (missing a sensor), or it's not working (it's allowed to function without producing coffee).

But does the machine work? Is it done? Until yesterday I had no issues with it. Today the circumstances have changed: I did something dumb I'd never done before, and had a failed coffee-making experience. So maybe my criteria for done and working have changed as a result: today I may decide to buy a different machine, looking for an error prevention feature. But the machine I have hasn't changed.

The main message here is:

1. don't assume done and working are defined the same for everyone
2. it's ok for done and working to change meaning with new circumstances
3. if those change, then the product needs to change in response to it
4. frustration, hand-wringing and pain can be avoided by being aware of 1-3 and not judging a product that was built on old done/working criteria against the new criteria

Personalize like it's 1995

This is what I see on Hulu when I'm not logged in:

And this is what I see when I am logged in:

Notice the difference? Me neither. I've never watched Cougar Town or any of the other shows on the home page. I never watch clips--only full-length episodes. And I only ever watch one show on Hulu--Law and Order SVU. Nothing else, ever. Personalizing my home page to my tastes would be completely trivial: just add a link to the last show I watched. They don't need a $1M recommendation algorithm to pull shows I may want to watch--just a list of shows I've watched in the past would be nice.

I wonder what Hulu's engagement metrics look like. I know every web site has priorities to juggle, and maybe recommendations aren't at the top of that list. But engagement and stickiness are crucial to all ad-supported sites, and especially media sites. So why isn't Hulu trying a little harder to get me to engage with their site by giving me ways to get to the shows I want?

Overloaded 404 part deux

I just noticed Backpack by 37Signals also 404s when you access a page you need to be logged in to view.

STOP THE MADNESS!

And of course, if I tell them it's bad UX, they're likely to tell me to go f*** myself.

This is why Apple wins, part II

Last night, I was enticed by an Android tablet edition of This Old House magazine, which is available free for print subscribers. I'm trying to ditch paper everywhere I can, and thought "yay!". So I set about getting This Old House for my tablet.

What I expected:

1. go to Android market
2. download This Old House app
3. install This Old House app
4. sign in with my print subscription info
5. read

What actually happened:

1. go to Android market
2. fail to find the This Old House app (WTF #1)
3. Google for "This Old House android app"
4. look at 2-3 search results and fail to find the This Old House app (WTF #2)
5. go to Amazon
6. find the This Old House app listing, which is free
7. look for a "download" link, to no avail (WTF #3)
8. find the "enter your email address and we'll send you a link to download the Amazon App Store" box (WTF #4)
9. enter my email address and wait
10. fail to receive email, go back to Amazon home page (WTF #5)
11. enter my email address again
12. view the Amazon App Store app install instruction
13. follow instructions (go to settings > applications > allow unknown sources) (WTF #6)
14. receive email and click link
15. download Amazon App Store app
16. install Amazon App Store app
17. find Amazon App Store app (no icon added to the home screen) (WTF #7)
18. sign in with my Amazon account
19. search for and fail to find the This Old House app (WTF #8)
20. load browser, go to This Old House web site, and find Android app ad
21. click Android app ad, read instructions and go to nextissue,  the This Old House app provider
22. find nextissue app download link and download
23. install nextissue app
24. find next issue app and start it (no icon added to the home screen) (WTF #9)
25. create nextissue account (WTF #10)
26. go back to This Old House site and enter my print subscription information to get free access to the Android app
27. create a This Old House account (WTF #11)
28. go back to nextissue app on my tablet
    
29. sign into nextissue app (WTF #12)
30. look for This Old House in nextissue app, to no avail (no search function) (WTF #13)
31. scroll through the available selections and finally find This Old House, next to last
32. tap This Old House
33. see This Old House listing and tap "install"
34. tap This Old House to run it (after install)
35. enter my print subscription information to allow free access to the magazine (WTF #14)
36. see latest issue and tap on it to download
37. wait for issue to download
38. wait for issue to install (WTF #15--why show me two progress bars, one for download, one for install? why do you have to install an issue? just show me one progress bar)
39. tap issue
40. read

I wish I were making this up.

I was not trying to circumvent anything, hack anything, jailbreak or root anything, or steal content. I was just trying to read This Old House on my tablet, after the magazine itself prompted me to try out its tablet app in an expensive full-page ad.

This Old House magazine: do you realize how much money you're wasting on an ad and an app that my gut says maybe 5% of eligible users can actually set up and use?

Design trends suck

How exactly is this trendy font effect cool, unless hard to read is cool?