You (yes, you!) are a designer

Are you building software or launching a startup? Are you a coder, thinking you’ll never feel confident in your own designs?

Start calling yourself a designer right now.

“Designer” isn’t a title you unlock at some threshold of skill, or a title you earn. People of all skill levels are designers.

If you begin calling yourself a designer, all the sudden you can take that work seriously. You might not have a lot of experience, but at least the time you spend working on a design is serious work. You’re not messing around, dipping your toes in the water. You are committed.

That commitment makes all the difference: now you are allowed to make mistakes, because you are going to stick with it. Making mistakes is how you learn and improve your skill.

Too often, fear of making mistakes gets in the way of learning. Make a commitment and allow yourself to make mistakes without beating yourself up about how bad it looks. With each attempt, your skill will improve.

Those like me who have made a career out of design started poorly skilled. My work wasn’t great when I began my career, but I still called myself a designer. Back then, I wasn’t any different from a developer who is just starting to learn design right now.

It’s easy to earn the right to call yourself a designer: just go design things.

“…we assign mystical reverence to the work of professional designers. Their elegant color schemes, provocative typography, and eye-scorching aesthetics leave us dumbfounded. Only “creative types” can achieve this; only near-savants who were born with a special talent.

…you’d think design is difficult. You’d think it’s complicated, and that gaining basic skill requires hours of studying a multitude of advanced topics. And you’d be wrong.

Anyone can be a great designer with practice. It’s both at once liberating and frightening: your future as a designer depends only on how hard you’re willing to work. Design is a skill and a trade; you get better at it by practicing. First, learn the basics and go design something. Then, call yourself a designer. The more things you design, the better you will get and the more lovely and insightful your creations will become. No magic knowledge hidden away in design books, blogs, or classes will teach you to be a great designer. All you have to do is practice. Learning design is that simple.

Excerpt from Chapter 2 of my ebook, Bootstrapping Design

Why do coders think they can’t design?

“I’m not creative enough.” / “I wasn’t born with the artistic gene.”

“I don’t know how to start. Everything I read about design confuses me more.”

“I recognize good design when I see it, but everything I design looks bad.”

The answers are always the same. I write about design specifically for developers, and have even written a book on the topic. I talk to developers about design a lot.

Developers want to design—that’s apparent from conversations. However, many are confused about how to start learning. And even worse, some developers don’t think they are capable in the first place.

But that’s not even remotely true. Design is a skill anyone can learn. You don’t have to be born with a special talent, or acquire a wealth of knowledge before you can design something beautiful.

Developers are creative

“I’m not creative enough.” / “I wasn’t born with the artistic gene.”

You might consider coding to be logical and analytical, while design is creative and artistic. That’s completely inaccurate. Coding is every bit as creative as visual design.

I’ve seen code that was art. I know you have too. The kind of code that just seems so brilliantly creative—a solution to a problem that was too elegant to believe or a new technique that completely changed the way people work.

Programmers are creative. When you are debugging code or writing tests, you are imagining possible outcomes and causes. That’s creativity—the ability to imagine.

Which means you already have the creativity you need to design.

The only problem is you haven’t learned to be creative in the ways necessary for design. You are creative in problem solving, but maybe not in visual communication. But that’s ok. For now, what’s important is that you know you are capable of creativity. You can learn to express your ideas visually, just like you learned to express them in code.

Stop reading design education that’s intended for experienced designers

“I don’t know how to start. Everything I read about design confuses me more.”

You’ve read design books, blogs, and/or tutorials, but you don’t understand how to use that information. None of it seems to help you make a design, or demonstrate what your very first step should be.

Learning to code, you install libraries and a text editor, then start typing. The tutorial teaches you what each line of code means, and introduces concepts one at a time.

If learning design seems more difficult, it’s because the tutorials/books you are reading are intended for experienced designers, not people just starting to learn. (And often, even if a resource claims to be written for developers, it still covers advanced topics too soon.)

Would you try to teach someone learning to code about OOP or TDD before they understood what a variable or a function is? Of course not! It would be impossible.

So don’t make that mistake while learning design. Don’t read about advanced topics like responsive design, color theory, or typographic genres before you have grasped the basics.

When you try to learn design, if you find yourself getting lost, take a step back and try to find a source for more basic topics. (I’d suggest that the most important topics to start learning are alignment, proximity, and visual hierarchy. My book could be a starting point for you.)

Your designs will look bad at first, but keep practicing

“I recognize good design when I see it, but everything I design looks bad.”

Look back at a sample of your code from just a year ago. I’m sure you could find ways to improve it. In a year’s time, you’ve practiced programming and you’ve increased your skill. You also have new knowledge.

Was the first program you ever wrote from scratch incredibly elegant, or was it buggy and gnarly?

Starting out with design is exactly the same. Your early designs will be ugly and gnarly. But each design will be better than the one before it.

Design is a skill. You have to design things to get better at designing things. It’s exactly the same as learning to code.

You have to be willing to let yourself make mistakes. Know that the first few times you try to design something, it’s going to be flawed. That’s ok. Look closely at those flaws and learn how to fix them. You’ll get better at it.

Practicing design is not as much work as you’re thinking

Practicing design sounds like a lot of work. After all, if it’s just practice, you might think you’re not actually producing real work.

Practicing on fake projects is great, but if that feels like a waste of time, practice on a real project. Redesign your personal blog, or finally design a concept for that side project you keep putting off. Or, take some minor feature of a bigger project and redesign it. Just do something.

You don’t have to make 100 websites before you get good at design. (Who has the time for that?) It happens in small steps. However, if you don’t start taking steps, you’ll never get better.

How To Stop Design Guesswork

When you try to design, do you ever feel like you are making things up?

For example, you are trying UI elements you’ve never used before. You’re not even sure if they will make a difference—it’s just a guess. You thought it sounded like a good idea. But how do you really know if it’s a good idea or a waste of time?

Design is just like any other kind of work: every time you venture out into new territory, you take a risk of getting stuck. When facing an issue, the natural reaction is to keep working until you fix it. Somehow a week passes, and you realize there was a simpler solution all along. Then you find yourself wishing you could get that week back.

While you’re still new to design, getting lost like this is easy. Here are some tips to avoid that trap.

My definition of designer is broad. I write for developers learning design, and encourage you to start calling yourself a designer right now! Keep that in mind as you read.

1. Become a dirty thief

The design problem that’s vexing you isn’t new. Someone has solved it before, and they are probably more experienced than you. So before you try to reinvent the wheel, do some looking around to see how other designers have solved your problem.

Look at software you use regularly for similar situations. Sign up for a few free trials to see what the interfaces look like.

Once you figure out how someone else solved that sticky issue, copy them. Steal their solution.

This is what designers often refer to as “finding inspiration”, “design convention”, and “best practice”. These are all fancy euphemisms for copying.

So while I call it stealing, what I’m really suggesting is that you learn from others’ experience. That’s the best way to solve the most challenging design problems.

(To be clear, I’m not suggesting you infringe on someone else’s rights, break the law, or take intellectual property. Don’t copy someone’s entire design, just the one aspect that solves your challenge.)

Further Reading: check out my ebook. I wrote a whole chapter called “How To Steal,” that gets into more specific ways to copy design ideas.

2. Sketch first and you won’t waste so much time

Sketching is magic. There’s no better way to find and test a multitude of ideas than to sketch.

Sure, you could draw a wireframe in Balsamiq. You could build a prototype in code or even create a full-blown mockup in Photoshop. But none of these is nearly so fast as sketching.

Sketches get exponentially more efficient the more concepts you explore. Your first concept will rarely be correct. To find the best solution, you need to explore lots of concepts. If you try each of these by making a prototype or mockup, you’ll end up burning a lot of time.

New designers often want to skip sketching. They want to jump into the exciting part—the real design. They want to get something built. But sketches are important because they prevent you from committing to a solution too soon. If you jump into creating a polished, detailed version of the concept before you are certain it’s correct, that’s a risk. Better to spend 15 minutes sketching to ensure that time won’t be wasted by having to start over.

You might think sketching is a bad idea unless you have some drawing skill. I also wrote in my ebook that many designers’ sketches look like works of art, but yours shouldn’t. Your sketches should be quick and ugly. The only purpose of these sketches is to explore ideas quickly. The more beautiful your sketches, the more time you wasted. Let them be ugly. You don’t have to show them to anyone else.

Oh, and just use a pen and paper. Don’t try to get fancy with iPad apps or other software. Remember, it’s all about cutting distractions to explore ideas as quickly as possible.

3. Don’t start from scratch

Frameworks and libraries are awesome. Never before has our time spent coding been so efficient, and it gets better all the time. However you might not expect that using a front end coding framework can save you a lot of design time too.

Frameworks like Bootstrap and Foundation solve common interface problems for you. You don’t have to research the best way to design a dropdown menu, or ways to lay out a form. Just choose from implementations built into the framework. Each time you do this, your design burden gets lighter.

Unfortunately, there aren’t many tools like that specifically for design.

But, using traditional design tools isn’t quite so difficult as you’d expect (or have been led to believe).

Basic Photoshop and Illustrator can be a good use of time when you are ready to build the real concept. Not necessarily for mocking up the whole design, but just for adding some nice graphics. Learning just a few simple techniques can make you look like a bona fide digital artist.

Yes, a lot of designers advise steering clear of graphics software altogether and designing in the browser instead. That’s good advice (usually), but often sites still need graphics. Learn a bit of ‘shop and you won’t have to use stock photos so frequently.

If you want to learn some Photoshop, set a limit. A few simple techniques will be sufficient. If you tried to learn every feature in Photoshop, you’d end up with a lot of useless knowledge.

(Also remember you don’t need an expensive license to use Adobe software anymore. You can pay to use it by the month these days.)

4. When you make an assumption, test it

Inevitably there will times you can’t find a perfect solution, usually because you don’t have enough information to inform your decision. And because of that, you will have to make something up.

Too many designers stop there. They launch that assumption and never think about it again.

As designers, it’s easy to come to think that our assumptions are correct. We get comfortable making assumptions because design, as scientific as it can be, isn’t always precise.

However, when your assumption can have significant implications, make sure to test it. Real data is always better than a guess. Implement an A/B test or simple analytics to see how people use it out in the wild.

Then, launch it and observe what happens. But keep your sketches handy. You might find that you need to try one of your other concepts.

Personally, I find CrazyEgg to be the best analytics for evaluating design. The scrollmap is especially useful for seeing how people interact with your content and interface. It’s also less time-consuming to implement than event-based analytics.

Remember: if you are guessing, you need information

Do everything you can do avoid making a pure guess. Steal, sketch, and use tools that provide common answers. If you do have to make a guess, test it, and be ready to switch to a backup solution.

Don’t be afraid to rock the boat

Some months ago, I decided to change how I write.

I’d realized that much of my writing came across as preachy. “People just want helpful information,” I theorized. “People don’t want to be preached at.”

So, I wrote posts geared towards being helpful and did my best to avoid sounding judgemental.

And something strange happened. These posts didn’t get so much traffic. People started unfollowing me on Twitter. My writing frequency decreased.

I had a difficult time deciding what to write. I’d often open up Twitter, then immediately close it because, well, I didn’t have anything to say.

My decision to avoid sounding preachy had removed the best aspect of my writing: the passion. And people lost interest.

When I changed back to my old, ranty style on Twitter, people immediately began engaging me. Even though I was standing on a soapbox. Even though my bold claims had some slight inaccuracies, or didn’t apply to everyone. Even though some of my statements were a bit idealistic and simplistic.

Looking back over my blog and tweets, the difference is amazing. Bold, controversial content always gets more interest. Some people get mad, but even more thanked me for speaking up. And then they subscribed to my newsletter, followed me on Twitter, or bought my ebook.

I’d changed my writing because of my fear of dissenters. I was tired of having people nitpick my arguments. I was afraid the only reason people were reading was because of the controversy—that they didn’t really care what I had to say. I didn’t want people to think I was just rocking the boat so they’d buy my stuff.

I was wrong. Developing a voice and taking a stance are what earn you an audience. It’s how you form relationships instead of just earning customers.

If no one’s upset by what you’re saying, you’re probably not pushing hard enough. (And you’re probably boring, too.)

So when you’re writing landing pages, blog posts, and emails for your business, take a stance. Say something bold. Make some people mad. You’ll find that people who share your worldview will gravitate toward you.

And do yourself a favor: spend your time talking to those people, the people you like, rather than arguing with grumpy strangers on the internet. You and your audience will be a lot happier.

Breaking design rules for profit

I’ve had to relearn certain aspects of design now that I’m running my own business.

I’m making decisions I’d have considered a major error only a short time ago. Like putting the logo below the fold. Or using a color that doesn’t match the rest of the palette on purpose. On purpose!

The proof it works is in the numbers. Cascade earned a 12-15% conversion rate, depending on the traffic source. That is higher than Bootstrapping Design’s landing page conversion rate of 8-12%.

Designing for your own business is different than designing for clients. What follows are my hard realizations after living on product income for a year.

(Also note, I’m discussing professional products only. Consumer products are a wild goose chase, as far as I’m concerned.)

The logo below the fold

Customers are more important than me

Designers revere conventions. Putting the logo in the top left corner of the site is supposed to be an important convention.

But for small startups like mine, it’s the wrong decision.

Putting the logo in the top left corner is wrong because it makes the statement that the person or company operating the website is the most important information on the page. It implies: “Hey visitor, you should know who I am before you read anything. I’m kind of a big deal.”

Brand awareness doesn’t exist if your customers number in the hundreds. Designing for a small business is totally different than designing for a large brand (or a brand that wants to become large).

Visitors don’t care about your logo and they don’t even care who you are (yet). They are looking for the answers to two questions: What problem does it solve? Do I have that problem?

You’ll notice that in my design for Cascade, I placed the logo below the fold and low on the visual hierarchy. The answers to those two important questions are right at the top where the logo would normally be.  The only people who even see the logo are those who identify with the problem and intended audience. People who don’t leave the page immediately. That’s great because throughout the rest of the page, I know exactly who I am writing to.

So stop putting the logo at the top of the visual hierarchy. Instead, write about the problem your business is proposing to solve. Write about what type of person usually has that problem. Then, lower down on the page, explain how your business is the answer and ask them to buy. And place the logo there too.

Your job as a designer and writer is to show the visitor that they have a problem and to convince them to continue reading about your solution. If you succeed in this, people will pay you.

The ugly button

Business goals are more important than taste

(I bet you never thought you’d see a designer write that!)

Cascade’s landing page sports a shiny green button. The button isn’t ugly in and of itself. But set amongst the intense orange that dominates the composition, it clashes—badly. And, it clashes on purpose.

I chose the bright, clashing green color for the button because I wanted visitors to see it. Originally, the color scheme for the site included a complimentary blue. I used that blue in several of the illustrations, but the buttons were blue too. When evaluating the design, I realized that this was a problem. The buttons had similar visual prominence to the other elements on the page, and that didn’t fit my goals for the visual hierarchy.

My plan was to place the buttons lower on the page. After all, no one is going to sign up before I’ve explained why they’d want to. But, when the visitor does scroll to a point where the button is visible, I wanted it to be the most obvious element on screen.

A pretty blue button that matches the rest of the design did not accomplish this. So, I stripped the blue from the design and chose a clashing green color for the buttons. Now when you scroll far enough to see a button, it is impossible to miss. The ugly aesthetic of the button supports my goals perfectly.

With this change, I made a conscious decision: my business goals were more important than making the design attractive. I don’t care if Cascade wins design awards. It doesn’t matter if other designers like the page. It’s not for them. All that matters is that the page connects with technical startup founders who struggle with design.

Furthermore, rather than merely assuming I met my goals, I used analytics. Every metric shows that my design is successful.

It’s okay to break the rules.

I’m not trying to convince you to always place the logo below the fold or to always use an ugly button. But I do hope these examples give you the confidence to break best practice when you discover it’s necessary.

Doing this is not nearly as big of a risk as you’d think. Designers might point out the flaws in rude tweets, but they could surprise you. Some might even be smart enough to catch onto what you’re doing and write a blog post about it, like Sacha Grief’s writeup of the Cascade landing page.

Regardless, be proud that you’re prioritizing efficiency over vanity. Making these kinds of decisions is the right way to run a business, and your customers will be grateful. And they’ll show that gratitude by paying you.

On timeless design

We can point to any number of famous works in architecture, industrial design, and graphic design and show rightly that they are equally effective today as they were upon creation.

But what about digital work, like web design? Technology turns over so quickly that digital design seems to be forgotten or deemed ineffective much more quickly than physical counterparts. No one points to a great website from 5 years ago and says “Yeah, that would still do the job today.”

Is digital design disposable?

The idea that digital design is disposable can be disheartening. You put the same hours, care, and passion into a digital design as you would the design of a physical object. But if you don’t update that site design every couple of years, you start to feel like it isn’t doing its job anymore.

We feel this way because we forget about the purpose of the digital design in the first place: to deliver a message, experience, or connection. That purpose is fundamentally different than the purpose for designing a physical object. Further, realizing this difference brings the core of the matter into focus. It’s not the design that matters. It’s the message.

So, when you’re working on a digital design, don’t worry about whether it’s timeless. Don’t concern yourself with earning web design awards or whether you’re committing a grievous design mistake by following a trend. Instead, focus on the goal of your project. Create a great experience for customers. Deliver your message in a way that people can really connect. And, exploit those trends if they serve the goals of your project.

$30,000 eBook Sales. In 2 Months.

Note: You can read the archived comments at the Hacker News thread.

I launched my design ebook for startup founders on March 20th, 2012. On May 25, I broke $30,000 in sales volume. Here’s what I learned.

Research customers.

6 months ago, the idea of writing a book was inconceivable. I’ve never wanted to write a book. I didn’t think I had anything to say.

When I started—with research—what would become my next project, I was surprised. Not surprised at myself, that I had discovered some new ambition, but surprised at what people needed and how well I could meet that need. Me, a designer, not a writer.

See, by beginning my project with research rather than an idea, I found an opportunity. It wasn’t an opportunity I could have imagined nor one for which I would have intentionally searched. It was an opportunity that already existed out there—on the web, in tweets, on blogs, and appearing in the frustrations of certain people. (The audience I researched was programmers who are bootstrapping software businesses.)

The primary reason for the success of this eBook is that the idea came from my customers, not from me.

My business is succeeding because it began with an understanding of customers. This understanding includes not just what they need, but also more important insights: what they buy, what they value, how they communicate, and where they hang out.

You think you already know these things about your own customers, but you don’t. Your assumptions are wrong.

My first business was based on such assumptions, and it crashed and burned in silence. Don’t make the same mistake. Research first.

Price by value.

I set a price for my ebook that some consider too high. Their opinion demonstrates that these people are not really in the audience for my book.

My audience is composed of professionals—they’re good at what they do and they are paid well for it. While many in my audience can’t afford to hire a designer outright to work on their bootstrapped side projects, they are comfortable paying for products and services as part of doing business. They donate time and money to open source projects and they enjoy supporting products they like. For them, it doesn’t matter that much if the eBook costs $12 or $39. All that matters is that it helps them to build a more viable business.

Read my guest blog post on A Smart Bear about my value pricing strategy for a more detailed rationale.

The numbers prove my strategy worked well enough. Here are the details:

Say sorry.

The power of an apology or the cost of a mistake?

I made an honest mistake after launch. The coupon I had promised everyone on my mailing list expired before I said it would.

I reactivated the coupon, extended the expiration by an extra week, and sent an email to the list apologizing. This apology email drove about $1,200 in sales. Other newsletters have not converted quite so well.

Would I have earned more sales if I hadn’t made that mistake? Did the apology completely close the gap? I have no way of knowing. Regardless of speculation, the apology email made an impact.

Later on, my payment system had an issue where credit cards were being declined for no reason. A couple of customers were very kind to notify me, and I got in touch with the support teams for those third-party systems and they fixed the issue quickly.

Rather than leave it there, I sorted through the logs to find about 10 people who had been declined when trying to purchase. I wrote a personal email to each of them, and included a $5 discount coupon as an apology. A few of them had already purchased after the error was fixed, so I refunded them $5 instead.

These apologies have led to customer relationships and great feedback, and I know that several of these customers recommended my book to others just because of this experience. Apologizing and fixing the problem was not only the right thing to do, but it drove more sales by word of mouth.

So, what now?

The last couple of months have been strange because I have no idea how to run a profitable business. I’m making it up as I go.

I’ve completely skipped marketing practices like SEO and A/B testing. Many people claim these techniques are essential to running a business, but the truth is they are long-term strategies for optimizing something that already works. SEO and multivariate testing can’t do much if people don’t want your product. This time out, I learned to focus on getting the product right before I worried about following every best practice. I can always work on that stuff later.

Next, the revised edition of the eBook is in the works. I have dozens of lengthy feedback emails and even full copies of the ebook annotated by customers to inform the revisions.

After that, I’ll start researching the next project. I have an awesome customer base to learn from, and they’re already asking for more.

Not designers. Not coders. Just builders.

Designers should learn to code. We’ve been talking about it for years, and the attention this issue rightfully earned brought about a change: designers are writing code now more than ever.

This movement has produced an interesting and unintended consequence: the line between designer and coder is blurring.

I propose we remove the line altogether.

Why? Say it with feeling: design concerns and code concerns are the same concerns. Internalize that for a moment. Designers and coders contribute to the project at hand equally—we both want the project to succeed. Because of that, our goals and concerns are the same.

Designers don’t want to build an app that runs slow because of agonizingly complex SQL. Coders don’t want to build an app that is hard to use. An incredible app requires both incredible code and incredible design. Without one, it’s not incredible.

Designers are tired of being the gatekeepers for visual detail and user experience. They’re tired of having to explain to the team that their concerns are not petty but are instead a major factor in a project’s success.

Coders are tired of dealing with designers who don’t understand how things get built. They’re tired of turning down silly features that have dire coding implications or are otherwise untenable.

Too often, designers and coders are at odds. Their interests compete. They disagree. If our goals are the same, the classic face-off between designers and coders needs to end.

The influx of coding designers proves we can do it. We can align our goals and start to alleviate all that mutual frustration by sharing our duties and skill sets.

Of course, specialization is important. If each of us were to just dabble in every possible skill rather than pursuing mastery, nothing would get done. However, we need to stop defining ourselves by too-narrow sets of concerns, and instead become well-rounded professionals who each excel in a specific area.

But there’s a problem: coders need to catch up. I could make a broad generalization that most coders don’t know about design, and it would be unfair but perhaps a tiny bit true. Instead, I’ll say that I don’t anecdotally know of many coders who understand even design basics. Do you?

Here is my plea: let’s all start learning about the opposite discipline and continue blurring the line between them. Designers: learn to code and understand why technical proficiency brings about great software. Coders: learn about design and understand why the little details affect the entire project. Let’s stop assuming our colleagues are out to undermine our interests and get on the same side.

Let’s stop being coders and designers—let’s become builders.

Value pricing

I wrote a guest post for A Smart Bear about how value pricing earned more money with fewer sales.

It’s a counterpoint to Sacha Greif’s post the previous week about the pricing strategy for his ebook. Since we both launched our design ebooks on the same day and used different pricing strategies, the comparison and ensuing discussion should be really interesting! A Smart Bear is one of the very few consistently good startup and marketing blogs. A sincere thanks to Jason Cohen for the chance to write there.

Go read it!

Reboot. Relaunch. Redesign. Pivot. Sunset. Shutter. The Knack, a web app, story.

Welcome. I’m kicking off my new blog with this post about the demise of my labor of love for over a year, Knack.

(Boring back story: I quit a full time job I loved when a freelance opportunity fell into my lap. It was my chance to strike out on my own. Building a web app on the side had been a goal ever since I read Getting Real, and this freelance project would fund it. I decided to design and build the thing myself after having friends and co-founders bail on me at various stages of 4 prior projects. The first version of Knack took me ~2 months to build, spread over 5 months of freelancing. Launch was August 2010. I worked on it another 4 months of the following year, and today I am shutting it down.)

Entrepreneurship, and the act of creation vs. the pit of despair!

My first year of entrepreneurship was spectacular and melodramatic. It was unlike anything else I have done in my life or my career. I made something awesome. Not everyone can say that.

Throughout the year after launch, I struggled to find users and make sales. I tried every marketing tactic I could afford. I wrote personal emails to bloggers asking for coverage, or at least feedback. I took a stance. (That teachers are unfairly blamed for the problems in education). I lucked out and had a chance to write about my stance for GOOD. My thoughts and writing were a bit undeveloped, but it was exciting. I got a few hundred visits. This was the high point of the year, and came a month or so after launch. It didn’t last long; the traffic stalled. I struggled to get users. I added features, relaunched, redesigned, repositioned. I rewrote the marketing website over and over. I ran Facebook, LinkedIn, StumpleUpon, and AdWords ads. I wrote link bait blog posts. I tweeted. I facebooked. Sent more emails. I offered free subscriptions to every teacher I met.

A few people loved what I had to say, but none of them used my web app. (Almost none.) Over the year I had about 120 free trial sign ups (100 of which I bought with AdWords), and a total of exactly 10 users who paid for at least one month. I lost about $2000 out of pocket, which I easily financed through freelance work. Monthly costs were about $150 total for my Braintree merchant account/gateway, Spreedly, and Heroku. The price in time was more substantial. Knack occupied about 6 months of work stretched out over more than a year. At my standard $100/hr rate, that’s $96,000 worth of work uncompensated. This figure is misleading and even deceptive, so let’s take it for what it is: a number I pulled out of thin air. (I don’t even make that much in a full year, much less 6 months.) That said, it does show how much effort I put into this app.

My great idea.

Knack was supposed be an alternative in an enterprise software dominated market. It would underdo the competition. It would save users measurable time every day. Knack would empower downtrodden educators who are blamed for the problems in the public education system.

My goal was to carve off a niche of young, tech-savvy educators who are passionate about education reform. I’d build an app for them. I wasn’t going to revolutionize an industry. I didn’t need every teacher everywhere to use it or even like it. Just a few.

I focused on building a great app. I reworked UI features until they were right—sometimes 4 or 5 times. I ignored the laundry list of standard features most gradebooks have, and just built what I knew teachers needed. The only blogger who graciously covered Knack called it a “beta version.” That stung, but it was fair. I had launched early on purpose, following the advice of tech industry maxims. I knew I could always fix it up later (and eventually I did).

I charged money for my software. I could not risk freemium and getting stuck with server bills I couldn’t afford for people who didn’t want to pay me. I set the price low—only $4.99/mo. That’s cheap for a web app.

The same month I launched, Learnboost, a funded silicon valley darling, launched too. I felt blindsided. Worried. Then I reread Getting Real and Rework. Learnboost had just validated my market, or so I thought. I put it out of my mind and kept working.

(More recently another funded app probably borrowed from my design. Quite a compliment. This event and my ensuing desperate tweets led me to Amy Hoy’s 30×500.)

I thought Knack was a viable business. It was the best work of my career, built for people who could reap tangible benefits. The hard truth that it was doomed from the start took that full year to set in.

Sometimes people don’t want their problems solved.

Before I built the app, I talked to friends and family who are educators. Trying to be supportive, they innocently told me what I wanted to hear. They didn’t know much about business or software. I didn’t know how to get real answers out of them. (Now that I’ve read Running Lean, I do.)

I should have done more research about teachers before I started coding. I thought what I’d learned was enough. There were quite a few online gradebooks that charged money and seemed to be healthy businesses. I had found research that said most teachers spend their own money on their classrooms. I asked educators I knew if they’d pay for a web app. None of this was enough. I didn’t learn about the simple psychology that drives teachers’ desires and purchasing decisions. I didn’t realize there is a stigma amongst teachers—that they deeply resent having to spend money on their classrooms and careers. Many businesses, both online and off, have special discounts and freebies for teachers. This has warped teachers’ sense of value and fostered a sense of entitlement. (Whether teachers deserve free stuff is a different debate. I personally don’t think anyone deserves a free lunch.)

Beyond this, I’ve learned that teachers do not want technology solutions for their everyday problems. Teachers say they love tech. Some blog about it. They tweet about it in #edchat and #edtech. They even coin their own special tech terms. (PLN anyone?) This is a farce. Talking about tech and being on the Twitter make teachers look good to administrators and to the public. They can add “Technology Committee Member” to their resumes and congratulate themselves for being innovative. But using tech to do work requires a small minimum of effort and change, and any amount of these is too much for teachers.

To be fair, teachers are really busy. A hell of a lot busier than you’d expect. Really. Visited a local school lately? Most teachers are busy putting out fires or trying not to get fired. (Or lose their collective bargaining rights.) I feel for them. I really do. But they’re still terrible customers.

We ruined the web.

Teachers and education are just one online market we ruined by giving everything away for free. I made the mistake of thinking I could carve off a little niche of teachers who were passionate about education reform. I couldn’t. You can’t either. Don’t waste your time on people who won’t pay. They aren’t going to change their minds.

People are going to comment and tell me mobile is our savior. That I should have built an iPad app. Those people are wrong. If mobile proves anything, it’s that technologists have a poor collective memory. We can build apps for every imagined need on every emergent platform. Just like we do on the web. We can create a boring app for every boring aspect of our boring lives, and then pat ourselves on the back just as each lands in the dead pool. We can even create a few good apps, but the majority of consumers will not assign monetary value to them. That’s the tech industry we earned, and it won’t change anytime soon.

(You could write me off as bitter. To be completely truthful, I’m not! I had a blast building Knack. I had to learn some lessons the hard way, but it was the best thing I’ve ever done.)

The way forward.

After a year, I ended up with around 10 Google Docs with variations of the titles “The Way Forward” or “Reboot.” They are filled with ideas of how I could pivot, respin, relaunch, better market, redesign, or add to my app. None of these could have saved Knack.

The way forward is without my great ideas or my selfish audience. The way forward is finding people who are willing to pay for an honest day of work. These people deserve my attention, and I deserve their money if I do a good job. (I’m going to.)