Tag Archives: culture

Being a startup’s first product designer

There are few things more tantalizing than taking the reins at a growing startup in Silicon Valley as the first Product Designer. The entire visual and interactive experience is in your hands, and everything a user sees and does happens through the filter of your work. Product design is more important now than ever, so it has become a huge responsibility. Bad design and user experience can sink a small company just as fast as bad engineering, but great design can be the hallmark of a good product.

I’ve been fortunate enough to spend the last month and a half here at Kicksend as Product Designer. It’s been so much more intense than I could have imagined, and I’ve learned a lot about how working in a startup differs from leading a consulting team. These are a few of those things that stand out the most.

1. You are the creative product culture lead.

Just as important as good product design is good design culture. What does that mean exactly? It’s a way of thinking about product (and, I suppose, the world in general) with awareness of how things are designed, what about them constitutes good or bad design, and how it could be improved. It’s all subjective, and you don’t have to be ‘right’ – you don’t even need to be a designer or a ‘visual person.’ Engineers, biz ops, marketing, and whoever else on your small team should be thinking about design. If your team can get into the habit of noting usability and aesthetic problems (or successes) when critiquing another company’s product, they’ll be much more helpful when you ask them for critique on the work you’re doing with them. As the first designer, you can’t benefit from a strong team critique structure, so take advantage of  your great team by sharing your knowledge and passion for design, and ability to discern good design from bad design when observing the world around you.

Most small startups and early-stage companies are still figuring out the nuances of their culture. Company culture can’t be forced – it has to be discovered. It’s defined by the way product, business goals, and the team work together. If you exude design from the get-go, it will be forever ingrained in the company’s fundamental values and culture.

For example, I talk about design incessantly. Ask anyone on my team, ask my girlfriend, my parents, strangers… I just can’t seem to shut up about it. I see the world through this lens that makes badly set type literally impossible for me to read, and I instantly ragequit anything with bad usability. I can’t even use certain mobile OSes because the confirmation dialogues won’t make up their minds about which side the confirm button will be on.

I also bring design into the office…

(Amperbranch by Ryan Putnam and Ropersand print by Rogie)

(My baby baby grand)

Posters lying on the floor waiting to be hung. Can you believe we don’t have nails in our office?

Posters and letterpress prints aren’t the lynchpin to design culture success, but it gets me excited about design. By extension, it gets everyone else excited about design or, at least, exposed to it constantly. Culture is contagious… you just gotta start the fever.

2. Take religious and verbose notes before you dig too deep into the trenches.

This is something I wish I had done more of. For the first 72 hours you’re part of a new product team, write down everything. Think about how it works, what’s wrong with it, what stands out in a good or bad way, what you think the product can do for you, etc. The ‘newbie’ perspective is something you can never get back, and it’ll give Future You some great insight into how a new user feels stepping into your product for the first time. Think of it as doing user testing on someone with a great design vocabulary.

On my first day, I walked into the office and said “No one wants to send photos. No one wants to use Kicksend” and it’s the most valuable observation I could have ever made. It informs most of my design decisions, because I know people (especially our market of Average Joes and soccer moms) are adverse to using software. Their goal is for Grandma and Aunt Sue to see their vacation photos or Timmy’s first steps. How can I design Kicksend to help people achieve that goal? As we iterate on our product, you’re going to see it get more and more out of the way. There’s nothing revolutionary or shocking about that approach, but it’s informed by experience and observation, not jargon.

After your first week, present your notes and feelings to the team. It’ll give everyone a fresh perspective on something they’ve been looking at under a magnifying glass for (possibly) months or even years. Fresh perspective is crucial for any product to stay relevant and keep improving… ask any startup founder.

3. Never stop learning. You don’t know as much as you think.

Coming from a more traditional role as a design consultant, I thought I had a pretty good idea of how software / product design worked. It shouldn’t come as a surprise to anyone that I was pretty much completely wrong about that.

Rarely as a consultant did I ever have to ‘clean up’ an existing product, and I never had to stick around after the first release to maintain, iterate, and bugfix. Stepping into an existing product with thousands of manhours and four passionate engineers behind it is an entirely different experience. At first, it’s almost impossible to make sweeping design changes. In the first week, I felt paralyzed by it. As I eased in, I learned the ins and outs of Kicksend for iPhone, then ‘realized’ there was a webapp, Android app, Mac app, and an Air app for Windows. O M G.

It was overwhelming, and even today I’ve only made headway on three of those five. Even on those I’ve only scratched the surface but fortunately Brendan, one of our co-founders, has always held high design standards, and Mike Kus has done some great consulting work for Kicksend before I got here. If you’re used to a fast workflow through consulting or freelancing projects prepare to slow waaay down, while working faster and more intensely than ever before. That’s not to say I sit at my desk twiddling my thumbs, however. I spend 90% of my time on product, and the rest…

4. Wear many hats.

My business card says “Product Designer” only because “Design ALL THE THINGS” wouldn’t fit. I’ve helped with iOS, Android, and Mac App icon design, created marketing collateral, business cards, landing pages, giveaways… the list goes on.

I expected (and desired) these responsibilities upon joining the team, but the workload adds up. Make sure you know where to draw the line, how to design for re-use, and always work smart, not hard. When the design team grows from guy-in-the-corner to Design Team, you’ll have the insight and experience to lead others effectively.

So that’s it. I’m still learning, failing, iterating, and insert-important-sounding-gerunds-here-ing at Kicksend. I’ll keep you updated.

Building a Rocket in 4 Days – A Kicksend Story

Kicksend lets you send tons of photos to people you love. A month ago, we released a revamped version of the awesome Kicksend web app. The relaunch was closely tied to making Kicksend a lot friendlier towards everyday people. To push that along a little further, we were brainstorming a new photo-sending flow for our users. Here’s how it all came together technically, and how this exercise helped influence Kicksend’s current branding.

Whiteboarding
At Kicksend, we whiteboard new product flows as a team. For this session, we were wondering what we could show users that would give them something interesting to look at while photos were sending. We decided that everytime someone sent photos from Kicksend on the web, we’d show them a subtle animation of a rocket blasting off, which was in line with Kicksend’s existing characteristics as a speedy photo delivery service. Here’s Derrick’s first attempt at fleshing it out on paper

First Draft
We had our illustrator, the mighty Mike Kus, come up with visual assets for the animation, which he created for us in a day. This included the actual rocket, flames, support structures for the rocket, a gauge that indicates photo sending progress and a beautiful moonlit background to set the stage. Here’s the result:

 

As photos send, we wanted the dial to fill up, and have the rocket blast off into the night sky, becoming smaller and receding into the distance.

To make the animation as close to reality as possible, we initially opted for HTML5 with an actual physics-based acceleration engine. Essentially, we would be animating the rocket using projectile motion and then scaling it to be smaller as it blasted off into the background. This involved setting up the HTML5 canvas with a coordinate system that made sense, and scaling/rotating/accelerating the rocket as a function of it’s position on the x-axis, while moving the rocket along the canvas using a projectile function tied again to the rocket’s position on the x-axis.

After a few experiments with Mathematica, we found a few custom projectile functions that worked well, and we had a pretty decent proof of concept. When we decided to test performance, however,  we ran into serious issues with every browser except Chrome. The problem seemed to lie less with doing math in the browser at a rapid execution rate and more towards browser compatibility of the HTML5 Canvas. Animations over a big Canvas were lagging most of the time, and we weren’t confident enough to move forward with it, even though animations on a smaller canvas object seemed to be consistent.

Second Draft
At this point, we were considering scrapping the rocket altogether when we realized we should probably give the new CSS3 animation functions a shot. A little digging showed wider compatibility on multiple browsers so we decided to spend a little time poking around.

20 minutes later – surprise! CSS3 animation support is actually quite powerful, and we wound up replacing most of the rocket animation with CSS3 properties. We scrapped the projectile motion equations completely and also moved off HTML5 Canvas for the most part.

The new way of animating the rocket was now a combination of the following CSS3 properties: transition and transform (for rotation) operating on a rocket image. The actual movement of the rocket (slow start, then speedup) is governed by a custom Cubic-Bezier path that the transition property supports.

 

This method was significantly smoother, was supported on many more browsers and essentially gave us a solid foundation on top of which we could build out more of the photo sending interface confidently.

Rocket Gauge
We still had some trouble with animating the rocket gauge. Since it was shaped like an arc, filling in backgrounds using transparent foregrounds didn’t really work cross-browser. This is when our realization that HTML5 Canvas actually works consistently with smaller canvas sizes helped.

The rocket gauge was then coded up as a simple canvas arc that gets drawn on the canvas as the photos send. We also used the aforementioned CSS3 properties to make the gauge’s needle move along with the arc drawing. For IE 8, we reverted to a simple progress bar since it didn’t support Canvas.

 

We pushed the rocket to production and were super happy with the response from our users. Time from whiteboarding to production push: 4 days.

Send some photos on Kicksend to see the animation in action.

And Then…
A few days later, we were wondering what to do about our email newsletter, nurture campaigns and notifications. At that point in time, the layouts were quite terrible, with very limited Kicksend branding. Worse, they looked unfriendly and unapproachable, which directly affected our conversion rates.

When we gave Mike Kus the mandate to redesign our email newsletters and notifications, he used the new rocket to guide his work, resulting in a fresh new look for all our email nurture campaigns, newsletters and notifications, and one that improved the overall cohesiveness and conversions of the app dramatically.

 

 

Looking back…
We’ve been working on Kicksend for over a year now and as a team we’ve gotten to know each other’s strengths very well. This web app relaunch was some of our best work together as a team, where every person on the team stepped up to make our product shine.

Thanks for reading!

PS: If you’re interesting in working on a tight product team, we’re always hiring stellar folk.

From consulting to employee #1

Has it already been a month? 

Screen_shot_2012-02-24_at_5

Right before Kicksend, I was engineer at Pivotal Labs, a software consultancy. I had an awesome time there and learned an incredible amount, but I missed startups. Life at a startup is very different than a consultancy. For one, you own the product and get to experience the ups and downs of the entire lifecycle, as opposed to focused 3 month chunks of work at a time.

But I believe that despite the differences, what makes a team effective remains the same. Prior to Kicksend, I had previously started, worked and consulted at startups. I had developed ideals that I learned I shared with the founders, and after a month it’d be great to look back and see that all in action.

So instead of a “highlights at the company” post, I’ll share my one-month-old thoughts about what’s working for us at Kicksend.

Ship often. Iterate fast.

522031168

Day 1. “We need a new flow for the web app.” 

Great, I thought, that’d help me familiarize myself with the code base quickly and give me great chance to see how the team really goes about building stuff. 

Starting off with a high level wireframe, we built, we tweaked, we shipped, and we tweaked some more. We always discovered that extra cut for simplicity, a more succinctly written copy, an additional subtlety that adds to the experience. It was a textbook example of product iteration, that was out the door in two weeks.

There’s a fine balance between “perfecting” a release and shipping quickly, and the team always has to tread that carefully. That doesn’t mean substandard releases, though. Anyone who builds stuff will have that in built sense of pride in whatever they create. We focus on the minimum viable feature that’d achieve our goal. Once met, we ship and start iterating on real world feedback. Which leads me to..

Measure and experiment

238496432

While learning the code base, I was struck was by the sheer number of metrics at play. At Kicksend, we measure and experiment with everything. I had to familiarize myself with the countless funnels, events and AB tests, and how we use them to evolve the product. Even on our iPhone app. It’s our way of understanding how users use Kicksend in the real world, and helps us continually create a great experience for them.

Always adapt

Screen_shot_2012-02-23_at_10

We started the month using Github Issues as our primary project management tool. We were already on Github, so it was the straightforward choice. And it worked well. Issues is a slick, well designed product. 

We started to outgrow it (I increased the team size by 50%) . Having to use tags to manage priorities and state was just cumbersome, for example. Issues is an issue tracking system at heart, so it does have it’s limitations.

Having just joined from a pretty great consultancy, I proposed a switch to Pivotal Tracker. Inherent bias-ness aside, I knew how well Tracker could work in teams. After my 5 minute intro to effective Tracker usage, followed by hook ups to Github and Hipchat, Tracker just blended into our workflow.

Don’t prematurely optimize

229544144

We use a very straight forward stack with the tools we needed for the job. I’m not a fan of pre-mature optimization, nor many moving parts. Especially in startups. So it warmed my heart to see that Kicksend was built on a simple stack, with clear avenues for scaling. We closely monitor site performance using tools like New Relic, to pinpoint exact areas for optimization. Just the other day, we didn’t like the rendering time of a couple of pages, so we decided to add an additional layer of caching.

Keep learning

263409424

There’s so much to learn at a startup beyond the realm of clever engineering. I’ve been exposed an incredible amount about what’s truly involved to grow a product and company in just the past month. As someone who intends on starting a company down the road, it’s just been awesome. 

Team

280103856

Hiring for the right fit is always important, but after that, the little things still count when building a team. An example: eating. There are many philosophies about team lunches. We eat together as often as we can. For one, it really has synced me up quickly and I feel like I’ve been here for way more than a month. (On a side note, we are making our way down Castro Street for our lunches, inspired by the Sunfire Lunch Tour. Makes picking a place easy.)

269756992

So, who’s next?

Catch me on Twitter @derrickko.

Derrick Ko: New Kicksend Team Member

We’re ecstatic to announce that we added a new product engineer to the Kicksend team: Derrick Ko

Derrickkoprofile

Derrick’s a stellar engineer who previously worked at Pivotal Labs. Derrick also started Startup Roots Singapore, and previously created Bartop & Yum.sg. At Kicksend, he’ll be working directly on our web application and our realtime backend.

We met Derrick at coffee shop in downtown Mountain View for a lengthy chat. During the course of this conversation, we quickly realized that he possessed the carefully honed technical chops and the always-curious personality that marks a very talented early-stage product engineer. We’re really happy to have him work on our web product full-time, and are very excited to see what he comes up with.

Img-4994

You can follow him on Twitter here and read his blog here. Derrick plays soccer & squash, likes to travel and is a student of design. We were really happy to discover that he’s as much of a foodie as the rest of the team, which bodes well for our team lunches :)