Since 2008, I have been tasked with designing and UX testing the entire website for my first startup. From the outside, Skritter is pretty simple, it's a website that teaches students of Chinese and Japanese to better learn and remember their characters. Basically a flashcard program for Chinese and Japanese.
Seems pretty simple, right?
Well, not at all, actually. The problem is that Skritter uses a spaced repetition algorithm that makes it non-obvious to add and manage vocabulary. Unlike a standard flashcard program, you don't just add words to your library, the application does that for you gradually, as you learn and remember more content. So on Skritter, you can't "study" a list, you have to "start adding from" a list. The difference creates all sorts of problems for users. Where are you in the list? What haven't you learned yet? When you stop adding from a list, should we remove all the material you've already added? Spaced repetition makes Skritter powerful and useful, but at the cost of simplicity.
For years I railed against this unintuive aspect of our product. Apple, Dropbox, and a hundred other companies were making it big by making it simple. Although Skritter eventually became a big success, it took a while for people to "get it" and it was an exercise in frustration for me as the product designer.
So I was thrilled to start work on a new startup in 2013. CodeCombat offered me the opportunity to build upon the design lessons learned at Skritter, but in a different arena: game design. We were making a game that taught users to write JavaScript.
Sounds pretty simple, right?
Not at all. Although there are hundreds of educational games teaching everything from typing to math, surprisingly few teach users to code. And those that do serve more as antipatterns than examples of successful design. For CodeCombat, we couldn't just rely on typical game mechanics, because we were supposed to be teaching users how to code the very behaviors most games take for granted like move up, for instance. As a result, simple things like unit selection, setting waypoints, choosing actions, and resource allocation turn into non-obvious design conundrums.
When I was working on Skritter, I used to think, "Someday I'll be able to work on a product that's simple and obvious, boy that'll be sweet." But CodeCombat taught me is that if you aren't running into seemingly intractable design problems, that's a strong indicator the product isn't solving real problems.
There are products out there that won by simplifying a complex problem; perhaps it's file uploads, or listening to music, or sharing photos with friends. But it's a mistake to assume that because the end result is simple that it was simple to design. As Apple has proven time and time again, making things simple is extremely difficult.
So, if your startup isn't solving an intractable design problem, find one.