Over the past year, there’s been a lot of talk about how everyone should learn to program. I’ve heard some good arguments either way. As a lifelong programmer, I’m all for this. But programming is making, and if you want to achieve specific results or outcomes, basic design thinking can go a long way, and I’d love to see a similar push for democratization of literacy in design thinking. There are two recent examples where I think a little more design literacy could have helped.
Lesson 1: design is not about pretty or shitty. Despite its brevity, this Venture Beat article (“Screw Design and Get Data“) can’t seem to make up its mind about the definition of design. Ben Huh, CEO of the Cheezburger network, is not saying design is unimportant. His point is that for their customer and business needs, they prioritize data collection and analysis over the aesthetic appeal of the site. As a data-driven company, you can be sure that if they identify a page component is leading to bounces (exits from the site), they will make modifications to change that behavior. That’s design, and Huh says as much:
“When making design changes, Huh said, Cheezburger looks at four things: desired outcome (business outcomes, not warm and fuzzies), intended user, data on the existing condition, and data on the new condition when the company retests for validity.”
This is not too dissimilar from the process of design thinking which includes extensive research, testing, implementation and iteration using lessons learned from each step.
In closing, the author paraphrases Huh with “you don’t need great design to have a successful design.” My takeaway is not “screw design,” but rather you don’t need beautiful aesthetics to have a successful product. Design is the process by which you determine what successful is and how to achieve it. Obviously Huh gets this, but he and the author’s expression of design in this context is muddied.
Lesson 2: ignore design thinking at your own peril. As we build products, objects, applications or services, we constantly make decisions, and we bear responsibility for the consequences and impacts of them. Dalton Caldwell is hoping that his new service, App.net, will become an alternative to Twitter as users and developers become discontent with increasingly restrictive Twitter policies. In order to avoid repeating Twitter’s mistakes, Caldwell felt is was important for people to pay for the service, rather than be beholden to advertisers. So in addition to designing APIs, documentation, and the other parts of the new platform, he had to design a business model that would help pay for it. He used a Kickstarter type of model where users paid $50/year in advance, and developers paid $100/year in advance.
Caldwell has documented how he arrived at those price tiers (See the FAQ section on this page), but some are wondering if that pricing is creating a “gated community” or “country club” of mostly white, male and technically privileged users. The debate centers around whether the current demographic of App.net is a reflection of early adopters and societal disparity in general, or if the structure itself is creating this. Jamelle Bouie sums it up nicely:
“In a world of huge racial and class disparities, ostensibly neutral procedures and parameters can yield non-neutral results…. App.net wasn’t envisioned as a service of mostly white, mostly male, and mostly affluent people, but the conditions of its creation have created exactly that.”
I agree that App.net wasn’t envisioned as a country club, but I would also argue that the if you are creating a social network, you must consider the type of community you are trying to build. App.net is very early stage, and is very much a prototype, so in that sense, they have time to adjust and learn from this feedback—which is very much part of the design process. Sadly, some initial reactions are to take this as criticism of intent rather than early warning signals to recheck design assumptions.
By bringing design thinking into the creation process, we can move beyond thinking of design as a concept about visual appeal, but rather as a process, not an end result. Additionally, this understanding could help communities talk more constructively about the consequences of decisions and then move to mitigate them, rather than argue over their intentions.
Any easy way you can do this right now is to start getting more feedback. Try to remember what seemed like an innocuous decision you recently made in creating something (a product, document, service, object, etc). Then think of someone who uses or is affected by your creation. Tell them what the options were and how you arrived at your decision. Ask them how that affected them. Would they have made the same decision, or picked something you didn’t even consider?
This is a great start to get beyond the preconception of design as the end result, but as a process to help you achieve desirable outcomes and avoid unintended consequences.