I'm on Twitter, @weesie_b,
and I'm from Colorado so I have to use
mountain pictures everywhere I can.
So, I'm a developer and a designer at Haught Codeworks
and we're a small consultancy
based out of Longmont, Colorado.
And I'm a chapter leader for Girl Develop It - Boulder.
(light applause)
Woo! (laughs)
And then, before we get started,
I just wanna really quickly run through
how I've set up my slides.
So, as you may know, we are in Texas right now
and Texas has some famous cows.
And cows need cowboys,
and cowboys ride horses.
And horses are a lot like ponies.
And I drew a lot of ponies for my slide deck.
(audience laughs)
So, now that that's taken care of,
we can go ahead and get started and talk about design.
So, unlike the popular perception of what design means,
it's actually much bigger than the elements to come together
to form what we typically associate with visual design.
So, typography, color palettes and layout.
I think designers often get a bad rap
for being overly sentimental about these things.
And even though they may have a slightly unhealthy fixation
on letter forms, these elements really are just details
of what a designer's job is
and don't encompass the full breadth
of what design is actually all about.
So, at its core, design requires the ability
to take a set of restrictions framing a problem
and find the best solution within those limitations
to maximize impact, usability and engagement with users.
So, design is all about people
and it's about how the things
those people need actually work.
So, has anyone here every built something
that was super cool but then turned out
to be pretty challenging for the people
that you shared it with to use?
I know I have.
I have, it's happened.
And maybe your app was so challenging to use
that those people just didn't use it
and they just didn't understand something that,
from your perspective, made perfect sense.
And that's a pretty frustrating experience, right?
It's not fun to have something
you've put a lot of effort into
not really be appreciated or understood.
But there's a silver lining to going through that
because it is actually a great thing to have experienced.
So, going through the process
of seeing first-hand what happens
when someone doesn't understand
or relate to your thought process
and then, by association, doesn't understand your product
means that you've taken the first step.
And welcome to design.
So, it's a glorious place where you get to build cool stuff
by figuring out how to make things
that are relevant and useful to other humans.
So, clearly, the code that you write is important
when you're building software,
but design is just as critical a component.
And this is because products that offer unique
and effective solutions to human problems
that are also intuitive for users
to understand and relate to
really set themselves apart from the crowd of competitors.
So, how many times have you heard
something along the lines of, "It's like Twitter for cats,"
or, "it's Uber for dog-walking"?
And this is because coming up
with original ideas is really hard.
And it's easier not to and, instead,
just use established, successful products
like Twitter and Uber as a starting point
and then just tweak them enough to make them yours.
And this isn't always a bad approach,
but what it means is that, if you can came up with something
that's unexpected and better than those established models
of solving users' problems,
that it's going to really get people's attention.
And creative design solutions are a major deciding factor
in the choices that lead to those novel approaches.
So, since design and creative thinking is something
that can be a big part of what sets you
and your work apart from the crowd,
how many of you consider yourself to be creative?
Okay, awesome.
Now, how many of you think of yourselves as designers?
A few, okay. That's good, a few.
So, I really wanna help everyone in this room
feel like they have the ability to be creative
and then also to participate in the design process
and to feel like they can make positive design contributions
to their teams and their projects.
And so, on that note, I think it's a good time for a story.
So, I went through one
of Jeff Casimir's early developer training programs
before he started Turing School of Software & Design
and I have this very distinct memory
of him telling our class that we were not allowed
to use Bootstrap to build out
the front ends of our projects
that we'd be presenting at our demo nights
because Bootstrap would, in his words,
"Make it too easy to win."
And he told us this a day or something right before the demo
and it was followed by this sort of giant collective groan
throughout the class
because we really hadn't been learning about front end
and Bootstrap would be a time-
and sort of sanity-saving resource that we could use
to make things look okay (laughs)
while we were just focusing
on getting our projects to actually work
and then getting them successfully deployed on time.
And then, just like that,
he just was taking it away from us
because it made it too easy to win.
So, chew on that for a second.
We had spent months writing and studying Ruby
and now we were building these Greenfield Rails apps
in very short timelines and showing them to people
who could very well turn into our employers.
And what, of all things, is Jeff worried about teams using
to their unfair advantage?
A tool that gives you just a little bit of help
with very basic visual design.
So, we were building complex back end systems
and that was what we really wanted to show off, right?
Why would getting some outside help
polishing the user-facing part of the app be such an issue?
He was justifiably worried that teams would use
a clean-looking user-facing product
to compensate for crummy back end code.
And he was worried that teams
that only got the minimum project requirements completed
would sway the crowd with a slick-looking front end
while teams who went above and beyond with the back end,
but had a less usable front end wouldn't get the attention
from the community that they really deserved.
So, I really love this story
because it emphasizes something that developers
and, I think, especially devs who spend the majority
of their time writing code that isn't user-facing,
can really too easily overlook.
And it's that users don't care how you built your product.
They only care if it works
and their first impression of it really counts for a lot.
So, you know the saying, "Don't judge a book by its cover"?
Your user is going to ignore that.
If your product looks good, they're more likely to trust it.
And they really don't care
about the code that's actually powering it.
So, before these angry ponies run me out of San Antonio
with pitchforks and fire
for saying that the code doesn't matter,
let me just clarify real quick.
So, obviously, the technology stack that you use
is a very important part of the success of your product.
I'm not disputing that.
And I think we're really lucky
to be working in this industry where the sky's the limit
when it comes to what you can make.
And we're surrounded by
and getting to build cool technology 24/7.
But this saturation of connection is a double-edged sword
because living and working at a time
when technology is constantly making these very fast,
very big leaps forward means
that our users have really high expectations
and developers are constantly chasing
the next best tool for the job.
And as a culture, we are totally immersed
in digital things all-day, everyday,
so the tech itself is not novel for users anymore.
It has just turned into another part
of how they navigate through their lives.
So, technology's become so ubiquitous in our daily lives
that it's taken for granted unless a user's experience
with it is so exceptional
that they can't help but notice it.
So, basically, what this means is that
you all have done your job so well
that nobody notices anymore.
So, digital tools are everywhere
and they're used for everything.
And we really ask users to put a huge amount
of trust in our products,
which means that we're asking them
to put a huge amount of trust in us.
And we're asking them to give us their e-mail addresses,
their home addresses, their Social Security numbers
and their bank account information.
And, I mean, that's asking for a lot, right?
And they should expect a lot from us in return.
So, users expect and they quite frankly deserve
to have digital products that are tailored to work for them
and that they feel good about using.
And, again, they don't care how you build it.
What they do care about is that it does
what they need it to do,
they care that it solves a problem for them,
they care that the value it offers
makes using it worth their time and worth their money,
and they care how it makes them feel.
Do they feel dumb when they're trying to use it?
Do they feel frustrated?
Are they able to easily do all the things they needed to do
and wanted to do without any trouble?
So, this all boils down to the fact
that prioritizing design, creative solutions
and the needs of your user and your approach to software
is a lot bigger than just making things pretty.
It's a business decision that can have a very real impact
on your bottom line because it determines
whether or not people actually use your product.
So, think back to Jeff's restrictions on Bootstrap
in our student project for demo night
'cause good design focuses and delivers
on something that your user needs
and that does make it easier to win.
And, when building software is your business,
that's exactly what you want.
So, the key take-aways here are that
your users have high expectations,
you really need to understand your users' needs,
technology changes all the time,
and the ability to generate new ideas will never lose value.
So, knowing how to leverage design as a tool
to understand your users and shape your product
has huge benefits for developers,
but I've had a lot of conversations with devs
who say that they can't do design
or that they aren't creative.
And so, I expect this is a combination
of not really liking crafty things
or feeling like design would take valuable time away
from writing code and that design
is just simply not their job.
But, this attitude always kinda gives me pause
because design is really interesting and developers are some
of the most creative people that I know.
And, as developers, you have a great advantage
when it comes to learning about design
because you come to the table
with a really deep understanding
of the complex technical piece of the puzzle.
So, it's very worth the effort it takes
to gain a deeper understanding of the human side
of the equation because it will lead you
to this powerful combination of technical knowledge
and creative thinking, which in turn provides you
with the power to generate amazing ideas
and amazing products.
And amazing ideas and amazing products
lead to happy users and successful organizations.
So, I love design.
I'm a designer.
I'm also a developer, but I'm a designer first. (laughs)
And a big part of why I love it so much
is the depth of thinking and the process
that goes into a design project.
So, the larger idea behind why and how something came to be,
like whether it's a product for business
or a piece of artwork, is just really interesting to me.
And in my personal design philosophy,
I've considered this bigger picture ideation
to be concept-focused thinking
or CDD, concept driven design,
meaning that the implementation
and details are growing outwards
from a core concept that's based on the needs of your user,
and this drives the approach to your solutions.
So, this can be that the idea
that a digital product needs to bring families together
away from a computer, or that a company wants to branch out
from a core product and needs help figuring out
what this new market or product should be,
or, because I did exhibit design
for museums for a long time,
how signage in a physical space
can maximize visitor engagement at museums.
So, it really can be any scenario,
but the lineage of this final product
can always be traced back to that core concept.
Oh, another story time.
So, this way of thinking came from my undergrad experience.
I actually went to an art school and,
in the freshman year program,
everyone went through this foundations program
that exposed every student to the full range
of techniques and materials and processes
that were used in all the different departments.
So, you're doing sculpture and painting
and drawing and that sort of thing.
And by going through this foundation program,
you really got a solid starting point
for the rest of your educational career
and your actual career.
And so, this curriculum means
that you aren't gonna be restricted in your work
because of a lack of skills, but, more importantly,
it means that it's taught you how to think about problems.
And this program assumes
that no one has mastered how to think creatively.
So, it starts at square one
and it teaches every student how to do that.
So, at the start of my foundation year,
my studio professors kept telling me
that my work wasn't deep enough
and not conceptual enough, very arty critiques of things.
But then, they really struggled to clarify
what that actually meant so I could fix it.
And that kinda drove me crazy
and I wasn't really doing badly,
but there was this sort of indescribable
and intangible issue that was preventing me
from doing the quality of work that I expected of myself.
And it was really frustrating
that I couldn't translate this feedback
into something I could use.
And then, at the end of that year, I took a short workshop
with a professor who broke this idea of conceptual thinking
into steps that I could understand and actually apply.
And then, suddenly, all of those prior conversations
clicked into place and I understood what they meant.
And it took some practice before I was consistently able
to work concept-first, but it was a major turning point
because I understood how to push my ideas further
to do better work.
So, it was this teacher who took the time
to break down what concept is
and then teach it to her students
who gave me the tools to absorb
and utilize what other professors had been telling me
without clarification for the rest of the year.
So, fast-forward quite a few years
and to my current company,
where my official job title is developer,
but our recent project needs have given me the chance
to spend some time on design work.
And I was a designer for a long time
before I stepped away from it in 2013
to focus on writing code, so it's been really a lot of fun
to dive back into it and find new resources and inspiration.
So, during this period of investigation
and research at work,
I started reading about a design methodology
that not only supports
my own design approach and experience,
but expertly expands it
into a repeatable human-centered technique
to help people outside of traditionally creative careers
like art and design leverage the power
of human-centered design
in their work and their organizations.
So, it shows you how to get to the concept consistently.
This approach is not necessarily a brand-new idea,
but it's very relevant, useful and powerful,
and it's basically doing
what my college professor did to me.
It teaches you a way to think
and approach human-focused problems
through real actionable steps that allow you
to break down problems and take full advantage
of your inner creativity
to arrive at unique successful solutions.
So it basically just gives you the tools
to fast-track the design learning process
that I went through in my foundation year program
and through the applied practice of design thinking.
Oh, slide pony, I'm so glad that you asked.
Let's talk about what design thinking is.
So, the sort of broad 10,000-foot view
is that design thinking is about driving innovation
through focusing on human needs.
It's a repeatable formula for identifying problems
and creating user-focused solutions
that's been championed by and refined by IDO
and the Hasso Plattner Institute of Design at Stanford,
which is also known as the d.School.
So, using this approach trains you
to think differently about how you tackle problems
faced by your user through gathering critical feedback
and being open-minded about trying novel approaches,
sorry, (laughs).
Through gathering feedback, prototyping,
and then being open-minded about trying novel approaches,
you ultimately are able to produce
the best product for your user.
So, this application of an approach to design
helps sift through the idea static
to expose the highly creative innovator in everyone.
So, one of design thinking's base constructs
is building what David Kelley,
the founder of the d.School and IDO,
refers to as creative confidence in people
who may not view themselves
as creative in the traditional sense.
So, these are the folks who say, "I'm not an artist.
"I can't draw. I'm not a designer," those kinds of things.
Basically, the kind of statements
I've heard a lot of developers say.
So, this process actually helps its practitioners
change the way they view themselves
and the way that they view their creative capabilities.
So, this mindset shift
around how you view your own abilities
is a really important milestone in the process
of learning to embrace design thinking
and it's an idea backed by the work on self-efficacy
by Albert Bandura, a Stanford psychologist.
So, I say he's a Stanford psychologist,
but he could probably be more described
as the Stanford psychologist.
He's one of the most respected
and well-known modern psychologists
and he's probably the most famous living psychologist.
And he's been awarded like 16 honorary degrees
and his research around human agency
and social cognition is really groundbreaking and important.
So, self-efficacy, as described by Bandura,
is the belief in one's capabilities to organize and execute
the courses of action required
to manage prospective situations.
So, basically, it's all about your perceptions of yourself
and that you see yourself as someone
who is capable of something.
And, in this case, that something
is the ability to be creative.
So, it's similar to the school of thought
that success is not dictated by raw intelligence,
but rather by a student's grittiness
or the possession of a growth mindset,
which is the belief that, if something is hard,
it's still learnable through effort and hard work.
Or, rather than a fixed mindset,
which is thinking that, if something is hard,
it's just unlearnable and you can't do it.
So, design thinking and developing creative confidence
is about approaching problems with the belief
that there is at least one solution and probably more,
and that you are capable of finding it.
So, rather than letting setbacks derail you,
you are using them as evidence to, or,
rather than letting setbacks derail you
and using them as evidence
to back a claim of non-creativity,
you see them as a learning opportunity
and a chance to help you fine-tune your work and ideas.
So, I've heard both sides,
I've heard people on both sides
of the creative and technical fence
use exactly the same reasons
to explain why they aren't suited to do the work
that the other side is doing, and I really don't buy it.
And I don't think that you have to, either.
Embracing design thinking
and taking your user into consideration
will not only help give you skills
that make you a stronger asset to any team you work with,
but it'll help you make
consistently smarter business decisions and reduce risk
because you'll have a deeper understanding
of the what and why behind your product.
So, without this understanding,
you really have no way to know
if your product is actually relevant to the market
and the people you want to be using it.
So, the key take-aways here are
building creative confidence is important,
design is fun and so can you,
and it's a huge value add to your skill-set as a developer.
So, IDO and the d.School have,
over many years of practicing this methodology,
developed a formulaic design thinking strategy
to help you leverage these approaches in your work.
And the good news is that these techniques and these steps
will probably feel pretty familiar
to what you do in your development work.
So, do you pair program every day, or sometimes?
Sometimes pair programming?
Do you submit pull requests
and then participate in code reviews?
Yeah?
Do you use TDD and then work
through a red, green, refactor cycle?
Hopefully?
Maybe not, depending on how your day's going.
So, it turns out that these are all strategies that,
with a little bit of adjustment,
can be applied to the user-facing side of your product
to help you better understand
the people who you want to use it
and then what their needs are
and ultimately how to focus your product and what it does.
So, the d.School outlines these following steps
as key process states to work through.
So, this are empathy, define, ideate, prototype, and test.
So, let's dig into each one of these.
So, the definition of empathy is the ability
to understand and share the feelings of another.
And this is a central element in human-centered design
because it allows you to understand your design challenge
through the eyes of the people
you actually want to be using it.
And why is this important?
Because you aren't solving this problem for yourself.
Just because something is good for you
and makes sense to you doesn't mean that it's good
and makes sense to other people.
It's back to that problem when you build something
that's super cool but doesn't make sense to anyone
and they don't wanna use it.
So, how do you do this?
How do you accomplish this level of empathy?
So, step one, through observation.
You can get really great information
from the insights you gain
from simply paying close attention to what people do.
So, we generally tend to filter things
based on our own experiences and preferences.
So, it's really critical to see that
from someone else's eyes,
through someone else's eyes and their point of view.
Second step, by engaging with people.
Yes, you're gonna have to talk to some humans.
It's terrible, right? Oh no.
So, directly engaging with people
reveals a lot about what they think
and what their values are.
So if you're listening and paying attention to details
and watching what they do compared to what they,
watching what they say
compared to what they actually do,
you'll really understand their beliefs and world view
a lot more clearly.
And then just watch and listen.
So ask someone to show you how they do something.
Have them go through the steps
and then talk you through why they're doing
what they're doing and let that process
guide you in asking better questions.
Define.
After we have gone through the empathy stage
we're gonna define things.
So define means to state or describe
exactly the nature, scope, or meaning of.
So in this context that means that
this state is gonna bring clarity and focus
to the information collected in the empathy phase
and focus on the design problem
and what form it will take.
This is your chance to really shape
the challenge you're tackling
based on your findings about the user and the context
of the problem that they're facing.
So ultimately, it's about making sense
of all the information that you've gathered.
So you're taking all these unrelated parts
and putting them together.
Why would you do this?
It's giving you time to take your scattered insights
and then combine them into more focused thought
and direction.
And then this lets you find your point of view.
Which is the explicit expression
of the problem that you want to address.
And then the more focused your point of view is,
the greater quantity and quality of solutions
that you can generate in the next phases.
Which brings us to ideation.
This is when you really concentrate on idea generation.
You're combining your understanding of the problem
and the people that you're designing for
with your imagination.
And at this stage it's really all about
pushing for the widest possible range of ideas
and not just finding a single best solution.
So you're looking for a broadness
rather than depth of solutions.
So don't worry about getting it right at this point
because the user feedback that you get
at later stages will help dictate what the best solution is.
Why would you do this?
It really helps you step beyond obvious solutions
and it pushes you outside of your comfort zone.
If you happen to be working in a group
going through these processes
it helps harness all the strength
and input of your team and lets your ideas
build on one another.
And it helps you find unexpected areas of exploration
and it helps you get the obvious solutions
out of your head and then lets you
push beyond them sooner than later.
So now we get to prototyping.
This is the fun part, I think this is the fun part.
Prototyping is the iterative generation of ideas
to get you closer to the final solution.
Especially early in this phase,
you really wanna create quick, simple prototypes
and just get feedback early and often.
And these sort of lo-fi examples
will tend to get better feedback
because people don't worry that
you are gonna have your feelings hurt
or that you're really committed to a certain direction.
So they're not gonna worry about
throwing the wrench in the work
so they're gonna give you better input.
At this stage, it really should be clear
that nobody's overly attached to a specific idea
and that it's wide open for input.
This means that you're gonna get better feedback.
I think one way that the d.School describes it
is that it's building to think.
So you're working your ideas out
in a physical way and you're just trying to get them
out in the open.
So why would you do this?
Because it starts conversations.
It allows you to fail quickly and cheaply
so you're able to figure out if something
isn't gonna work sooner than later.
So you're not investing a bunch of time and money in it.
And it really allows you to test all the possibilities.
And it also helps you manage the process
of building your solution so you can just clarify
and guide yourself better.
And the really great thing about this step is
to start you just start building things.
And you don't have to spend too much time on one prototype
and you can just focus on getting your ideas
out of your head and turn them into something
you can get input on.
And then testing
and this is where you are actually getting your prototype
into people's hands.
We aim to be,
aim to be open-minded that this could be
an unsuccessful solution when you show it to somebody.
Don't just test how your solution is succeeding,
and keep asking why
and then be willing to pivot and potentially even scrap
the current idea for a better one.
Really take the opportunity to refine your solution
and make it better.
A good rule of thumb is to prototype
like you know that you're right.
So with great confidence.
And then test as if you know you're wrong.
So you're really making the user prove to you
that this is the right solution.
And remember that this is the opportunity
to get feedback on your ideas
and the assumptions you've made
about what the problem was and how to solve it.
And then you might have to do it again.
Don't be afraid to go back through the process again
and to refine your ideas and make them stronger.
And that might seem like a lot.
And maybe it's too much talking to humans.
And maybe you already do too much at work.
And that's okay!
And, you know, it may sounds like a lot
or just seem too far outside of your normal workflow
but let's go back and look through these steps
from a more familiar angle
because they're actually guiding you through a process
that's very similar to what you do as developers
and you can incorporate them
in your workflow.
So let's think about the parallels
between this user focus process
and then the TDD cycle that you work through.
With empathy.
So before we write any of our working code,
we want to write a test.
And to do that effectively you have to have an understanding
of what you actually want your code to do
and what its place in your app is
and then what the implications of adding the code
to your codebase will be.
You're finding the right question to ask
about what you want your code to do
and then you're finding the right way
to ask them at this stage.
Define.
So now that you have a solid understanding
of what you want your test to cover,
you might write some pseudocode to help you lock in
what you want your test to do
and then test and then you're going to
write your test so that it frames
the questions and needs that you established previously.
Then for ideating,
we're actually gonna be writing our working code
and we're gonna be letting the test guide us.
So you're going through the,
letting all the error messages tell you what to write next.
And then for prototyping,
we're gonna refactor, make it better and make it cleaner,
make it more reusable.
And keep getting it back to green,
so you're getting a nicer, cleaner solution.
And then testing in this phase
would be about submitting a pull request.
Having your team doing a code review
and then possibly going back
and doing additional refactoring.
And then once it's been approved,
merge it into master and then deploy.
Grab the next story, do it again.
And then just in case you're still thinking
that this is a load of hooey,
and your skills are fine as is,
or you don't have space in your schedule
to learn about how to think like a designer,
I just want to add this.
So I've gone through this mindset shift not once, but twice.
So initially I learned to think creatively and conceptually
and then years later, I learned to program
and think like a developer.
Basically, I decided thinking I couldn't do things
for whatever reason was a horrible excuse,
that was actually poo.
And now I'm a designer and a developer
and I do a lot of work with organizations
that teach people to code.
And how I view myself and how I view my ability to learn
has totally changed.
So there are no more unpassable obstacles
and no more pooey excuses.
And if I can do that, you can do it too.
So thank you.
(applause)
And here are some resources.
