After I submitted my 10-hour hack Mixmatic to HN on Tuesday I got a couple of emails and tweets asking me about the design and how to become better at doing good design work quickly. The short answer to that question is: that just like everything worth doing it’s really, really hard. But if you really want to become a competent designer from scratch in 2012 here are a few of the things that I’ve learned along the way.
Ignore the tools
At least one person on the Hacker News thread about Mixmatic asked me what tools I used to do the design. I told him that I used Photoshop to mock everything up and then SASS and HTML (what else) to actually create the site. But the tools you use don’t matter. The only thing that matters is who is using them (you). I know people who never touch image editing software during the whole process and create pretty nice looking sites. Like this. I personally have to design every pixel in Photoshop before I start doing CSS. But to each his own.
If you’re just starting out and you don’t know what to use, try to find a designer you respect and ask them what they use. Then you can just ask them for help and tips while you’re learning whatever system or combination programs they like best.
Do it a lot
If you want to get jacked you have to lift weights. lf you want to run fast you have to do sprints. The same goes for design. There’s no magic bullet for it. Except maybe Themeforest. But the point remains: if you want to get better at web design you have to do it a lot.
Create a portfolio of sites you like and copy them relentlessly
The easiest way to get started immediately (assuming you have some competence with basic image manipulation and CSS) is to start noticing designs you like. Every time you see a new website examine the design and see if it appeals to you. Go back through the list of startups you like, or software you’ve bought over the past year and look at their websites. Once you’ve built this portfolio up it becomes a lot easier to do design quickly. All you have to do is take whatever your product idea is, and find site designs that are similar to the feeling you want your product to convey. Then take the principles from those designs, put your own spin on them and use them!
Copying only gets you so far
Copying designs gets you about 80% of the way to being a good designer. The difference between a competent designer and a good designer is in the small details that are almost impossible to pick up by copying. They require technical knowledge.
Acquisition of that knowledge is difficult to do but not impossible. Take a design class if you can (even if it’s not web design). Read books. Read blog posts. This one in particular blew my mind and changed the way I approach web design even though it’s about Renaissance book design. Once you’ve gotten to the point where you’re turning on the grid in Photoshop to lay out your pages, or you can wax poetic about the Van der Graaf canon you’re on your way there.
I hope you found this helpful. As always feel free to reach out if you want to talk – I’d love to!
If you read this far you should probably follow me on Twitter.
Just to prove to myself that I can still do it here’s a project I did today in 10 hours from first commit to last (with holiday shopping and dinner in between). It’s called Mixmatic and it’s a fun way to make mixtapes for your friends with Spotify.
Basically I didn’t like how Spotify sharing worked, and wanted a more personal experience kind of like when I used to make mixtapes and CDs for my friends in middle school and high school.
Mixmatic makes it really easy to do that. Just give me a Spotify playlist URL, a message, and a friend’s email address and it will deliver them your playlist with style.
Feedback and bug reports are much appreciated!
I would like today to discuss an extremely grave and pressing matter that has weighed heavily upon my spirit over the last few years. Chief among the many problems facing America today ahead of such urgent problems as mercury in fish, urban overcrowding, and shark attacks is the vapid and profane use of the vulgar word “damn.” In the forthcoming piece I will posit the reasons why I feel it should be banned in regular conversation, and suggest a better alternative. Continue Reading
Over the past few weeks a few friends at school and I have started doing technical consulting for MBAs who have a startup idea but have limited programming knowledge. Basically we run down the technical problems inherent to their ideas, talk to them about finding a technical cofounder and answer other questions they have. The program is called Rent A CTO and over the course of the two meetings I’ve had so far, I’ve had the pleasure of meeting two amazingly smart, talented and humble MBAs that don’t fit the stereotype that startup engineering culture has created to describe the prototypical busines student.
That being said, a common pattern has emerged over the course of these meetings. It’s also one that I’ve noticed over the past year in talking to as many people as I can about startups, and I think it’s a useful one to consider. Both of these entrepreneurs were trying to create what I call the “all-inclusive web app”, i.e. one that beats its competitors by bringing together their disparate features into one mega-app that does everything in the problem space. Essentially it’s the “Kayak-for-x” business model.
Those ideas are great and necessary. But the problem is that they’re unbelievably difficult to execute on.
The first problem is that they’re almost impossible to whittle down to the MVP. I’m a big believer in creating things fast that solve the problem with the smallest number of features, releasing and then expanding. Case in point is my project DomainPolish or the story of How I Made $350 in Two Days With Three Pages and Some Payment Code. The biggest strength of the all-inclusive web app is that it takes ALL the features in the problem space and combines them. Because of this, eliminating ANY features essentially reduces the product to one if its competitors. This is anti-thetical to the MVP mindset.
The second problem is that because you have to include every feature under the sun for differentiation the feature spec becomes huge. This means that while you’re creating a huge app that you’re sure there’s a market for it takes a long, long time. Any project that takes more than a month to complete has an exponentially lower chance of actually reaching the market in my experience. You end up adding feature on feature on feature for months and months, and then finally just giving up for lack of funds, lack of time, lack of interest or a combination of the three.
And finally, the third problem is designing an interface to support all of these features you’re adding. Unless you’re a UX/UI master, who are incredibly hard to come by despite the protestations in the bios of many an aspiring start-junkie, creating a sleek, simple, and easy to use interface to manage all of these features is next to impossible.
So in considering which ideas to start pursuing, ask yourself: “Is this an all-inclusive app?” If it is, you may want to reconsider trying to build it. It’s not impossible, it’s just really really hard.
If you’ve read this far you should probably follow me on Twitter.
Why do we choose one product over another? I’ve built a fair number of small web apps over the past year (DomainPolish, WhereMyFriends.Be, ReadStreamApp) and that’s a question I think about a lot. The common answer to that is whichever product has more advanced features is the better product, and will be more successful in the marketplace than its competitors. But in doing more thinking about this I’m not convinced that this is actually true.
About a month and a half ago I started working on a new project. It’s not currenly public but it’s live and used by 10 companies to help them do better email marketing. When I first conceived of the project I was pretty excited because it was the first B2B product I had worked on, and I had heard that B2B sales were much easier than consumer sales.
While that may be true, B2B sales definitely aren’t simple. Here are a few things that I’ve learned to keep in mind over the last month of pitching, cold-calling and cold-emailing tens of companies looking to prove the idea and sign up the first few customers.
Know who the decision makers are
Companies are extremely hierarchical and so when you’re pitching a product you need to know who the decision maker is within the company and talk to them. If you’re pitching an IT product to the head of marketing you’re not likely to get very far. This is especially true when you’re cold calling or cold emailing because the marketing guy isn’t going to forward your email to the IT guy (unless your pitch is brilliant) he’s just going to say that it doesn’t seem that useful.
Make it easy for your pitch to get the right person
If you’re doing cold emailing, oftentimes companies won’t list email addresses for specific people and departments and will instead have a catchall email address like email@example.com that they ask you to send all general inquiries to. If you’re going to email that address make sure your subject line makes it clear who should be reading the email. A subject line like:
“Would love to talk to you about a new product”
Might get read by the community manager, by the CTO or by the marketing guy. But a subject line like:
“Would love to talk about how to improve your email marketing”
Will either get read by the marketing guy or get forwarded to him.
Make the math clear
The awesome part about B2B is that unlike consumer products the value proposition is just math. If the company has to spend $10 on your product every month and will end up making $200 from it a month then it’s probably something they’re interested in. Make sure you make it clear from your pitch to your pricing how the math works and why it will work for them.
Realize that the sales cycle is a lot longer for B2B
For all of my other projects which were more consumer focused people usually said yes or no within the first couple of minutes. Not so with B2B. It can take weeks and weeks, with multiple phone calls and emails sent back and forth before you get a straight answer. And even if they say they want to buy it, it can take weeks after that before they actually enter in their credit card and integrate it. The key is to just keep closing, keep calling, and keep nudging them until eventually they either ask you to stop (in which case you should stop immediately) or they sign up.
I hope this little rundown was helpful for someone. If you want to know more about what I’m working on you should follow me on Twitter.
In the beginning of November I wrote a post about my goals for the month. They were:
1. Write one blog post every day in November.
2. Sign up 20 paying customers for my new project. This means I would be generating about $200 a month in revenue.
3. Bring one new team member aboard to work with me – preferably one that has a lot of coding experience.