Markerboard mentality is all about encouraging people who make things to identify problems, objectives, strategies and solutions from the abstract vantage point first. The point is to encourage software designers and developers to rethink their initial strategy for approaching a problem that needs solved.
The temptation for people who build solutions (whether code based solutions or design based solutions) is focusing on the details execution and implementation details first, when the best way to tackle a challenge is often from a higher, more abstract vantage point.
This talk was given at CPOSC 2013, and based on this article: http://joelglovier.com/writing/2013/markerboard-mentality/
TRANSCRIPT:
# Markerboard Mentality
_[slide 1: talk title: "Product Design and Markerboard Mentality"]_
_[slide 2: name & twitter handle]_
I'm Joel Glovier - "jglover" on twitter, so if you have any questions or thoughts about today find me there and we can talk more. I love what we do in this industry and I love talking to people about what we do, so let's have conversation.
_[slide 3: GitHub logo]_
I work at GitHub where I'm a front-end designer. At GitHub we make tools to help developers work better together. [Question] Just out of curiosity how many people are using GitHub?
We're known for a lot of things at GitHub, including:
_[slide 4: octocat]_
- **the OctoCat**. This is Mona Lisa Octocat for those who'd on't know her name.
_[slide 5: drinkups ]_
- **Drinkups**, where we bring smart people together in their communities and talk code with them.
_[slide 6: creating git ]_
- **Creating Git**
_[slide 7: Linus Torvalds]_
- …which is totally not true: Linus Torvalds actually created Git, born out of the Linux community where there was a specific need for distributed version control, and for which we are very grateful.
_[slide 8: "Asynchonous culture" - explain hubot]_
- **Asynchronous culture** That guy there is Hubot. If you were in Scott Robert’s talk about an hour ago you heard him talk a lot about Hubot and how we use him at GitHub for all sorts of things like deploying GitHub.com the website, etc.
_[slide 9: currently 62% of our 215 team members are remote ]_
_[slide 10: quote mission statement]_
- Our mission: Making it easier for people to work together than alone. That’s our mission, and that’s one of the things I love most about GitHub.
_[slide 11: office shot]_
I work remotely from my home office in Mechanicsburg.
_[slide 12: Markerboard slide]_
…and in my office I have a markerboard.
_[slide 13: Mac slide]_
…I also have a Macbook Air with the usual designer and developer apps like Photoshop, Illustrator, Balsamiq, Sublime Text, iTerm.
_[slide 14: Moleskine slide]_
And of course, I even have a Moleskine where I can prove how hipster I am between it's leather bound pages where I sketch UI layouts, logo designs, and t-shirt artwork.
_[slide 15: Me at markerboard]_
But I prefer to start most projects on the markerboard.
Sometimes, instead of the markerboard, I'll use some scratchpaper - either from my printer, or from a little pile of cut up sheets of paper I have on my desk.
_[slide 16: question]_
Do you know what the markerboard and the scratchpaper have in common that Photoshop, Balsamiq, my code editor and the Moleskine don't?
_[slide 17: "Temporality."]_
Temporality.
_[slide 18: Temporality points A]_
The markerboard and the scratch paper are temporal mediums.
They're disposable.
And they start with the assumption that what I create on them will be disposed of, not saved. It puts my mind in a state where I can spend my ideas freely.
**[illustration: disposable products]**
_[slide 19: Displosable cups]_
Think about your Labor Day weekend. There's a good chance if you're like a lot of Americans you had a cookout with friends, and might have had some drinks there. And probably used a few of these bad boys. The ubiquitous Solo brand disposable cup - or some generic version of the red disposable cup.
Now think for a moment about how we use disposable cups. Totally different context but similar dynamics at play.
Because you know they are intended to be thrown away after use, you don't think twice about doing just that. And you use as many as you need, because they're expendable.
And you don't see anyone saving them and washing them and reusing them (unless you're my mom), we just use them and discard them, and it actually has an affect on how we consume the beverages we drink from them.
It's the same way with temporal mediums like the markerboard and scratch paper when we are thinking strategically about our work. Because these mediums are temporal, we tend to spend our ideas more freely when know that what we are doing isn't necessarily permanent and set it stone.
And that process of getting out as many ideas as possible - spending our ideas freely - tends to bring the best ideas to the surface.
When we know that our initial ideas will be disposed of, and replaced with better ones, we're preparing our minds to iterate.
**[/illustration]**
_[slide 20: Temporality points B]_
These mediums I'm talking about also have another benefit related to their temporal, disposable nature: they facilitate discussion, not execution. In other words, they are about solving the "what", not the "how".
_[slide 21: execution, strategy]_
Too often we as designers and engineers, we instinctively start with execution, then worry about the content or the strategy after an idea for execution has been established.
What happens is we end up creating a framework for solutions first, then fitting the strategy into our framework - which in reality is putting the cart before the horse.
_[slide 22: X]_
_[slide 23: strategy, execution]_
Starting with disposable mediums lends itself to keeping initial ideas and direction to the strategic level. It facilitates the discussion that must take place before a framework for execution is ever considered.
_[slide 24: star]_
And of course, they do blend together at times. Is it possible to use a disposable medium like a markerboard or scrap paper to start hashing out your visual execution or a strategy for your app's architecture? Of course it is.
_[slide 25: Markerboard Mentality is about:]_
And I'm not proposing these tools should never be used for the purpose of brainstorming specific execution related details. What I am advocating for are two things:
_[slide 26: "Start a discussion first"]_
1. Starting A Discussion First.
View your work through the lens of a problem solver creating a solution, not just as a designer creating a visual work, or an engineer building scalable architecture.
Start to think of yourself as creating conceptual solutions that just happen to be manifested through a visual skin or a code structure, and you'll begin to understand the necessity of solving the problem independent of the visual design or the code structure that the solution takes on.
_[slide needed]_
The benefit of using temporal mediums is that it forces you to start to abstract yourself away from the specific details we tend to get caught up in due to *fidelity*. The low-fi nature of those tools tends to force us to think more objectively about the solution we are trying to accomplish, as opposed to rounded corners and drop shadows, or javascript libraries and CSS preprocessors that we tend to get caught up in with our hi-fidelity tools.
_[slide needed]_
The point is NOT that you need to use a markerboard or scrap paper to start your projects.
The point is that you need to use your conceptual thinking cap first to start a discussion about the nature of the problem and what the solution should be like independent from the aspects of implementation it will ultimately take on.
_[slide needed]_
_[slide 27: "Prepare to Iterate"]_
2. Prepare Yourself To Iterate
The other benefit in tools that produce disposable output is that they help us to realize where we are in the process: the beginning.
_[slide needed]_
Often we stumble on a singular piece of the puzzle and try to use it to craft the rest of the solution.
In reality there are **many** aspects to a good solution that must all come together to form the final product. You can no more design an entire web application based around a single button treatment, or javascript library than you can design an entire building from a certain style of staircase.
_[slide needed]_
But far too often that's how we treat the process. Finding some isolated piece of inspiration, or tool that provides built in solutions and allowing that to dictate the tone of the entire project. When in reality we need to be willing to let go of our initial ideas as the creative process unfolds and uncovers challenges and solutions unique to our own projects.
**[illustration: Wordpress]**
_[slide 28: Wordpress logo]_
I used to do this all the time with Wordpress. Wordpress is a great tool that solves a lot of problems for you just by choosing to use it as your framework.
I used to do a lot of Wordpress development - partly because it was a tool I had learned to use and I wanted to leverage it's strengths. We all do that, that's how you use tools. But also partly because my ability to work with scripting languages beyond basic PHP for Wordpress was really low. So Wordpress became a crutch.
_[slide needed]_
So I would often approach projects with the assumption that Wordpress was going to be the way I solved the problem of backend architecture.
The problem with that is that Wordpress is really good at somethings, and really crappy at others, but I wasn't thinking about whether Wordpress was the right solution for the project, I was assuming it was the solution I was going to use and fitting the projects into my solution.
And that type of approach doesn't always make for great products. In fact, it often makes for a really crappy one.
_[slide needed]_
**[/illustration]**
And Wordpress isn't the only culprit - we do this all the time with the tools we are most comfortable with or familiar with.
_[slide 29: all logos]_
How many of you use any of these tools? Do you ever find yourself assuming the solution from the tool without first considering if it's the right tool just because it's the one you are most comfortable with or familiar with?
In order to make great products, we have to iterate. And in order to iterate well, we need to be prepared to iterate. And that comes from starting from first principles.
Now to be clear, I'm not attacking people who choose an area of specialization that revolves around a specific tool. Specializing is great. What I **am** attacking is where we get lazy and allow our specializations to keep us from digging deep into the problem we have to solve and fully understanding it.
_[slide 30: Problem solving]_
This thing I'm calling "marker board mentality" is really just problem solving thinking. It's understanding that solving problems doesn't just happen from doing, it happens from stopping and taking time to think about and truly understand the problems we are trying to solve.
It's understanding that at the core, the skill sets we practice - design, engineering - they are only valuable because we are building solutions to an actual problem. And understanding that problem is directly connected to our ability to create a solution for it.
And it's taking time to think about the problem we are trying to solve from first principles, discussing them and exploring all the potential solutions, and iterating on whatever we come up with because we realize that until we fully understand the problems we are trying to solve, we'll never make great solutions for them.
_[slide 31: thank you]_
_[slide 32: twitter handle "lets talk more"]_
_[Discussion: Can anyone talk about how you practice "marker board mentality" and think through and understand problems? What specific techniques do you use to keep from getting too focused on the specifics of implementation before you have really thought through the whole problem?]_
jglovier
base
crboy
sms_tech
cpineda57
zozodevelopers
nathanacurtis
elrns88
elsh
ashapiro
minamitary
gdgmontreal
tokimari
colly
sergeychernyshev
garrettdimon
trishagee
marcduiker
speakerdeck
brettharned
shpigford
davidbonilla
andyhume
zakiyama
erikaheidi
