Mar 3, 2011
In the March 2011 issue of San Francisco magazine, there's an article called “Field guide to cable cutters". The article discusses the fact that people are starting to rely solely on streaming internet services as a replacement to cable television. It outlined a bunch of use cases, including 3 (of 9) who reported that their setup did not rely solely on the internet.
That's two-thirds of the use cases that, amongst a variety of devices per case, report they've "cut the cord". For a reality check, I do realize that the Bay Area is filled with way more super-nerd early-adopters than most places. However, Bay Area or not, I do think it's worth noting that the change in behavior is happening at a significant enough rate to attract this much attention on a local level.
For me, I've been hearing people talk about doing this for a while now. From people who switch because it's much cheaper than cable to people who can pretty much afford anything doing it for whatever reason they choose – it's happening, and I couldn't disagree with it more.
Why? I love the guide channel.
I do. I really love the guide channel. The guide channel is my friend who helps me find something to watch. Depending on your cable provider, your friend may gift you a portion of your screen to keep you entertained while you browse, like mine does.
Sometimes hanging out with my friend is the best option, so we just chill together until something better comes along. What's better, my friend knows its purpose in my life is to help me find something better to do than hang out with it. It doesn't get bent out of shape when I leave because it knows I'll be back.
This is where Netflix, iTunes, Hulu, and all the others fail. They're not my friend. They're a vending machine that learns what I like so that each time I return, it's filled with more and more items that suit my taste. Don't get me wrong, I absolutely love Netflix and iTunes, but they're not a suitable replacement for cable television because they serve entirely different purposes.
When I get home, I usually watch TV for a little while just to relax. With the exception of Grey's Anatomy (don't judge), I don't follow any TV shows. I don't know what's on when and I don't care. What I want is a reasonable amount of choices, separated by category (ie. channel), prioritized by time.
Cable will continue to win my business until the companies that threaten to steal it start making it dead simple to casually watch something, right now. Every one of those companies has a huge amount of content, makes it relatively easy to find something you'd want to watch, and can get you from making a choice to being entertained in the time it takes to buffer the stream.
That's not good enough for me. To consider streaming services as a suitable replacement for cable, the gap between the two needs to be bridged much better. I need to be able to come home from work, put my bag down, turn on the TV and watch something without having to spend so much time thinking about what to watch. Otherwise it's often like when you spend so much time talking about where or what to eat, you lose your appetite.
Ultimately, it would take a streaming service to add these three things for me to seriously consider canceling my cable service and becoming completely reliant on the internet to fill the need:
Again, I am not saying don't use Netflix or iTunes or any other service like that. I use them. I love them, but not more than cable. Not yet, at least.
Feb 23, 2011
I've always thought that design portfolios don't tell stories well enough. If a portfolio is supposed to be a book of stories, most all of them are simply a collection of endings. I spent the last five or so years without any of my work online in any sort of organized fashion (which left a few companies thinking I was crazy for talking to them about work with no portfolio to show after I left Digg). When I recently rebuilt my blog, I included a work section. I wanted to use this section to tell stories via sketches, photos, anecdotes, as well as finished work — not simply present an array of finished products.
I launched the site with just enough work to convey my idea for a different kind of work presentation, but have also been (and will continue to) slowly backfill work as well. In order to keep the work section light at first glance, I decided to have certain entries link to a case-study-like story of a project. The first one I posted was simply a pictorial of most of my workspaces over the years. I recently posted my second one, the story of my work on the first Threadless Store in Chicago.
Jan 31, 2011
It occurred to me a while ago that I was pretty bored with my blog. Not with writing, but with the blog itself, and that was affecting my desire to write. Because I felt like I wanted to redesign the site, that somehow overtook my desire to blog. This may only make sense to me, but I needed a fresh place to re-inspire some creative thinking.
When Virb re-launched as a website service, I thought their pivot was really smart. I wanted to try them out, but at first, their offering didn't have everything I needed to switch. It was really clever for them to post their roadmap, so it was easy to keep up with their progress. That made it easy to decide when the time was right to move over.
This site is a bit "more site" than my last one. After I left Threadless, I realized I didn't have any of my work online. I talked to a few companies about work and had to tell some of them that I didn't maintain a portfolio. That was always an awkward conversation.
If portfolios tell stories, they're mostly a collection of endings. In putting this site together, I wanted to tell stories about projects. In the Work section, I'll share my thoughts, sketches, photos, and anything else that helps to present more than just conclusions (which I'll also show). I have a bunch of work to go through still, and I'll continue to backfill over time. The overall idea is to maintain a stream of in-progress and finished work.
I'll also be using my blog to share things I seen, heard, or read that inspire me, along with my own thoughts. This has been a long time coming, and I'm glad it's finally ready to share!
Dec 20, 2010
With 11 days left in the year, I feel pretty confident that nothing else will come out this year that would have made my list. Musically, it’s been an interesting year. I found myself getting really into more ambient music to work to, with a clear favorite emerging in Ludovico Einaudi. I discovered him on the This Is England soundtrack late last year and since then have become somewhat of a superfan. I’ve acquired literally every piece of music he’s published, including side projects. Kelly and I even flew to LA to see him perform live, one of the few US dates he performed after I missed his SF date in March in support of Nightbook while I was in Austin for SXSW. It was amazing.
This year I also found myself getting back into electronic music in a big way. I used to DJ, I’ve always loved beats, but this year I discovered dubstep, which has filled the void that super-dark techstep Drum n Bass left when it seemed like most everything good had gone away. Not much of that made this list because not many artists put outalbums, but there were a lot of tracks and remixes that owned my ears this year (like the one linked above).
Anyway, here’s my list of my 10 favorite albums of the year, in no particular order…
As I Lay Dying – The Powerless Rise
The Glitch Mob – Drink The Sea
Ludovico Einaudi – Nightbook
Pendulum – Immersion
UNKLE – Where Did The Night Fall
Skrillex – Scary Monsters & Nice Sprites
Torche – Songs For Singles
Deftones – Diamond Eyes
Dillinger Escape Plan – Option Paralysis
Triptykon – Eparistera Daimones
Looking forward to next year…
Jul 18, 2010
I rarely rant, but here we go...
Not to be a bastard naysayer, but the advice in Mashable's "How To: Score A Design Job" is so frustrating that if I facepalmed, I'd likely push my face through the back of my head. These types of articles have been written a thousand times. They always include the same advice and always provide zero context (ie. what type of design job/business is this advice suited for?). Nothing is more annoying than "rules" for up-and-coming designers on how many pieces to put in your portfolio, how many pages your resume should be, or what the content of your cover letter should be.
THERE IS NO RIGHT ANSWER.
I used to do portfolio review for graduating seniors at Columbia College in Chicago and almost every kid came in with the exact same set of questions. I'd tell them all the same thing: "Do you what you feel is right and treat each situation on an individual basis." Everyone else's opinion about what's right is based upon two things: (1) what they'd expect if they were hiring, or (2) what worked for them when they were hired – and yet they're always represented somehow as globally applicable, chiseled-in-stone fact.
This is my advice: Take all advice (including mine) with a huge grain of salt – what works for one person usually will not work for others. And a few pointers...
Put as much work in your book (online or off) as you feel best represents your skills, whether it's 10 or 100 pieces. Present what you're proud of. You get hired based upon the quality of your work, not a judgment of the quantity.
Put whatever you feel best represent your career path on your resume. Mine is 2 pages long. People who think it needs to fit on one page can kiss my ass. However, beyond some simple layout and type, don't design your resume. Seriously. Its purpose is to convey information, not your design skills. That's what your portfolio is for.
Cover letters are stupid. You're not being hired for your writing skills. Sometimes they're required, so in those cases, anything beyond "Hey, check out my work and let me know if you think there could be a fit" is a waste of time. There is nothing else you can say that will get you an interview if your work isn't worthy of one. Save your spiel for in-person when you'll be judged on whether you're a good cultural fit for a team. If a cover letter is required, think about the type of place that would require it, and consider whether you want to work there. Nothing says oil and water more than designers and formality.
Lastly, do whatever you want. Nothing is more miserable and uncomfortable than failing when you were only doing what someone else told you to do. The whole point of being a designer is to solve problems... you should be able to figure this stuff out on your own. And please, please, please when you do figure it out for yourself, don't fool yourself into thinking your solution is the solution.
Jul 6, 2010
They say hindsight is 20/20. They. They're right, the bastards. I always try to make decisions in the interest of never having to summons that awful cliché. I strive for foresight being 20/20, or at least as close as it can be. I even wear some pretty enormous glasses to help achieve that.
I've said before that I like to think of my attention split between the past and the future as the difference between the rear-view mirror and the windshield. Face forward, buckle up, glance behind you and go.
Unfortunately, this isn't completely a success story for that way of thinking because I, sometimes, can be a moron. This is the story of why I chose to work at SimpleGeo, and how I lost track of my foresight along the way (spoiler alert: I found it).
In August of 2009, after nearly 7 years of being at Threadless, my work life and my personal life had a very unclear divide. When I left that same month, suddenly the division between my work life and my personal life was very, very clear. Leaving Threadless kind of felt like losing a limb. As a guy who has actually lost body parts before, I won't lie, it was difficult.
I wasn't quite sure how to handle it, but I was pretty certain that the right thing to do was take a whole bunch of time off and move to SF to end the long-distance part of Kelly and my relationship. Friends, family and advisers all seemed to agree with this course of action.
Did I end up taking that time off? Of course not! Remember how I said I can sometimes be a moron? I did move to SF though. That was a step in the right direction. My free time was put on hold with the offer of joining Digg as their Director of Design & UX. I accepted and started just shy of 7 weeks after I left Threadless; the time in-between was eaten up by packing and moving.
Now, I know what you're thinking. "This is the part where he blames being laid off at Digg on it being a poor choice to be there in the first place". Not at all. I don't regret joining and helping to continue building a great team. Plus, I believed in the product and the problem we were all trying to solve together.
Digg was a comfortable place for me. I was given the freedom to come in guns-blazing on both design and some product, and they were in a place where it was advantageous for them to be evaluating all new ideas.
However after a couple months, something felt off. I did what I tend to do when I'm not 100% happy with where things are going: work until I'm happy. In the ~8 months I spent at Digg, I consistently worked 60+ hour weeks.
It was only after leaving Digg that it occurred to me what the problem was: I walked directly into a very similar situation to what I left at Threadless, only this time, I had absolutely nothing to do with how that company came to be or what it was. I was just an employee.
Fred Wilson recently wrote a really insightful blog post that, frankly, I wish he'd have written about 18 months ago. I found it to be particularly insightful because it was more or less about me (on the receiving end, in a general sense), save a few details: (1) I was not a founding member of Threadless, and (2) leaving was a mutual decision.
However, what Fred was able to articulate in 7 paragraphs gave me a lot of insight into what was likely happening at Threadless on the opposite side of my departure. It also helped me to understand why I felt more and more like the square peg in the round hole as the company grew.
Fred writes, "What works when you are five or ten people often does not work when you are fifty or more". When I started at Threadless, it was a handful of people. When I left, it was nearly 100. When I started at Digg, the team was roughly 75 (don't quote me on that, I'm just estimating).
I believe what Fred wrote about the type of people who are very effective in smaller groups but have a hard time scaling their effectiveness to very large groups. At this point in my career, I think that describes me pretty well (though I'm always working on it). Had I read Fred's post prior to interviewing at Digg, I wonder how my choices would have differed.
I think this is an important aside: Getting laid off was a blessing in disguise. I'd likely still be at Digg had I not gotten laid off. It wasn't until I had a decent chunk of time to clear my head and look at the rear-view and the windshield simultaneously and figure out what I wanted.
I think this is how people end up getting stuck doing something they don't like/want to do. It's very easy to focus on the tasks at hand, lose sight of the big picture, and leave very little time for self-reflection. The longer you remain that way, the more inconceivable it may seem to make the changes necessary to be truly happy with what you do. Believe me. I had entirely too much work to do to spend time thinking about what else I'd rather be doing.
After taking 3 months off from work, I realized what I wanted to do through a little side project work, a decent amount of interviewing with companies (big and small), and a whole lot of sitting on my ass contemplating the universe (read: playing video games).
This is what I came up with: I want to build companies, products and cultures from the ground up, and surround myself with amazing people who have amazing ideas. I want to be an integral part in the birth of innovative things. I don't need to be a founder, but I want to be early. Most importantly, I want to work with friends.
My time at Threadless has proven that culture is the core of the company. Culture creates friendships amongst you and your co-workers. By working with friends, you'll find teams will be more collaborative, feedback will be more honest, and the overall level of care and support across the company will be enormous.
For the above reasons... this is why I chose to work at SimpleGeo. Simply put, it feels like home.
Jun 22, 2010
This morning I was reading through Quora (which by the way, is totally awesome and they just launched publicly), and found this question: Should user interface designers be able to build what they design? This is a topic I'm pretty passionate about, as I feel that it's something that weighs on the minds of all young designers entering the field. Plus I tend to have an opposing view from a lot of people on this. I posted an answer to the thread, but then realized I basically wrote a blog post (I know, bad form) so I decided to post it here as well as it outlines my thoughts on the subject. The answer begins below...
I don't think it should be a requirement to be able to build what you design. That's about as silly as requiring an architect to know how to weld professionally. However, I doubt there's an architect out there who doesn't, at least, understand the concepts of how what they design is built (or maybe be able to tinker a little on the side).
The fact is this: being a designer and being a front-end engineer are two separate skill sets. If you're great at both – that's awesome. Pick one as your focus. In the 10+ years I've been in this industry, I've seen designers feel more and more pressure to learn how to code. The problem with this is that it ends up creating a whole lot of people who are mediocre at both because they weren't able to ever really focus on one.
Now, that isn't to say that you can't be an amazing designer and an amazing developer. There are many examples of people who are. However, if you look at the people who fit that bill, they very likely started with one, then pursued the other. I see so many kids coming up in this industry who spend more of their time trying to wrap their heads around JQuery than they do UX. Here's a tip: If you're better at JQuery than you are at UX you're a developer, not a designer.
This may seem like a convenient point of view coming from a designer who isn't a very good developer, however, I've purposely gone this path. Why? I've spent my career around passionate, talented developers who were more suited to tackle the work, which allowed me to focus on being a designer. And every minute I didn't spend writing code, I spent designing. I do have a baseline understanding of markup, and I can write some wonky-bordering-on-decent HTML & CSS, and that's ok. I don't get paid to do those things. They're a hobby.
Here's my caveat: all designers should understand what all applicable programming languages do to be able to effectively design for them.
I may not be able to write the code that will fuel what's going on in my head that I've laid down in Photoshop, but I sure know how to design for it. That's why I said "sorta" above. Going back to the architect example: If you're designing something to be built using steel vs. wood, your thought process goes in a different direction and you have different problems to solve. Without understanding the benefits and limitations of your materials, you're going to design something that will fall down.
In the end, it's important to understand that a great designer is a great problem solver, and hard problems are solved with great ideas. Not all designers have great ideas. In fact, most don't – and that outweighs the benefit of how fast they can learn HTML5, CSS3, or the ins and outs of the latest version of Adobe CS. I'm certainly not suggesting that someone with great ideas and a totally shit ability to execute on them in any fashion is a worthwhile hire, but a great designer is a great designer. Whatever else they happen to excel at should be a bonus, not a requirement.
Feb 5, 2010
I want to get a few thoughts out regarding the situation between TechCrunch and DanielBru. First of all, this is in no way in defense of either side. What Daniel allegedly did was wrong, no question. And how the situation was handled on TC's side – well, that could certainly be debated. It is what it is.
I will also disclose that I do know Daniel, but not very well. He's another fish in the expansive sea of acquaintances we end up with while working in this industry. However, I do know him well enough to know that he's a kid. This isn't meant to demean any of his many accomplishments, but at the end of the day – he's a kid. He's a kid who goes to high school, who likely has a curfew, who because of the opportunities presented to him by adults has to add the pressure of being a teenager with the pressure of being a pseudo-adult. This can't be easy.
This industry is, as far as I know, the only other industry besides entertainment that allows kids to be in positions of power or of massive reach. Daniel's company, Teens In Tech, is a blinking-neon-arrow-over-the-heads-of-each-kid-in-this-industry reminder of that fact.
We, as a culture, love to give kids the opportunities to function as adults. We're entertained by the notion of a child-prodigy-turned-doctor on TV; we're enamored by the phenomenon of the child star, but then we act shocked when they spiral out of control before they're old enough to drink the alcohol that caused them to crash their Ferrari.
We forget that a kid is a kid, regardless of the responsibilities they've managed to shoulder. Let's not forget the lesson in the story of the scorpion and the frog. Now, I'm certainly not saying that anyone under the age of 18 is incapable of handling themselves as an adult – but they're not an adult. I'll go so far as to say that it's irresponsible to forget that.
Our country gives minors the chance to get their act straight when they do something really screwed up in hopes of it not hurting the rest of their lives. Whether or not this works is another story, but the idea is to give people a second chance before they hit an average benchmark of maturity.
So, a bit of unsolicited advice for anyone who's interested: If as an adult you decide to bestow responsibility upon a kid who is capable of doing the work of an adult, then you should be prepared to shoulder some of the responsibility for decisions made that are more aligned with their age than yours.
Dec 16, 2009
Yesterday morning, I was having a conversation with my friends Ian and Arsenio at Digg about our favorite albums of 2009. I realized that I've never taken the time to make a list of my favorite music from a particular year, considering how much I tend to tweet about what I'm listening to. So, without further adieu - my 10 favorite albums of 2009 (in no particular order), with links to my favorite tracks.
Silversun Pickups - Swoon
Suicide Silence - No Time To Bleed
Converge - Axe to Fall
Irepress - Sol Eye Sea I
Baroness - Blue Record
Isis - Wavering Radiant
Kid Cudi - Man on the Moon
Animals As Leaders - Animals As Leaders
Russian Circles - Geneva
Nov 14, 2009
Recently at Digg, I started doing a weekly-ish company-wide design review. My feeling is that it's essential to get feedback from the people in your company for two reasons: First, if there's a decent amount of people in your company (say, 50+), they're a good, quick snapshot of multiple user types. Second, enthusiasm is infectious, and it should start from within the company. In a general sense, if the employees of a company don't love the product, why should anyone else?
So far, I've had one large and one small design review. Knowing there'd be the probability of a high volume of feedback and limited time to respond both communicatively and creatively, I asked for feedback to come in a particular format to make it as easy as possible for my team to digest. The "rules" were simple...
Send feedback via email. I want people to take the time to think about their suggestions, and not have too large of a forum for knee-jerk reactions. Group feedback sessions tend to move too quickly, and it becomes really difficult to record everyone's opinion.
Provide context to your suggestions. By nature, feedback is subjective. Without understanding where someone is coming from or having inherent trust in their opinion, it's difficult to turn "I don't think that looks right" into something useful. The best way to do this is to provide a link to or an explanation of an example of where you feel something is done better.
I'm not the type of person who discounts someone's ideas based upon who they are or what they do professionally - if you use the site, your point of view is valid. That being said, of all of the talents of my team - reading minds isn't one of them (at least not to the best of my knowledge). With feedback, context is king.
When in doubt, draw it out. Ideas presented with visual support are much easier to understand. It doesn't matter if it's a hacked up screenshot or a camera phone snap of a bunch of boxes drawn on a napkin. Designers are visual people, so it easiest way to get convey an idea is to speak our language.
So where is this coming from? Besides the fact that I'm really excited about the design reviews at Digg and wanted to tell people about it, I noticed something on my sister's Facebook stream this morning that I've seen happen a few times on my own.
I took a screen shot of it and wrote out a bit of feedback. Initially, the idea was to send the feedback directly to people I know at Facebook, but then decided to blog about it instead. Kill two birds with one stone, if you will.
The feedback was written following my own feedback rules, but with a bit more added structure. The part that I added, which I didn't ask of my co-workers, was the inclusion of arguments. The context of this feedback is based upon the assumption that I've earned some amount of trust in my opinion over the span of my career.
Due to this, I wanted to present what I felt would be reasonable arguments to my feedback to help whoever read it decide whether the issue is worth looking into.
Here's what I was going to send...
Summary (check out the image)
Denise posted on my sister's wall "Are you in Texas" because she saw a group of pictures in Lisa's stream that she was tagged in, with the associated album named "Driving to Texas"
The album name that's displayed in the stream should have ownership attached to it, ie. "Driving to Texas by (First Name + Last Name)"
The assumption based upon the information given is that my sister was driving to Texas because of the title of the album. It's a safe assumption because there's no context as to who's album it is.
This confusion is likely an edge case where most people probably don't care about the context of the album, they only care to see pictures of their friends. Plus, If you click the picture, it displays whose album the pictures belong to in context of the album.
I find collaboration with non-designers to be so important in design. Designers have a tendency to see things through a different lens than most people, which can be counter-productive when trying to find solutions across all use cases. I'd argue that one of that main reasons teams tend to design in a vacuum is because managing feedback is difficult and it's extremely time-consuming to dissect subjective thought.
If someone uses the product, they have a valid point of view - period. Set expectations. You'll have the ability to digest a larger amount of feedback in a shorter period of time and have best chance possible to turn anyone's ideas into useful information for design.