The blog of Method of Action

Unintended design legacies

Posted on August 7, 2013

The woman on the poster below, Geraldine Doyle, was a metal presser during World War II for two weeks. Yes, just two weeks. She was there when a photographer needed a face for an anti-strike poster. She left the job because, being a celo player, she didn’t want to hurt her hands. She was not a strong and feminist worker, but her image is.


Fun fact: The poster wouldn’t be noticed until the 80’s, when it became popular. Ms. Doyle didn’t discover it until she saw herself in a magazine.

Dr. Joseph Ignace Guillotin

Dr. Joseph Ignace Guillotin is remembered for one of the most ironic deaths on history, being executed by the machine he invented. Poor Joseph. He neither invent the guillotine nor was he executed by it.


Dr. Guillotin wanted prisioners to have a cleaner, less public death. He even was against death penalty. He helped improve the guillotine changing its direction from horizontal to vertical, succeeding to put it into use. At the time only royalty and high class members got to be killed without much pain.

Who knows. If the myth of him being killed by his machine wasn’t there maybe we wouldn’t even know his existence.

Eric Gill

Before I knew the details of the sexual activity of Eric Gill I was his fan. Now I’m only a fan of his work. Gill, the London underground typeface designer, was also a sculptor, stonecutter and printmaker. He was profoundly religious and his work was highly regarded in his time.

In 1989, biographer Fiona MacCarthy exposed Eric Gill’s “diary” (a detailed log of his life) where he records his sexual activity. He had committed adultery, incest with his sister and abused his children and the family dog.

Eric Gill

He would often use family members as models for his sculptures, carving his sister and brother-in-law in ecstasy. He would also draw his young daughter:

Do we like them –the drawings– the less knowing, as we know now, that during those years at Ditchling, Gill was habitually abusing his two elder daughters?

Fiona MacCarthy, Gill Sans biographer.

The drawings are well crafted, but their meaning has changed forever.

Victor Gruen

In 1941, socialist architect Victor Gruen started a firm in California. He was an Austrian born urban designer aspiring to bring european shopping culture to the US.

In 1955 he panned a full urban project involving houses, schools, medical facilities, an expansive garden with a lake, crowned by a shopping center. He hated cars and wanted people to foster a sense of community by enjoying nature while shopping. The result was Southdale Center the first indoor, multi-store shopping center in the US.


The project was so successful it was replicated in nearby cities, but malls morphed into a nightmare for Gruen: they were consumption centers isolated by vast parking lots. His ideal of community didn’t turn out as he expected and would leave for Austria in his later years.

I am often called the father of the shopping mall. I would like to take this opportunity to disclaim paternity once and for all. I refuse to pay alimony to those bastard developments. They destroyed our cities.

Victor Gruen

The cost of hustling

Posted on July 20, 2013


You’ve probably seen this diagram before. In theory, a hustler talks as much as he produces, a dynamite combination perfectly suited for the getting things done startup culture. In practice, most self professed hustlers I’ve met are neither good at talking nor doing.

Part of the problem, I suspect, lies in the multitasking nature of hustlers. You cannot reflect upon the effects of your talking if the rest of the time you are doing, and vice versa. However, there are many incredible doers that later became talkers (Marc Andreessen comes to mind).

Some time ago a person contacted me to inquire if I was available to customize Method Draw for his own needs. I let him know I was in the same situation as he was: bootstrapping my own company, giving it all the time I could carve out of my busy scale, so I was not available for contract work. At first he seemed to understand, but he pointed out an important bug and said that he was happy to pay me to fix it.

I conceded and said I would fix the bug, but without payment, as this would put me into a position of responsibility. The bug fix was delivered, but then he pressed on paying for more customizations. Again, I said no and suggested some developers well suited for the task.

This fell on deaf ears and yet again insisted on paying me to customize for his use case. This went back and forth four or five times until I then reminded him that I had made it very clear that I was not available, and that he was losing my time and his own by sending these constant emails. I let him know that I had set up a filter to route his email address to trash and that he would never hear about me again.

This is just one of many examples of people who take hustling to heart. I’ve had people propose me ideas for money, work in exchange unneeded perks, or stock in vapor companies in exchange for work. You probably have your own share of stories too.

The end result is costly: they’ve demonstrated they don’t value their own time, or mine. It’s the kind of people that prefer to mindlessly try and fail a thousand times than taking to time to think how they can have a better success rate.

People who just plow forward with the hustling mindset run the risk of burning bridges. Conventional wisdom says what’s the worst that can happen? That I get a no as a response. Actually, the more you insist the more you are putting your reputation at stake. People who don’t take no for an answer don’t respect the boundaries of your own personal liberty, and you should always avoid working for them.

A good hustler must consider that–if he has nothing to lose by asking–it might be because his self worth is nothing.

Our Server’s Hard Drive is Dead. We didn’t have a backup.

Posted on May 24, 2013

This is a long-winded post on how this came to happen. Jump to the TL;DR; if you want the summary.

Three years ago I was an interaction designer who did a bit of front-end. I felt comfortable in HTML, CSS and jQuery flavored JavaScript. I grew interested in programming as a to tool to build my ideas, but as I explored deeper I found that certain aspects of programming have a lot in common with design.

Throughout my professional career I’ve worked shoulder to shoulder with programmers. I’ve always admired their passion for their craft, I would often go to their meet-ups, and many of my close friends are programmers. I am a very analytical person and I think this puts us on the same wavelength.

I wanted a place where I could write about design for engineers, but design (just like programming) can’t be learned without practice. I wanted a website where I could teach design to programmers on my own terms, with built in tools to tackle little graphic challenges. Each challenge would be accompanied by a bit of design theory expressed in ways that would be understandable to a rational mind.

This was my dream and I was fortunate enough that my sentimental partner (also a designer) shared it, so we decided to make the jump and became business partners too.

How it started

We didn’t have enough capital to hire a programmer and I knew this would be an ongoing need, so I took a long overdue dive into programming. My JavaScript at the time was your typical jQuery spaghetti code, so this is in some ways worse than starting from scratch.

At some point we discussed that some design challenges were best expressed as games. A design challenge where you could kern in-browser wouldn’t be too difficult to implement in JavaScript, so why wait until Method of Action is released? The result was KernType. It went viral.

What followed came completely unexpected: people were signing up to be notified when released by the minute. After KernType we released two more games. All in all we got 30,000 notification sign-ups and 10,000 followers. Our games have been in the front page of Gizmodo, Metafilter, Boing Boing, Hacker News, Reddit and a couple of others. Marketing wise we were doing good.

Problem was: we didn’t have a product yet. Lean start-up right?

Learning Ruby on Rails

After a few failed attempts at completing Michael Hartl’s Ruby on Rails Tutorial, I sought the help of a Ivan, a talented Ruby programmer. I couldn’t hire Ivan fulltime, but I could hire him to teach me. The learning curve was steep. It’s not that any tech is particularly difficult, it’s that there’s just so much too learn.

It was an eye opening experience to development. I would describe my spec verbally (when a user receives three positive reviews his challenge is completed successfully) and we would write it down in RSpec. We would then make a couple tests pass and I’d take back home some pending tests.

The thing that isn’t obvious from the outside is that doing professional development requires a tremendous amount of knowledge if you mean to become a good full-stack engineer. This is what I had to learn and had no previous experience:

  • Ruby
  • Object Oriented Programming
  • Webservers (nginx + unicorn)
  • Sendmail
  • Chrome Developer Tools (beyond the web inspector)
  • MongoDB
  • Make
  • Bash Scripting
  • MVC

Ivan’s software development practices and Codeschool got me to the point where I knew enough programming to be dangerous. I just wish it wasn’t so literal.

Learning System Administration

My intention was to deploy to Heroku, but premature growth caused a problem I didn’t expect: I’d need a robust infrastructure to support all the people who where lined up for the beta. I found a powerful server with unlimited bandwidth at just $80 USD from 1&1.

We had chosen to bootstrap, so in the event of a massive influx of users I couldn’t just scale in the cloud because I could end up paying thousands of dollars per month, which was money we didn’t have. So a dedicated server seemed like a good idea.

In practice it was very painful. I had to compile nginx, install SSL certificates, open ports, tweak config files all over the place. I did some math and I found out that using a third party email delivery would be more expensive than the server itself, so I set up the infrastructure for delivering and receiving emails. I was overwhelmed. Just so much stuff to learn.

The release

We released the beta but we never announced it. We never sent out those 30,000 emails we were supposed to send. The reason was that it became popular without even trying, pretty soon we were inundated with challenges from users who had come across our website and signed up. Last count I made we were at 10,000 users without even announcing our launch.

What happened was that users were doing challenges, but they didn’t write reviews for other users. Kind of like a StackOverflow where everybody asks and nobody answers. The reward mechanics of the app were clearly at fault, the only reward for writing reviews was meaningless karma points.

We knew we had to fix the gamification system in order to balance the community, but suddenly reality hit us in the face like a brick: our runaway had been reduced to six months, which wasn’t enough to monetize the site and also fix the game mechanics. We began taking in client work again.

The downfall

We took part time client work which would extend our runaway indefinitely, but we couldn’t focus full time on Method of Action. The revenue was enough for paying ourselves a salary, but it wasn’t enough to hire someone else. We decided to make the beta private while we scrambled to gather enough resources to finance a round of development.

The fact that I didn’t have backups was in the back of my mind the entire time. When we soft launched I thought I would have enough time to learn how to properly back up the server, but in practice that time never came. Since there were no users writing reviews we tried to fill that gap while we fixed the mechanics. Our vector editor, Method Draw was drawing a lot of brainpower. Customer service. Unexpected downtimes. We were tired and overworked.

I know hard drives failures are just a matter of time, it’s just that I never expected that time to be so close.

Three days ago the server stopped responding. I restarted and it failed to come back. I booted in recovery mode, wrote fdisk –l. My heart sunk when the list was empty, I knew it had happened.

Technical support informed me that my first HD died 20 days into my contract. The backup HD hummed along for a year. I was oblivious to any sign that this was happening. I was spread too thin across all aspects of the product to notice, overwhelmed by two years of 60 hour work weeks.


We messed up bad. We launched without having a backup procedure in place, and without the resources to make it happen. This was a hard-learned lesson that won’t happen again. We have no one except ourselves to blame.

Your data is gone, and we are deeply sorry that your first forays into design have been lost. If there’s anything we can do for you please let us know.

What comes next

We need to get programming talent on-board. We believe in owning your product and make it happen with your own means. So venture capital is out of the question. We will release an iPad version of the Kerning Game, hopefully this will generate enough revenue to make it an attractive deal for a senior engineer or a technical co-founder.

Once the proper pieces are in place we will re-launch Method of Action.

This was a tremendously painful lesson and we will make sure it doesn’t happen again in the future. We are very sorry.

TechPlaya, the tech scene in Playa del Carmen

Posted on April 27, 2013

We moved to Playa del Carmen a year ago. Playa is a town along the Riviera Maya, near Cancun, Mexico. We started Method of Action here because it’s beautiful, cheaper than Europe, Canada or the US, and we have a well connected international airport nearby.

We soon realized we weren’t alone. Many people come on vacations, fall in love with Playa and think I could work from here. The tech community is small but interesting. We all know each other even if we come from different disciplines.

The Riviera Maya receives millions of visitors per year, some of them ought to be creatives, technologists and entrepreneurs. We created techplaya.com as a way to connect with like-minded individuals who come visiting.

The code behind techplaya is open source. If your local tech community is similar you are free to fork your own version in the github repository.

How memory works and why we don’t remember anything from yesterday’s test

Posted on April 8, 2013

We have trouble remembering topics for an exam because we use working memory. Working memory helps us remember information for a limited time. It’s different from short-term memory because it’s associated with cognitive development. Short-term memory holds around 7 items; hoever, working memory remembers more information that lasts longer.

Remembering is not learning

As a young student, my cousin used to study history linking every alliance/war with the personal life of the major characters in it, as if it were gossip. She still remembers almost everything. Memory contest participants use a similar method for associating memory:

A unit of working memory is best represented as a bundle of features. When two units share some features, one of them steals features from the other. When you try to recall that memory, oftentimes a second memory pops up because they have similarities. More items held in working memory causes more overlaps, causing interference and degrading your recall ability.

You probably are better at remembering the name of a person who has told you a story about him/herself. A name at the beginning of a conversation has no context, and thus is more difficult to remember.

Working memory is the first step to consolidate long-term memory.

Learning and long-term memory

Learning is a slower process than remembering, but it lasts longer.

If you focus on learning motor skills sequentially—for example, two different overhand ball throws—you will acquire each fairly quickly, but are more likely to forget them later. However, if you split your time up between learning multiple motor skills—say, learning two different throws—you will learn them more slowly but be more likely to remember them both later.

Regarding language, the odds of learning a new word rise when people surrounding us use it. It’s been discovered that we use the same part of the brain to speak and listen (except for the part linked to physical movements).

At a molecular level, memories are made of signals. Every time a neuron receives a new stimulus it will respond in different ways. As the stimulus is repeated, the neuron will start firing in more predictable and controller manner. Imagine this process with many neurons and you’ll have a long-term memory stored. Neurons are thrifty and they learn too. When you hear water flowing for the first time you must verify the source to find out that it’s a river. The second time you hear the same noise you will know there’s a river. After a few different rivers you would be able to estimate the flow of the river will be just from the sound.

What was your name again?

Learning and remembering are pretty difficult tasks. How about forgetting? Yeah, I also forget what I eat yesterday. Remember when I said the brain is thrifty? The brain doesn’t store short-memories for a long time. Yi Zhong of Tsinghua University and Cold Spring Harbor Laboratory, said about short-term memories “you need to remove memories for new information to come in. We’ve found that forgetting is an active process to remove memory”.

Yes, our brain forgets things on purpose.

Getting pre-launch traction with web games

Posted on April 9, 2012

The path travelled between an idea and a minimum viable product is often ruthless. Depending on the scope of your project, it takes between a couple of weeks and a couple of years to get anything out of the door. Few people possess the focus and determination required to get-to-launch, and I’m certainly not one of them. I have a graveyard of half baked ideas littering my hard drive, but Method of Action was something that I really wanted to deliver, so I knew I had to set some intermediate checkpoints before launching our own product.

I often describe Method of Action as an intersection between Codecademy and Project Euler, but for design. Every course has a series of challenges that you must achieve to complete the course. Most of the challenges are simple design tasks such as design a newsletter, or design a blog post, but some of the challenges are games that require you to achieve a minimum score.

Even though I set out the games as mini-launches that would help us maintain high spirits, their success caught me by surprise. Never in my wildest dreams I had imagined I’d have 20,000+ people to be notified when we launched, or 9,000 followers on Twitter. So I’m writing this out for fellow entrepreneurs who might want to take this approach for pre or post-launch marketing.

As a sidenote, I have a profound dislike for telling others what to do. Every startup has it’s own specific limitations, be it funding, location, market or talent. Your best course-of-action depends on your constraints. Please read this from where it comes: a two person bootstrapped team in the middle of nowhere where the only word-of-mouth marketing is going to come from what we do ourselves. The games are also part of our product, so even if we launch an unsuccessful game we are working towards the completion of our product.



KernType was our first and most successful game. It received more than 625,000 uniques in its first two weeks:


It was featured by some big names like Salon, Kottke, FastCo, BoingBoing and Computer Arts. This might seem like the brunt of the traffic, but if you actually look at the referrers, big name blogs don’t send that much traffic. Most of it comes from people sharing it on Twitter and Facebook.


To promote it we posted it on Hacker News and Reddit, and it quickly made it to the front-page of each site. From there it took life on its own.

A nice surprise was a site I had never heard about: Design Made in Germany. Fortunately they are not too strict about the Made in Germany part, because KernType was actually made in Cancún.

KernType took about two weeks part time to program. I am a terrible programmer and I’m sure any decent front-end programmer could have done it in half the time. Even though I used the Raphael library to get it done (which provides a single API for SVG and VML, which older versions of IE support), I just didn’t know how to get around some issues with Internet Explorer 8 and below, so I released it as a modern-browser game.

Funnily enough, I didn’t receive a single complaint about IE, but Android users were very vocal about their disappointment because older versions of Android don’t support SVG.



We were high on the success of KernType, so trying to take advantage of the momentum I quickly mocked up a new game where you control bezier curves to match the shape of a letter. We released it three weeks after KernType and promptly posted it to Reddit and Hacker News. Both tanked.


Fortunately it still took life on it’s own, and it was a moderate success on it’s own right. It had 300,000 uniques in little over two weeks, the big surprise now being StumbleUpon and Dirty.ru.


ShapeType took about one week to program. Even though it was more challenging than KernType I had gained fluency in Javascript, but my knowledge about geometry wasn’t up to par and I had to spend a lot of time learning about bezier curves and I struggled mightily with simple stuff like the Pythagoras Theorem.



We took a break from games for some time in order to focus on the actual product, it would give me time to think about the next game. We wanted to create something that unrelated with typography, so I brainstormed a bit with my co-founder (and partner) about our next step. We settled on a game of color.


Again, we posted it to Reddit and Hacker News where it quickly gained steam and went viral again. It had nearly 400,000 uniques in two weeks, this time the surprise came from Tumblr, which had even more referrals than Twitter.


Color burned me out a bit. We had mocked up the game mechanics for an initial game, and after two weeks I had a pretty functional prototype. The problem was that it was incredibly boring. Our previous games gave the sensation of creation, even if you are just moving letters or nodes around you end up with a nice looking result. With our initial prototype you would just click on colors and get a score, it felt too much like a quiz.

We went back to the drawing board and made some one-day iterations on ideas, but they turned out either too difficult to implement or too subjective to be scored automatically. We settled on what is essentially a timed color picker with some cool features, such as colorblind assistance. This time I used D3 in addition to Raphael. It took me an additional two weeks to push this out of the door, so in total I used four weeks part-time to launch this game.

The aftermath

The job isn’t finished once you release a game. There will be a couple of small bugs that often prove challenging to solve, or really good suggestions from users that we can’t help but implement. I have learned to set aside at least a week of answering e-mails and fixing stuff once we release a game. Having your inbox flooded and your Twitter popping up with mentions is quite distracting.

We have also received emails from design educators telling us how convenient our games are for teaching design concepts, which is very encouraging as we know we are on the right path.

All in all, we have amassed more than 2.1 million unique visitors; 200K FB likes and 200K tweets and we are very pleased with the results.


The accumulated referrals are quite a sight, the amount of traffic that social media sends our way is just mind blowing, it dwarfs the accumulated traffic from aggregators, which come in at a distant second


We have 20,000 sign-ups for people to be notified when we launch. The conversion rate is a bit on the low side, but it is deliberate as we didn’t want to push too hard on notifications. Method of Action will rely on community generated content, so the quality of our product depends on the quality of our users. I could have easily added a sign up form at the end of each game, but we linked to our landing page instead. By doing this we—hopefully—filter those truly interested learning about design.

What we did wrong

We discussed our last game too much before implementing it. I didn’t realize it, but pitching a game is a tricky proposition. If you think about it, Tetris is a puzzle where you must accommodate colored blocks to form lines. Angry Birds is a game where you sling birds into blocks, which then collapse to crush pigs. Doesn’t sound like too much fun.

There is no point in discussing how a game will work, unless it’s very similar to an existing game. It is better to simply implement your idea as soon as you can and iterate from there.

From a SEO perspective, another mistake was putting the games in their own subdomains. I believe that self-standing content that doesn’t share navigation or purpose is meant to have a different Top Level Domain, or if it’s related but not within your main audience or purpose then it should reside in it’s own subdomain. Domains such as store.diesel.com or developer.apple.com are good examples of this.

However our games are actually part of our product, so we should have used something such as http://method.ac/challenges/kerntype/. By not doing this we are missing out on a tremendous amount of PageRank.

How to create a successful game for your own product

Before Method of Action I used to create small games and quizzes for my personal blog (in Spanish). I’d read, for example, that people have trouble distinguishing people from a different race than their own, hence phrases like “all asians look alike”. So I would gather some pictures off a yearbook and implement the experiment in the browser. You can find the experiment here (Flash SWF, in Spanish). At the very least people were engaged with the quizzes and the point made was very clear, even for the most uninterested users.

What I gathered out of these little exercises is that any kind of information asymmetry can be leveraged into a game. Anything that you know and I ignore can be transformed into a pleasant learning experience.

  • You have a marketplace for used cars, you could present a photo different car models and let me guess the average price on your site.
  • You are a stock photo company, and suddenly there are big news about a celebrity. You could let users guess which photo is best-selling at the moment.
  • You are an architecture magazine with decades in circulation. You can show me photos of houses from old issues and let me guess the year of construction.

These are contrived examples, but I find them immensely more interesting than what big brands are doing today. They pay creative agencies tons of money for what is essentially a generic branded game that has little to do with their domain.

Show respect for your users

Edutainment has reputation as being boring, and for good reason. Most edutainment is mind-numbingly dull, and when you intersect edutainment with marketing it’s a recipe for disaster. One brand of dog food had a game where you had a virtual dog, you could feed it chicken, chocolate, or their own dog food. If you made the wrong choice (you can guess what), the app would lecture you on why it was wrong.

Users don’t want to be lectured, they want to be entertained. Even then, users hate wasting time. When I’m done playing a game I often feel remorse. I should have been doing more important stuff. When you throw education into the mix that feeling disappears because you are actually learning something.

You must also try to find the right difficulty level. I must confess we go by feeling, but it might be a good idea to test on a couple of users before releasing into the wild. A game that is too easy is a boring game, too challenging and your users feel annoyed.

Make it challenging for yourself

I have a developer friend from whom I learned one of the best lessons in programming: for every project you do, incorporate a technology or constraint which you haven’t used before. For KernType it was CoffeeScript and full keyboard support, for ShapeType it was geometry and seeing if I could produce something attractive with an ugly color scheme (still unsure if I succeeded with this!), for Color it was D3 and color blind assistance.

Incorporating new constraints and technologies added the right amount of challenge to the projects, it made them interesting without being frustrating. I have learned a lot along the way.

If you are a programmer you might be surprised to learn that none of the games use Object Oriented Programming, at all. My mind was damaged by Basic decades ago, and my toolset only includes functions, loops and conditions. I’ll make sure my next game uses OOP, even if this is not evident on the font-end it will hopefully improve my delivery times.

Every marketing approach burns out users

You might remember the time when apps used to be invite only, either because of real scaling concerns, policing on community quality, or just plain nasty artificial scarcity. It turned out to be a great marketing tool, people would give them out on their blogs, trade them in forums, or even sell them on eBay. Of course, that approach is now dead, and when I encounter one of these websites I promptly hit my back button.

Nowadays the craze is in the LaunchRock kind of invite: if you share it on Twitter and Facebook, you further along the queue. This approach worked for the first few startups to use it, but frankly users can only get so excited about a product that doesn’t exist yet. I get exasperated every time some of this spam shows up on my timeline.

I’m sure that if many startups used the game approach to launch, interest would decrease. A well made game has value in itself, but time is a limited resource and novelty would wear off, making it a losing proposition.

In summary

Make it entertaining for others, and challenging for yourself. Don’t lecture, entertain. Don’t push too hard on promoting your product, let the context do the promotion.

Color, a color matching game

Color is a new game for Method of Action.


Probably the most interesting aspect of the game is the color blind assist. Each primary color is represented by a geometric shape, and the morph between the shapes represent intermediate colors. Try it out even if you don’t have any color perception deficiency just to see how it works.

I will follow up with a post on how to choose a good color palette, check out how complementary, ternary and quaternary colors work because it’s important in choosing a good palette.

Check out color – a color matching game

You’re already a pretty good designer

Posted on July 27, 2011

I’m a seasoned hacker that is able to tackle immensely complex problems with aplomb. I’m able to untangle spaghetti code and weave it into beautiful patterns. I envision systems and code them with the same grace a jazz pianist improvises music.

But I can’t design for my life. Please help.

I’ve heard this story a couple of times in the ten years I’ve been working with programmers. Programming is a damn hard craft to learn. My mind is blown by the level of complexity software has achieved given the basic elements of programming—variables, conditions, loops, functions and objects. At times, it feels like you have a quarry, wood, rope, a saw, and a chisel and then an architect asks you to build a cathedral.

The programmers’ approach to building a cathedral would involve using his tools and raw materials in order to build more advanced objects. Let’s imagine the work of this craftsman: he’d grab some wood and stone in order to create a hammer, then he’d devise some pulleys to get rocks out of the quarry, he would build platforms and scaffolds to reach unaccessible places, he’d fabricate a crane to stack the stone, and so forth.

Our craftsman follows the architect’s plans religiously, and painstakingly chisels every stone so that every brick fits in perfectly. He polishes the wood into a huge sculpted door that would accommodate God himself. The massive columns wouldn’t fall in a thousand years.

Once finished, he steps back and mesmerized by the beauty of it all, he thinks ‘Hey, I built this cathedral all by myself, perhaps if I tried designing my own cathedral I’d get all the praise, instead of this lazy hack who just handed me the layout and waited for it to be built’.

Of course, when a programmer first tries his own hand at designing, he will likely notice that it looks pretty clumsy, there are a couple of reasons for this, but—all in all—the odds are stacked in his favor. It is absolutely necessary to identify the shortcomings of the programmers’ mindset in order to overcome these obstacles. Later on I’ll detail what works out in his favor.

1. Being familiar with the implementation difficulty encourages compromises

I’m a designer by trade, I have a degree in Information Design. But—as often happens— ignorance instills confidence, and I jumped into programming expecting it to be a challenging hobby, but it actually sucks you in and you come out a different person. I’m not a competent programmer by any measure, but it is an activity I enjoy throughly. I’ve built memela.com entirely on my own, you can also see my portfolio. Here is my StackOverflow profile. The paradox of learning is that the field is just so huge that you must admit you’re not able to master it in your entire lifetime.

When I first started programming, I’d start sketching a general idea on paper, and when I’d grow bored of it, I’d jump into Textmate and bang some code. Sometimes I’d encounter that a particular feature was difficult to implement, so I’d go back to my sketch and rework it so it was easier to implement, even if the user experience suffered in the process.

This, I think, is the biggest mistake programmers make when designing their own products. This is a form of technical debt that is incredibly expensive if done repeatedly, but it’s very tempting when you’ve been struggling with a particular problem for some time.

Nowadays I separate the designing and programming phases completely. I start by sketching on paper, then create a pixel perfect mock-up and then I finally start programming. If there is something that I find hard to implement, I ask for help, making me a better programmer in the process.

The equivalent of our medieval craftsman would be noticing that the doors of the cathedral are a lot of work, so he replaces it with a standard sized door. Soon enough the cathedral is inaugurated and there’s an unsurmountable bottleneck when the crowd tries to enter the cathedral.

2. Data modeling clouds your understanding of use cases and tasks

Nailing the data models is the hallmark of a competent software architect. It sets the foundation for clean, understandable code. Unfortunately, it also provides a data centric view of the entire project; and when the software architect designs the graphical interface, it looks a hell lot like the models with a CRUD interface slapped on.

Programmers get a lot of unjustified heat for designing these kind of interfaces. Very few people understand why data modeling shapes a very strong mental model of how the interface should work. This problem is often painfully obvious in backend administration systems, where the programmer is left on his own because designers are busy on the public side of the application. Often programmers rely on automated admin tools because—despite being a crucial component—clients don’t want to pay for it.

The key to escaping mental model contamination is thinking in terms of use cases and tasks. Whereas duplication and redundancy are the bane of good data models, it often is the opposite for use cases. In some supermarkets you will find mayo next to the tuna, a cereal island next to the milk refrigerators, and Clamato next to vodka (as well as in the usual places). Let me use information where I need it, not where the data model dictates it should be.

3. Most design is written about and taught from the perspective of art

When I was younger I would ask people how to dance, they would often suggest to “feel the music”. Once you feel the music you can start moving your body along with the rhythm, or so they said. “Just tell me how to move my feet and my arms”, this would invariably turn out wrong, because I’d just flail my arms at my own pace. A sad spectacle that I’d prefer to forget.

It wasn’t until the Rockstar type of games started coming out that I finally understood what they meant by feeling the rhythm. There is a bass that marks the predominant rhythm and some other instrument that marks a secondary rhythm. You pace a range of pre-defined movements to these instruments and boom, you’re dancing half decently. But alas, this revelation came too late and I’m still a terrible dancer.

Perhaps you have already asked a designer where to get started with design. I’m pretty sure his advice was to observe things carefully, notice the details, copy things you like to understand how they work. This is good advice, but it’s the same thing you would tell someone learning how to draw.

This is what I call art oriented advice and it’s the same kind of advice I was being dispensed when I asked how to dance. It’s useless to logical minds because when you like something you just don’t know what you’re supposed to be looking at. It comes naturally to people who have some art experience because they are used to observing proportion and balance.

People often make of design some sort commercial spawn of art. It is not. Design is a discipline in itself, related to engineering, that uses some of art’s syntax (in the case of visual design). It is different from engineering in the sense that engineering looks after the efficiency and robustness the product, and design looks at the interaction between the product and a human being.

Now, let’s get to the good stuff:

You are already a pretty good designer

If you have been programming for a number of years, you probably have very good design and architectural coding skills. These skills are connected to visual design at a high level of abstraction. The connections are so strong you can face off two masters of their own field and it will make sense to senior designers and programmers alike. In fact, I’m going to face Edsger Dijkstra against Charles Eames .

Design depends largely on constraints.

The ability of discerning high quality unavoidably implies the ability of identifying shortcomings.

Innovate as a last resort.

The competent programmer […] avoids clever tricks like the plague.

Who ever said that pleasure wasn’t functional?

There should be no such thing as boring mathematics.

Everything you already know about design and architecture in programming can be applied readily to visual design, with few exceptions. The problem is that your skill set is domain specific. You don’t have the bridge to apply what you know about software design into visual design.

You are already creative

Perhaps you have bought into the bullshit that creativity is a state of mind, an eureka moment that bursts into flash of brilliance to produce something that has never been done before.

I’d go as far as saying that the popular conception of creativity is actually harmful to good design, as it relies on established conventions in order to function. There is a time and moment to innovate, but it should never be done for innovation’s sake.

Creativity is being able to create things. Objects that can be shown, discussed and built upon. In this sense programmers are much more creative than many so called creative professionals out there.

Your systematic mind can be used to your own advantage

One of the most difficult concepts to teach young aspiring designers is the ability to think in systems. If I requested a button in 99designs (without more context), people would jump at the chance of creating shiny realistic buttons. You probably know what is wrong with this scenario: you can’t design a button without knowing how the rest of the design looks.

This is something that takes many years to mature in a designer, because the relationship between visual elements is not as obvious as it is in code. I’m not only talking about consistency, but the profound understanding that each element competes for attention, and that by making an unimportant element “shine” you are detracting from the rest of the elements.

You already have attention to detail

In a scale from 1 to 10, how sinful is choosing a poor name for a variable?
Now, in the same scale, what number would you chose for code where every variable had an awkward name?

This is attention to detail. Knowing that the details make the product itself. I’m constantly amazed by the discipline of some programmers, their code is carefully formatted, comments are succinct, and the structure is evident by just looking at it.

So, how do you get started learning design?

Design education is quite different from other disciplines. It needs to be so, because design is concerned as much with skill acquisition as it is with knowledge acquisition. It is project oriented, because that is how design is professionally articulated. Design is not subjective, as people often say, it’s meant to solve a problem, and the problem may have different solutions, some better than the others.

The actual structure of design education is centered around the design critique: the teacher explains some concepts, then asks his students to articulate something visual around those concepts adding some constraints, and then the final work is discussed as a group.

The actual critique mechanics are quite interesting. Every student lays their work on a large table, and the teacher will chose one, and ask other students what they think about it. At this point, authorship isn’t important. It’s likely the teacher and his peers don’t know who made it. The objective is not criticizing the student, it’s criticizing the piece of work. So a student volunteers an opinion, and the teacher validates it. After a small round of opinions, the teacher gives some insight and moves on to the next piece.

I’ve been thinking long and hard on how to replicate this experience online in a way that scales. I’ll extend it to other disciplines, but the initial course will be on design for programmers. If you are interested sign up to be notified when we launch, or just follow our Twitter. We will be writing more on this blog about the relationship between design and programming. Keep tuned.

The racial performance gap explained

Posted on July 26, 2011

In 1974 Phillip Uri Treisman, a calculus teacher at Berkeley, received the visit of two graduate students. The purpose of their visit was to videotape Prof. Treisman’s class.

He had been rated as either one of the ten best or ten worst teachers in Berkeley, and he didn’t know which. They wanted to study if other teachers could identify good teachers from the bad ones. Prof. Treisman couldn’t know if he was in the top or bottom 10.

Prof. Treisman had been had been trying to get his students interested in Math through collaboration and creative problem solving, innovative techniques at the time. The students had met his experiments with certain reluctance: “is this going to be on the test?” they would ask. He had no idea if he was a good or a bad teacher.

Turns out he was one of the good ones, as he was given a grant to study why there was a performance gap in Black and Hispanic students. It was a problem that had been bothering some time, and he was willing to tackle it head on.

He would start by surveying his colleagues for possible hypothesis, and he found four widely-held beliefs:

  1. Minority students are not as motivated as other groups
  2. They come unprepared, as they often enter university with fewer credit hours of science and math.
  3. Their families lack a strong cultural and intellectual background, and thus lack understanding of the importance of higher education.
  4. That the income gap reflects on the educational gap, and if those variables are controlled there would be no performance gap.

All these beliefs sound reasonable, however, when they started looking at actual data, they noticed they were entirely wrong. Being an elite university, minority students, especially black students, had to make huge social sacrifices to be able to get accepted into Berkeley. Motivation was not the problem, it was disorientation.

They were also surprised to find that, among Black students, calculus grades correlated negatively with good math grades in high school. Black men with high SATs often faced academic dismissal. It was the students in the middle range who were the best math students in university.

They interviewed the families of the students to find if that was the cause of their poor performance. What they found was a strong network of support, that they had made a conscious effort into getting their kids into college, and quite a few of them were college graduates too.

Perhaps the most unexpected finding was that family income was negatively correlated with performance. This is because many of the poorest students come from families where the parents would work in public schools and don’t earn much, but had a long standing tradition of education.

So, after going through all the data and interviews, they were at a blank state again. They decided to do some ethnographic research: follow the students around, videotape them in the least conspicuous way possible, let them grow to their presence.

So they decided to follow a group of Chinese students and a group of Black students. Black students would go to class, take notes, study eight hours per week, and then fail. What was surprising was the difference they saw with the Chinese students:

They studied calculus for about 14 hours a week. They would put in 8 to 10 hours working alone. In the evenings, they would get together. They might make a meal together and then sit and eat or go over the homework assignment. They would check each others’ answers and each others’ English. If one student got an answer of “pi” and all the other got an an answer of “82”, the first student knew that he or she was probably wrong.

It was interesting to see how the Chinese students learned from each other. The would edit one another’s solutions. A cousin or an older brother would come in and test them. They would regularly work problems from old exams, which are kept in public file in the library.

Based on these findings, Prof. Treisman obtained funding for creating what was essentially a “learning group”. Berkeley had previously tried to enroll minority students in optional preparation courses, but he knew that minority students dismissed them as something for underperforming students.

His learning group was—in essence—a place to tackle problems to together.

Most visitors to the program thought that the heart of our project was group learning. They were impressed by the enthusiasm of the students and the intensity of their interactions as they collectively attacked challenging problems. But the real core was the problem sets which drove group interaction. One of the greatest challenges that we faced and still face today was figuring out suitable mathematical tasks for the students that not only would help them to crystalize their emerging understanding of the calculus, but that would show them the beauty of the subject.

We were able to convoke the students in our orientation that success in college would require them to work with their peers, to create for themselves a community based on shared intellectual interests and common professional aims. However, it took some doing to teach them how to work together. After that, it was really rather elementary pedagogy.

The results of this program were surprising: Black and Latino participants outperformed not only their minority peers, but their White and Asian classmates as well. Black students with Math SAT scores in the low-600s were performing comparably to White and Asian students whose Math SATs where in the mid-700s.

Here is Prof. Treisman’s first hand ccount (PDF) if you’re interested in learning more.