In this article, I will explain what the Design Thinking Process is and break down the five phases behind it. We will explore how this process was applied to the freeCodeCamp organization.

What is the Design Thinking Process and why is it important?

The Design Thinking Process was first mentioned in Herbert A. Simon's book The Sciences of the Artificial. As a cognitive scientist, Simon explored the decision making process humans go through.

As a result, Simon's ideas contributed a lot to the current model of the Design Thinking Process and provided companies with a different approach to understanding their users.

The Design Thinking Process focuses on studying the user's needs and coming up with solutions to develop better products and services for them.

This process encourages innovative thinking and creative problem solving which leads to better businesses and nonprofit organizations.

The five phases of the Design Thinking Process are:

1. Empathize
2. Define
3. Ideate
4. Prototype
5. Test

Let's take a closer look at this process and how it works in a real world organization like freeCodeCamp.

Empathize

When Quincy Larson started learning how to code, he bounced around from one free online source to another struggling to find a structured path. Even though he was able to land a developer job, the process of learning how to code was a lonely and frustrating one.

After speaking with many other self-taught developers, he realized he wasn't the only one with this story. So Quincy started researching and learning about those embarking on the self taught journey.

Quincy started to empathize with others struggling to learn how to code and sought to understand their needs, wants, and goals. Throughout this extensive research, he discovered a key problem.

Define

When Quincy started freeCodeCamp in 2014, his goal was to address an important issue: a lack of access to high quality education by most people wanting to learn around the world.

At the time, if you wanted to study programming, you would either attend college or a bootcamp. But Quincy realized there were issues concerning access for both of those options.

College is a wonderful opportunity for students to learn and gain an education, but not everyone has the funds or time to go through a 3-4 year degree program.

Bootcamps were an alternative to gain the skills needed to start an entry level job. But through extensive research, Quincy realized that most bootcamps were very expensive, and were attended by American white males in their mid 20's who had college degrees.

So the question became, "What about everyone else?"

What if someone wanted to learn how to code but there wasn't a high quality structured resource that was also free?

Ideate

In this article detailing the first month of freeCodeCamp, Quincy laid out the goals and mission for the organization.

The world needed a coding bootcamp that helped everyone else.
That meant:

It should be fully online so that busy people with families, and people outside of the US, could participate.

It should be inclusive rather than “selective”, and open to everyone regardless age, sex, race, country of origin, or English proficiency.

There was only one for sure way to remove socio-economic considerations: make it 100% free.

Quincy Larson set out to create freeCodeCamp which provided a free structured learning environment that can be done in the browser and was completely self-paced.

This meant that anyone around the world could learn for free on any device available to them and not have to worry about downloading a whole bunch of software.

The idea was to create an online platform filled with dozens of interactive challenges and projects for the users to build and add to their portfolios.

He also wanted to create an online chat for developers to come together and discuss their learning and help each other along the way. This addressed the core issue that many self taught developers felt trying to code alone in isolation.

Prototype

Quincy Larson built the first prototype version of freeCodeCamp in a few days and starting publicizing it on his social media channels. This early version had a few challenges for users to go through and a chat room for learners to connect online.

The prototype phase was important because it led into the final phase of the Design Thinking process: user testing.

Testing

Within the first few months, people were starting to join the platform and go through the challenges.

Since the project is open source, it allowed people to provide feedback and make changes to the early version of the curriculum.

This initial phase allowed Quincy and his small team to identify usability issues and observe how users were interacting with the platform. From there, they were able to listen to feedback and start implementing those changes.

Conclusion

The Design Thinking Process focuses on studying the user's needs and coming up with solutions to develop better products and services for them.

This process encourages innovative thinking and creative problem solving which leads to better businesses and nonprofit organizations.

The five phases of the Design Thinking Process are:

1. Empathize
2. Define
3. Ideate
4. Prototype
5. Test

freeCodeCamp used this process to come up with a creative solution to teaching people all around the world how to code for free.

If you want to learn more about the Design Thinking process, you can look into taking this Design Thinking for Innovation course.

##

There are some wonderfully well-designed products out there: a Herman Miller chair, an Apple laptop computer, a Tesla Model S, a cup of Starbucks coffee.

These products embody experiences that are greater than the product themselves.

These products have been designed to make our lives richer and in many respects better.

These products have something else in common: design is central to how they behave and feel. These products also have a wonderful user experience and are supported by profitable business models.

In short, these products are well known to represent the best of the design process.

This begs the questions: what is the Design Process? And how can entrepreneurs and developers start learning the Design Process?

Having built and launched products myself, I have a few relevant ideas.

I have also spoken with countless people about the topic, and these conversations have informed my thinking.

I now want to share these insights with you.

What is Design Thinking?

Design thinking is a holistic way of applying critical thinking to solving design-related problems that matter to people. Specifically, Design Thinking is a way to learn about, gain insight into, and deeply understand human beings.

An introduction to Design Thinking starts by placing the human experience – what people want, need, and value – at the center of your design thinking.

As opposed to optimizing for other metrics or stakeholders, like product speed, financial profits, or aesthetics, the design thinking process starts by prioritizing the primal needs of the human users.

What do people want? What do they fear? What do they most care about and why? Design Thinking starts by attempting to frame answers to these questions.

How can you place humans at the center of your thinking?

I took a Design Thinking class in graduate school. The Professor asked us to “get out of the building,” leave the classroom, and go speak with people about issues they faced in their lives.

Specifically I was tasked with asking people about their relationship with the medical field.

Speaking to strangers can be challenging. But speaking with strangers about medicine – and when they last saw a doctor, for example – was downright anxiety-inducing.

Yet I knew if I wanted to improve my Design Thinking skills, I needed to go beyond my comfort zone.

You should embrace speaking with people. It will help you learn and improve your Design Thinking capabilities.

When you go and speak with people, pick a topic that you find interesting and worthwhile. Pay close attention to who they are. Ask yourself:

1. How did you find this person?
2. Why did you talk to them?
3. Was this person similar to you or different?
4. In what ways did you originally guess that this person would be different from you? (class, gender, race, ethnicity, age, legal status, and so on)?

Design Thinking starts with people. If you want to design for people you need to interact with people.

Ask probing questions and listen carefully. Listen for facts and listen for stories.

At the conclusion of your conversation, take time to reflect:

1. What was the most surprising thing about this person's story?
2. In what ways is this person turn out to be different from you?
3. Does this person have values different from yours?
4. If they have similar values, do they express these values in surprising ways?
5. What questions did you ask that led to the most interesting insights?
6. Did you notice anything surprising about the immediate environment where you talked to the person?
7. Did the environment "prompt behavior" from you or from the person you talked with?

In Change by Design, author Tim Brown writes at length about the importance of “empathy” in design thinking. Brown notes that empathy is a challenging word to define but a critical concept to building and designing products.

This is because empathy helps us understand others.

And if we are designing for people, we need to design for people that look, act, behave, and are fundamentally different from ourselves.

When learning more about the medical field, I spoke with a young man named Sam. At first I wanted to learn more about which online resources he used to find doctors.

But what he shared pivoted the conversation, and my subsequent understanding of his relationship to medical practitioners.

Sam talked about control and his lack of “control” when it came time to paying medical bills. He repeatedly mentioned that he had to pay more out of pocket than he initially thought he would have to. He felt “cheated.”

I didn’t realize this at the time, but this feeling of being “cheated” was an area worth exploring further.

Had I had a better rooting in Design Thinking I would have probed this domain further.

Specifically, I would have sought answers to the following: What about this “cheated” feeling made Sam so irate? Was it the feeling of powerlessness? Was it a sense of financial injustice? Or some combination of both? Did Sam’s loss of control make him feel threatened?

A software tool that enables more transparent pricing disclosures is likely something that Sam would have benefited from. I only uncovered this insight by listening to what Sam said.

Yet I also missed other topics to question further. These were my mistakes. You need not repeat them.

When you are learning Design Thinking don’t be afraid to ask probing questions as the conversation takes new and unexpected directions.

Go deep in the pursuit of truth.

The ability to learn through feeling – even if you don’t have precise first-hand exposure to that thing – is what empathy is rooted in.

Using this feeling to inform decisions (products, design, and outcomes) is how empathy inspires Design Thinking.

Placing Design Thinking at the Center of Your Worldview

Design Thinking is practiced and learned over time. An introduction to the Design Process can start in a physical classroom (as mine did), via informative online courses, or in conversations with people in your life.

When I first used the empathy framework to connect with Sam and others I spoke with, it was very challenging.

While it was not hard to remember everything he said, it was challenging to recount his body language and tone throughout the conversation when I got home and wanted to type up notes.

It was hard to map patterns among the different parts of the conversation.

As you begin your Design Thinking journey, you will likely struggle with recount as well. It is okay to struggle. Keep engaging, keep listening, and keep reflecting.

These skills will help you better understand what people care about.

These insights, in turn, will help you develop and ultimately build better solutions. By demonstrating a deep interest in the development and understanding of people, you can create outcomes that best help these people.

I like to think of Design Thinking as an evolved skill. You can practice, improve, and grow Design Thinking skills over the course of your life.

Final Thoughts on Design Thinking

If you don’t feel fully comfortable with this approach, you can always outsource aspects of work to experts.

Through practice, however, you can improve.

And it also helps to establish a beneficial cycle. User-centric designs also help websites achieve their SEO goals too, after your product exists in the market.

Employing design thinking makes for web content that viewers will be inclined to share and that other sites will be happy to link to.

When visitors know they're at the heart of everything you do, search engines will notice and reward you accordingly.

By placing humans at the center of my inquiry, I discover new insights.

These insights helped me peel back assumptions and stale ways of thinking. By reframing patterns, I am able to incubate new ideas.

These benefits are readily available to you too.

You can stimulate creativity.

By thinking more creatively, you can ideate and generate new ideas and push the possibilities.

By pushing the boundaries, you can again discover new ways of thinking, and technologies like data visualization or VR can help you on your journey.

This makes it easier to build because you have a clearer North Star.

This clarity can help deliver new products and solutions.

Delivering products leads to a new foundation of learning and discovery. And that is a worthy end goal.

Design as a developer

Design is a term that can describe many parts of the process. Most often, it's probably thought of as the visual designers or UX designers who are actively working to make your product usable or beautiful.

A question that I commonly get asked or see online is where should one start to learn the basics of design?

This question makes me happy. It's an important part of the process that is constantly a secondary thought. And when I asked this on Twitter, I received some thoughtful responses!

We're living in an age where good UX is increasingly seen as important, but it's still nowhere near the top of the list for those who are learning their way through development. It's still an afterthought that's tossed over to the design team when you're at the 2nd half of your last sprint before launch.

So before I share with you some resources, I'm going to start by explaining why these things are important.

Giving something for your visitors to use

Starting from the top – you can have the best, most ingenious product that blows all competition away, but if no one knows how to use it, it realistically has no value.

Fictional Pied Piper's app tanked because of a bad user experience

Our fictional friends at Pied Piper learned this the hard way when their product launch with a groundbreaking compression algorithm didn't go over too well because no one knew how to actually use it.

But this is a realistic scenario. We learned from Craigslist that your website or app doesn't need to have a slick design, but it has to be usable.

Craigslist in 2001 vs 2020

For nearly 20 years, Craigslist really hasn't changed that much. A few tweaks to make things a little bit cleaner, but overall it's the same basic layout and experience.

Unfortunately, budget is a concern, and sometimes you can only stretch it so much which doesn't always include a designer. But try to at least get some outside perspective – it can even be a family member or a friend! You would be surprised how much insight you can gather by trying to get your family over the holiday to try to use your app.

The goal is ultimately to get your product in front of someone that hasn't been heads down in it for the past year to get a pair of fresh eyes and a new perspective.

Becoming more productive

Putting on my process hat – another overlooked aspect of prioritizing design time is the amount of overall time you can possibly save.

Designers don't always get it right the first time, let alone leaving developers to create the design. That's not even including the possibility that your customer or product owner doesn't like the direction you took.

Why spend a couple sprints building out a solution only to start from scratch when you have to throw it all away? Not only have you wasted your customer's time, you've wasted your whole team's time.

Get design feedback early. Work with the design resources you have to iterate and work in feedback as you go. It's important to solve the UI problems before you develop the solutions.

Design sketches from Unsplash.com

And this can generally help your team flesh out ideas. Visually seeing an idea, even as a rough sketch on a piece of paper or a disposable prototype, can completely change the way you look at the solution.

All of this early feedback and brainstorming will help you achieve the end-goal of a better product and user experience.

Developers are users

Most of people reading this post probably have written code in one form or another. But have you ever thought about how your code impacts other developers?

There are many layers to how your code can provide a better experience for another developer. The basic being – is the documentation that you created readable and easy to understand?

_Stripe's API documentation_

While it's certainly important for your fellow teammates, they should typically be able to message you on Slack or hop on a call when they run into trouble. But how about those developers that only have your documentation?

Beautiful documentation isn't that which has a beautiful design, it's one that thoroughly walks through the code that you've created so that others can understand what it does and how they can use it. Just as a visitor to your app needs to know how to use the UI, a developer working with your services needs to know how to use the API.

A little extra delight

But of course everyone wants something nice to look at. Not only can design treats make people happy and smile, it can also help avoid stress and tension.

Josh W. Comeau includes cute, happy graphics throughout his site

Having a page that's ugly or overly thick with data can be unsettling. Not only can it hurt the usability, but the clutter and color choices can make people feel uneasy, stressed, and full of anxiety.

While your team might not have the resources for full-time designers, taking a little time to learn the basics of design can help set you on your journey of becoming a well rounded developer.

Resources for learning design basics

Like it or not – we're all "designers" in a way. We're all building tools and systems that ultimately will be used by another human being. We should do what we can to make our creations friendlier to use for everyone who comes next.

Since you're now inevitably inspired to spend some time and learn about design, there are luckily a lot of resources available for you to get started.

Videos

• Abstract: The Art of Design (Netflix)
• Objectified (Amazon)

Books

• Design for Hackers (Amazon)
• The Non-Designer's Design Book (Amazon)

Email Course

• Design for Hackers
• Design Academy
• Hack Design

Misc

• Design Tips from @steveschoger

What's your take on design as a developer?

Have any of these worked particularly well for you? Am I missing something that made design click for you? Please share with me on Twitter!

Join the conversation!

Design Sprints can generate remarkable output for your company — such as a backlog of impactful ideas, functional prototypes, learning and key insights from customers along with real business opportunities.

Consider this situation: your company needs to solve a major real-world problem — you need a novel solution, better than any other offering available in the market. You could be aiming for a product, a component, a system, a service or a process.

In an ideal scenario, before making any investments, you would need the set of candidate solutions, prototyped and exposed to a controlled set of real users. This would enable enough signals and insights to make informed decisions and setup a better product development strategy.

To get there — from a problem to functional prototypes enriched with customer feedback — you can follow standard paths. For example you can consult the experts in your organization, assign work-streams to different teams, coordinate the work, schedule brainstorming meetings, and wait in the queue to get UI designs and then to develop prototypes — a lengthy process with several drawbacks, dependencies, issues and risks.

Or, you can setup a powerful multidisciplinary team and ‘lock’ it in a room for a few days, with a clear goal: a shortlist of inexpensive, realistic prototypes of selected high-potential concepts, each enriched with feedback from real users.

A rapid innovation process outputting potential solutions to your problem and evidence from real users on how effective they are.

This intense ideation and prototyping process comes in several forms and variations — a popular one being the ‘Design Sprint’, which promises ‘Solutions to big problems in just five days’. It uses ‘design thinking’ principles and introduces several techniques, tools and rules.

The success factors

To get real value from a Design Sprint, you must emphasize on the right setup, preparation and readiness — or you may end up hosting an expensive multi-day brainstorming session outputting just noise.

Having joined a large number of ‘ideation and prototyping’ sessions along with 10’s of formal ‘Design Sprints’, I would summarize the critical aspects and success factors in the following way.

1. Define the problem statement

Don’t let the problem statement become your real problem! Most of the unsuccessful Design Sprints and prototyping sessions I have experienced so far, share this specific single point of failure: a poorly defined problem statement, which triggers time-consuming discussions, iterations and unnecessary regression — setting the entire process at risk.

In contrast, the Design Sprints that started with clarity on the problem to be solved, moved on rapidly towards impressive solutions and prototypes.

The Design Sprints that started with clarity on the problem to be solved moved on rapidly towards impressive solutions and prototypes.

Although the first day of the Design Sprint is usually about framing and re-framing the problem statement, I am convinced that having a good problem definition upfront is key for a successful outcome. You can always revise it and reset it as necessary during the first day, but a solid basis can make the difference. In any case, the team needs to be open to understand the problem and ready to consider different angles and unconventional approaches.

There are several templates and methods to help you construct a valid problem statement — in general you need to describe the current situation vs the ideal state and the related implications for the involved users.

2. Set up the right team

The synthesis of the team sets the foundation for the entire Design Sprint — you need diversity of thought, skills and perspectives along with expertise and creativeness — all combined in a small multidisciplinary team with the right culture: a team willing to share, collaborate, challenge assumptions, think big but also be pragmatic and purpose-driven.

A few factors can introduce serious risks to the process:

• The wrong dynamics in the team (for instance, members do not express their ideas for fear of getting criticized by more senior members in the team)
• a large team (add more than 6–7 people and you’ll get additional problems to solve)
• or the wrong mindset (people tend to protect ideas versus sharing, or believe that they know the right solution, upfront).

The members of the team must ‘forget’ about seniority, hierarchy and authority. They need to be open to new ideas, new perspectives and different views. They also need to be ready to influence and get influenced, and to minimize the impact of bias and work together towards a shared mission — a great solution to a challenging problem.

Physical space is also very important to allow the team to focus, express random thoughts and ideas, collaborate and quickly visualize concepts. You need a room with enough space, the right equipment and office supplies– such as writable walls, whiteboards and well, plenty of sticky notes.

3. Make sure the team is well-prepared

Design Sprints are demanding — fast and intense. The key to success is to have a well-prepared team. Even if your dream team consists of domain experts and senior business leaders, they all have to put some extra effort to get prepared — so they fully understand the problem and its wider context, the technology, the competition and the relevant global trends. Make sure that you clearly communicate to the team not only the context and the problem to be solved, but also the rules and the need to get prepared.

4. Focus on ideation

Assuming that a solid problem statement and the right preparation is there, the next most important element is ideation. While the Design Sprint process provides some tools to empower ideation, I would strongly recommend that you:

• increase the time allocated to idea generation, sketching and pitching and
• capture the ideas in digital format — with more detailed descriptions.

A backlog of ideas is a great asset — one of the most important outputs of the sprint and the key input to the prototyping phase. Ideas should not be left on sticky notes — even the non-selected ones could prove to be relevant and valuable in the future.

This is why you need to feed the ideas generated in the Sprint into a centralized ideation system and make them discoverable by the right audience.

5. Get ready for ‘rapid prototyping’

Delivering realistic prototypes is a critical part of this process — since they will be used to capture user/ customer feedback. You don’t want your great concept to receive negative feedback due to a poor prototype implementation — that could mislead related decisions and undermine the overall value of the Design Sprint. Your team must be capable of real rapid prototyping — able to build realistic user experiences in just a couple of days or less.

Rapid Prototyping requires the right resources in the team along with a general technological readiness. For instance, to speed up the process you need to leverage any reusable software components you have, standardized datasets, artificial/ static data, UI elements, APIs, models and services. You will also need systems, tools and processes — for instance wireframing, software development environments and DevOps capabilities.

Availability of special equipment might be important. For example, if physical prototyping is involved, a 3D printer might be of real value. Or if you expect Augmented Reality prototypes, you will need access to related devices — along with any templates, APIs and documentation.

6. Find a great Facilitator

This is a key role — in fact, I see the facilitator as the real protagonist of the Design Sprint. The facilitator must maintain the right pace, direction, energy levels and interaction patterns, to lead the team towards a clear, shared goal: define and prototype a great, novel concept solving the problem for real users.

It is a difficult profile to find — you need somebody mastering the process itself, but also having deep understanding of the problem and the particular business context. The facilitator must be capable of ‘reading’ the characters in the room and take necessary action to make sure that all voices are heard and considered.

7. Capture everything

Design Sprints are typically very ‘noisy’ with tons of sticky notes, ideas and stories on the walls — all these, in-between discussions, arguments, decisions and random thoughts. And yes, this ‘controlled chaos’ is exciting, but unless you have a dedicated person responsible for taking (digital) notes, you will end up frustrated, trying to decode colorful sticky notes and ‘reverse-engineer’ random drawings.

To make the most of the thoughts and ideas, you need to capture them in a modern way — so they are discoverable and potentially usable.

8. Find a Leader, not just a ‘decider’

I find the proposed decision-making process — with the super voting concept and the sticky votes on the sketches — oversimplified and very sensitive to team dynamics and the overall state of the team. Moreover, given the extra power, the decider must demonstrate deep understanding of the concepts, the ability to think strategically and communicate with clarity. You need a real leader there, not an ‘authority’ or ‘political’ person.

The facilitator and the team should feel free to challenge whatever decisions made by the decider, by asking for justification — the business or technical reasoning.

9. Measure Success

A design sprint is an expensive process — consider the associated direct and indirect costs of having x members full-time for z days. Thus, measuring the success of the Design Sprint itself is important. In the case of an ‘isolated’ sprint, success can be measured by processing direct feedback, outputs and mid-term outcomes — for example business opportunities and success stories linked with the deliverables of the Sprint.

If you are running successive Design Sprints, you need a framework to capture and quantify Sprint outputs and impact — a flow towards a centralized ideas and knowledge repository. This data store should enable full tracking of the real business opportunities and financial gains associated with each of your Design Sprints — while specialized KPIs allow tracking the success of the overall innovation programme.

The key question in this case is regarding the baseline to compare this ‘quantified innovation output’ against — to be covered in a forthcoming article.

Design Sprints can generate remarkable output for your company — such as a backlog of impactful ideas (also with IP opportunities), functional prototypes, learnings and key insights from customers along with real business opportunities. At the same time, assuming proper and frequent execution, Design Sprints can lead to significant cultural improvements towards the ‘innovation mode’.

How to build Software Prototypes in rapid mode
_Best practices and guidance on how to rapidly build software prototypes and test your ideas to real users_medium.com

References

• Problem statement — https://en.wikipedia.org/wiki/Problem_statement
• Design Sprint book — http://www.gv.com/sprint/
• Design Thinking — https://en.wikipedia.org/wiki/Design_thinking
• Photo by Will H McMahan on Unsplash
• Related: How to lead innovation and drive change in engineering teams

Related articles

• Startups and the Importance of Agile Product Development
• Rapid Prototyping practices for Software Engineering teams
• How to lead innovation and drive change in engineering teams
• How (and Why) to Write Great User Stories
• How to become a great Product Manager
• Is this a prototype or an MVP? Well actually, it’s a proof of concept.
• How to setup and lead a great product development team
• Technology Innovation — Trends and Opportunities in 2018

In an ideal world, consumer-facing product development teams should have one designer for every four to six engineers. In reality this rarely happens. So I wrote some tips any engineer can follow when there’s a design shortage on their team.

Brainstorming at Airbnb

Context

I’m a product designer with a diverse background. I have worked in different industries from education and advertising to retail and technology.

I always thought of roles as a strict boundary between what my responsibilities are and what they’re not. As a designer, I would be in charge of design, and engineers would be in charge of coding. That helped me define my role and also have certain control over my responsibilities.

Last year, while I was working at Airbnb — a tech company renowned for its design culture — I faced a big challenge. After my on-boarding week, I landed on a team with 12 engineers, one PM, one data scientist, one researcher, and just me as a designer. I freaked out a little bit. How was I going to satisfy the needs of my team?

I thought about three possible solutions.

1. Working more hours. That was my first instinct. If I had to deliver design for more than twice the ideal number of engineers, I would have to work many more hours. That would seriously affect my life/work balance and eventually burn me out.
2. Slowing down. If I wanted to keep working at my usual pace, I would end up being a human bottleneck. Design requests would start accumulating and I would never have the time to catch up (which would have a serious negative impact on our team goals).
3. Letting go. As a designer, it’s hard to let go. We are proud to be the experts with the experience. Letting the whole team design felt like I was not doing my job properly, and of course, it had an impact on my ego. But with time, this proved to be the best approach.

Everyone is a designer

I’ve thought a lot about this subject, and I found a great article by Daniel Burka that ended up convincing me that this was the right approach. Everyone can be a designer.

Letting go didn’t mean that I stopped caring about our design. But I had to enable and encourage the rest of the team to use their design mindset and propose solutions to user problems or business goals. In the end, the user who uses your product doesn’t care if one particular screen or flow was designed by a designer or not. They care about the experience they are having, and that’s not a one-person responsibility.

In order to do this properly, I gave a few design tips and tools to our team and scheduled design office hours once a week. This provided a fixed spot where everyone could come with their design ideas to discuss it and share feedback.

_Photo by [rawpixel](https://unsplash.com/photos/3BK_DyRVf90" rel="noopener" target="blank" title=")

This process ended up having amazing results. In just a few weeks, we witnessed how some of those ideas got shipped to production with positive results. We were moving way faster than before and the team was super excited to see their design ideas out there in production!

Possible scenarios

Before jumping to the design tips for developers, I want to start by mentioning the possible scenarios you might face. This will depend a lot on what stage of the project you are in.

Scenario 1 - There’s no designer.

Probably the most common scenario among early stage startups or student projects. Having no designer on your team means you are the designer! Do not freak out, and use this opportunity to learn. I’m sure that if you follow some simple rules you can deliver a cohesive MVP.

At this stage, you are probably a very small team. Don’t spend a lot of time trying to build something beautiful, trendy, or eye-catching. Focus on building a great experience with a decent UI. You will have time to improve it later.

Scenario 2 - There’s only one designer for roughly 10 developers.

This happened to me last year, and your designer will certainly need help. How can you help? Propose ideas — don’t expect that everything will come resolved. Sit down with your designer and show them your ideas. They will definitely appreciate it. Join them in brainstorming sessions and give feedback. If designs don’t come fully spec’ed out, ask your designer for the source file and look at it yourself to save them some time.

Scenario 3 - There’s one designer every 4 to 6 developers.

You are lucky, as this is an ideal scenario! It doesn’t mean you can fully forget about design, but it is no longer of primary concern. I would still recommend that you join the brainstorming sessions to propose ideas and to give early feedback from your engineer perspective.

Design tips for developers

Here’s a list of design tips that will help you if you find yourself in the no-designer scenario. But they can also be applicable in any other circumstance.

Designer mindset

If you are going to design, it’s very important that you think as a designer. When you are designing, don’t think about engineering problems, but think about how to solve user problems.

The user comes first.

Let’s say you have to build a photo uploader feature. During your designer time you shouldn’t think about performance, code optimization, or platform limitations. Think about what is the most effective and intuitive way a user can upload a photo. Think about the user’s motivation to upload a picture. How can this process be straightforward and maybe even enjoyable?

Then, when you finish your design, wear your engineer hat and review what you just did, with your engineer perspective. Is this technically doable? How long does it take to build this feature as you’ve designed it? Do you have the time to build it? If not, can you reduce the scope a bit so you can reach your deadlines?

_Photo by [William Iven](https://unsplash.com/photos/gcsNOsPEXfs?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="blank" title=")

It’s very important that you don’t cross the line between roles, or you will end up limiting your design because of engineering constraints or vice-versa. If it helps, you can try dedicating mornings for design time and afternoons for engineering time. Or you can use an area in your working space to do all the design work, and then move to a different area to do your engineer work.

Build a plan

If you have an idea, before jumping straight to the code, build a plan. You can do wireframes, use sticky notes, a whiteboard, or sketch on a notepad — that’s up to you. Don’t skip this step even if you think you have all the details in your head. When you finalize your wireframes, review it and you will probably notice you are missing something.

_Photo by [rawpixel](https://unsplash.com/photos/u5XiXcOq2Tw" rel="noopener" target="blank" title=")

Balsamic is a good tool for rapid wireframing. You can also use Sketch or Figma for your whole design process from wireframes to production.

Start with a framework

Not having a designer on your team doesn’t mean you have to design everything from scratch. There’s a lot of already built frameworks that you can use as a starting point and customize them your way. Bootstrap and Foundation are my favorite ones, but there are plenty of them depending on the type of application you want to build.

_[Foundation](https://foundation.zurb.com/" rel="noopener" target="blank" title=") documentation

If you are building a native app, I strongly recommend that you follow Material Design’s guidelines for Android and Human Interface’s guidelines for iOS. Start with following the native patterns as closely as possible, unless you explicitly want to build a unique UI, like Snapchat, or a game. Only after you dominate the default patterns and components can you start customizing.

Design systems

If you are lucky to have at least one designer on your team, you can think about building your own design system.

Watch out!

This can be time-consuming and is only worth it when you are scaling fast and you have to maintain multiple applications with the same visual language. A great tool for building a design system is Pattern Lab.

_Airbnb’s [Design Language System](https://airbnb.design/building-a-visual-language/" rel="noopener" target="blank" title=")

Branding

As you build your framework you will probably start making decisions that will define your brand. Don’t feel intimidated by this! Branding is a fun exercise that you can definitely do. The brand you end up creating won’t get set in stone and you will probably hire a designer if your MVP is successful or if you get more resources. My friend Marc wrote a fun article about how to make a logo in about 5 minutes.

_[5-minute logo by Marc Hemeon](https://journal.designinc.com/how-to-make-a-logo-for-free-in-about-5-minutes-a4f409176a8e" rel="noopener" target="blank" title=")

Typography

After building your logo, you may want to choose a font family for the rest of the app. Google has a good beginner’s guide for choosing web fonts.

You can certainly use the same font you used for your logo, but make sure your font has good readability, especially if your product has large amounts of text. I recommend that you keep it simple and limit the number of font families to one or two max. Here’s a list of popular fonts.

_[Futura PT](https://www.myfonts.com/fonts/paratype/futura-book/" rel="noopener" target="blank" title=") my often weapon of choice for branding

A common technique is to use a distinctive font for headings and a more readable font for larger blocks of text. You can get inspired by these examples. A handy tool I use a lot to identify fonts on web pages is the WhatFont chrome extension.

When building your framework, be conscious about the number of different font sizes you use. Again, keep it simple. If possible, use the minimum amount of variations. Try to avoid going under 16pt for large amounts of text. Many people, like me, will have trouble reading under that size!

If your product needs it, use a proper font that supports many languages. Noto, for example, is a font developed by Google that aims to support all languages.

Color

Similar to typography, keep it simple. A common technique is to choose a primary color displayed most frequently across your app and a secondary color that provides more ways to accent and distinguish your product. For inspiration, you can use this color combinations page made by Tobias van Schneider, or use Material Design’s color tool to play around with color combinations. For more complex combinations you can use the Adobe color wheel.

When choosing two colors, avoid having vibrating color combinations. This happens when adjacent colors appear to merge, blur, and glow, giving the illusion of motion. Learn more in this article. Be careful with this undesirable effect if you create gradients.

_Unpleasant [color vibration](https://webdesign.tutsplus.com/articles/why-you-should-avoid-vibrating-color-combinations--cms-25621" rel="noopener" target="blank" title=")

Last, think about color contrast and accessibility. For an MVP, you don’t have to be fully compliant with WCAG. But with a little attention, you can reach some minimum degree of compliance. There are many tools to check your color contrast ratio like this one.

Iconography

Icons can definitely give some character to your UI and will help you in moments you need to synthesize complex concepts. They also take up less space and avoid long strings and internationalization problems. However, if you end up using an unclear icon to convey an important action, you will have a serious issue. If there’s doubt about the icon, use text only or an icon with a label close to it.

_[Noun Project](https://thenounproject.com/" rel="noopener" target="blank" title="), with over a million icons

Good sources for icons are Noun Project, Material Design icons, and Streamline icons.

Illustrations

Illustrations can help you support important messages that you don’t want to get lost. On average, users read at most 28% of the text. Having an illustration and reducing the amount of text can help the user digest that information. A small animation can make that moment even more delightful.

_High Five delightful moment by [MailChimp](https://blog.mailchimp.com/designing-the-freddie-high-five-animation-for-facebook-ads/" rel="noopener" target="blank" title=")

It’s hard to find the right illustration that fits your needs, so my recommendation would be to hire an illustrator to do it on demand.
Otherwise, if you don’t have the resources for that, you can always look for free illustrations and may find what you need. Just remember to give credit.

Photography

When I build a new product, I always like to create a set of photos that I call product in use. These show different scenarios of users using your product or enjoying the benefit that comes after using your product.

For example, if you are creating an app that helps you reduce the time spent on your phone, maybe you want to have a set of photos of people participating in outdoor activities, or spending time with their families.

Once you have this set of photos, you can use it to build the story and merchandise around your product. Use the photos on your onboarding tour, landing page, social media pages, or press release. Be consistent with the images you use, the style, the tone, and the age group. This will influence how people perceive your brand.

Usage of photography in onboarding tours can help convey value

An amazing source for free images is Unsplash. If you want to place your product in context, an affordable option is Placeit.

Prototyping

At some point you may want to build a prototype for testing an idea or a flow. You can test a prototype even at the wireframing stage!

A very simple tool for building prototypes is InVision, as it allows you to link a series of static images and build a flow with transitions that make it look like a finished product. Framer is another great prototyping tool, and it’s expanding its capabilities beyond prototyping every day.

_Prototyping with [Craft](https://www.invisionapp.com/craft" rel="noopener" target="blank" title="), a Sketch to InVision integration

Don’t get too attached to these tools that are constantly changing. Anything that works for you to test your idea (even paper prototyping) is fine.

User testing

By now you probably have a product or prototype that you are excited to test. Testing your product with only 5 users will give you early insights into what is working and what is not.

If you have the budget, you can use a tool like UserTesting. But if you don’t, you can do your own user testing recruiting family or friends as long as you keep it objective. Before starting your test, take some time to identify what questions you are trying to answer through user testing.

One easy and cheap way to test is the thinking aloud test. This consists of letting testers simply verbalize their thoughts as they move through the user interface after you give them a task. It is important that you keep quiet and don’t help the testers accomplish their tasks.

For example, if they ask you “What happens if I press this button” you can reply “What would you expect to happen?” Otherwise, if you give them the answer, you won’t learn from their experience.

_User testing with recording device. Photo credit [StartUX](http://www.startux.co.uk/services/snapshot-user-testing/" rel="noopener" target="blank" title=")

It could help to have a third person to document the session. It’s hard to be the moderator and take notes at the same time. If you can not find a third person to help, you can video-record your session.

Iterate

After launching your product, remember: Design is never done!

You will probably learn a lot after launching version one of your MVP. Take that knowledge and go back to the wireframing → prototyping → user testing cycle.

_Design is Never Done by [Kari Neuberger](https://dribbble.com/shots/2900760-Design-Is-Never-Done" rel="noopener" target="blank" title=")

Open conversation

I hope you find these tips useful and applicable to your every day work.

_Photo by [Agustina Perretta](http://agustinaperretta.com/" rel="noopener" target="blank" title=")

The challenge

I set out to see how far I could push myself creatively as a designer by rebuilding an App I frequently use.

I chose Tinder because I’ve used it a few times, and realized a few modifications to the design would be helpful. Of course I’m not suggesting that my design should be used instead of the current Tinder design. It’s just a different point of view from the current design of the App.

My Goals:

• Create a better user experience
• Facilitate the use of the application
• As a personal goal, to complete my first design project

Understanding the App

Tinder is a location-based social App that is most commonly used as a dating App with a target audience from 18 to 34. Since its debut in 2012, Tinder has undergone rapid growth thanks to its extremely simple way of use and amazing organic strategy.

The Home Page

Old screen and my redesign of it

Problem 1: Bottom buttons and Card swiping

As soon as a user opens the App, Tinder users have two prime features to indicate whether they like a profile or not:

• the bottom buttons
• the card swiping

So which of these should they use?

Both options are very good, but the card swiping provides a much smoother experience. If you compare it to other Apps that are increasingly implementing the card swiping feature, Tinder is far ahead. We should take 100% advantage of it.

After analysing the existing design, the “super like”, “like” and “nope” buttons were removed, with the card swiping gestures for these actions.

The following new buttons were added.

Dismiss Profile Button

Dismiss Profile

Let’s say you come across a profile that interests you and at the same time does not, you can dismiss it and go to the next one.

Message Button

Message

Feature for Tinder gold that would allow you to send a message to any profile, even if they have not yet liked you.

New swiping card - Friends

Tinder is listed under “Lifestyle” in the App store. Although Tinder isn’t marketed as a dating App, most people see it as one. Browsing through the profiles, I saw plenty of bios with something like “Just looking for friends!”.

So swiping down on the new swiping cards allows you to be friend of someone.

Problem 2: Changing pages to see a profile

This modification was something more personal. I didn’t like the way a user would navigate to a person’s profile. I did not consider the process fluid in the eyes of the user as we are constantly changing pages and it does not become very intuitive or practical if we want to go back after seeing the profile.

So I decided to implement the function of being able to see the profile of the user without leaving the main page. Swiping up would display the user’s profile and swiping down would return the user to the main page.

Redesigning the Tinder Feed

Tinder introduced the Feed feature that shows you real-time updates of your matches all in one place. Is a very good idea that will take you beyond “It’s a Match!” and help you make a real connection.

But to access this new feature you need to go to the messages. As I think we should take advantage of this I decided to remove it from the messages and put it on the main screen.

A user would just need to click on the feed button on the main screen to access all the news from their matches.

To navigate within the feed, I decided to implement two buttons:

• New - Clicking on “New” at the bottom of the screen on the right side would create a new post.
• Old - Clicking on “Old” at the bottom of the screen on the left side would navigate to the oldest post until we reach the last one.

The buttons:

• Message - Instant message to the connection without leaving the feed.
• Share - Sharing on social media.

New Feature: Tinder Experiences

Most people see Tinder as a dating App. But it’s much more, the experience can be more powerful. I implemented a new feature called “Tinder Experiences”, a way to take dates and meetings with friends to another level.

Discover places of the city where you are, meet people who share your passions, open up to new experiences.

Status

There are a few other things that can be implemented to improve the user experience a lot. One of them is to know the status of the user. So in a simple and minimalistic way I inserted the staus of users within the messages. This improvement allows us to know if a user is online, offline or inactive.

Another possible feature is to Filter users by when they were last active. This would allow a user to set a range in your “Discovery Preferences”, For example, display users that have been active within the last 30 minutes.

Conclusion

Going into this project, I knew that this would be the perfect opportunity for me to improve my design skills and push myself creatively. I’m studying computer engineering and at the same time studying design alone at home as I want to pursue a career in product design. I figured out that the best way for me to learn would be to just throw myself into a project.

So for me this is not the end of redesigning a mobile App and only the beginning.

Thanks for reading. I hope you liked it. ?

I would appreciate your feedback.

Moving from a concept to a properly defined MVP

The Minimum Viable Product, although a properly defined term, means different things to different people. In fact, it is one of the most misused terms in the technology domain. It is often poorly referenced to describe a prototype, a demo or even the first deliverable of a project.

“In product development, the minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future development” — Minimum_viable_product

Defining the MVP

Assuming you have this great idea, you need a method to start defining the product. More specifically, the subset of the product features that can serve your objectives with the minimum cost and risk. The following explains how to get from an idea to an MVP.

Identify your users

Set the context — think of the problem, the situation and the opportunity. Think of what is already available in the market dealing with the same problem. Identify and name the types of users involved and how they interact. Document your users, their needs, the problems they are experiencing, their expectations, and the best-possible experience they could have in your context.

The Minimum in the MVP implies that you already have the big picture, you have the product vision! A common mistake is when the team ‘easily’ identifies a set of ‘obvious’ use cases as the MVP — without a clear product vision and the big picture.

Check also: How (and why) to write great User Stories

Think as a user

Having the big picture you need to apply a process to identify the smallest subset of functionality that serves a very specific goal. The goal is to satisfy your users. You also want to enable critical user insights and feedback. This feedback can improve the next iteration in your product development plan.

The big picture is the super-set of user stories across all the classes of users identified. It’s a good idea to create a large set of epic stories. Then iterate across all identified users and try to define user stories covering their needs and expected benefit/ gains.

Use a compact format as the one proposed in Scrum: as a I want to so that <describe the gain>. You don’t have to worry about priorities at this stage. A good idea would be to name each story/ assign a compact title for easier classification and organization.

As soon as you have your product feature super-set, you need to review it to ensure that it defines a product (the P of the MVP). Search for continuity, homogeneity and complementarity among your user stories.

As a result of this process, you may realize that more than one of the related products are referenced in your backlog and need to be separated. Or you may realize that there are significant gaps that need to be filled.

Again, think as a user. Use empathy to identify interactions, scenarios and stories that need to be included.

You need to also gather feedback so you can try to validate your stories and the product. You can gather feedback through expert advice, user interviews, formal or informal surveys or public domain references (for instance any reliable public domain statistics that can help you test your assumptions).

Think as an entrepreneur

Thinking as a user is great. You can be creative and forget, for a moment, about real-world challenges such as technical and financial constraints. Your objective is to compile the product super-set of user stories to satisfy — or to even to excite — all the different types of your users.

Now it’s time to think as an entrepreneur. You need to start considering and documenting implementation costs, priorities, strategic advantages and differentiators against competition.

You need to estimate the development cost of each user story. You also have to quantify the expected value for the user along with the expected impact on the business: your business.

The logic to identify the right minimum subset can be complex — requiring estimates of all the above at the user-story level. For each user story (or Epic) you need to have at least the following:

1. The complexity / cost associated / feasibility

2. The expected value for the user

Estimates of the above dimensions could be on a numerical or ordinal scale. As soon as you have those estimations you can then rank your stories. Also plot them in a simple chart against complexity and expected value for the user.

Check also: How to become a great Product Manager

Prioritize, Rank, Set the focus

At this point you can start prioritizing high-value, low-cost stories over lower value, costly ones. Be aware, though, of those natural, strong dependencies between product features.

In many cases there are technical or procedural dependencies requiring certain features to be implemented first, although their cost is high and the expected user value low. These dependencies need to be identified and possibly visualized in the user stories mapping.

Having the above for each of the features (user stories) of your product allows you to define your MVP as:

“… the minimum set of features (stories) ensuring a good-enough product experience driving increased user engagement that can secure the next product development cycle”

You can sort your entire product backlog by dependency sequence (start with foundation). Then by the value for the user in descending order. Then by complexity and feasibility in ascending.

You can also combine budget constraints, team’s velocity and go-to-market strategy makes it ‘easy’ to identify the red-line of your to-be-proved Viable MP.

Reality check

In reality though, this will be just a draft definition of an MVP. What is needed in an ideal scenario is feedback and validation of the features by real users via prototyping, focus groups, market research, competition analysis and related methods.

The more input from real users, the more confident you can be that your product concept has all it takes to become Viable (which also assumes a great execution/ implementation/ launch).

Check out this other article on how to define an MVP (among other things).

Thanks for reading!

Images: pixabay

As a designer, your best work is going to always be invisible. It’ll be invisible because the best part of what you do will be everything that takes place behind the scenes, where nobody will ever see it.

Knowing this is important, as it can help to unlock your full potential and help you focus on what matters most when it comes to product design.

When first moving into a product design role, the novice tends to conflate the work of product design with that of a more traditional design role. They want to be recognized for what’s on the face of what they build, so they focus on making it attractive or flashy. Or they want to make something beautiful without dedicating much time to building empathy, or deeply understanding the problems, or developing or identifying a clear design system.

Of course beautiful designs, and well-crafted experiences, matter quite a lot in product design. But the actual pixels behind a design are only as good as the reasoning behind them.

Consider the fact that almost anyone today can download tools to design and create products. All it takes is a laptop and an internet connection. And once you have the tools, you can use online tutorials to recreate what you find inspirational out in the wild.

Having access to complex tools is no longer a separator between the amateurs and the pros. A formal education is no longer a requirement to do quality design work. What matters now isn’t your ability to even use design tools well, or to know the lingo of the trade, or even to have a flashy portfolio. The most important thing is everything that takes place behind the scenes.

Your approach to research and having access to resources for conducting it. Iteration, testing, and gaining perspective. The exploration of edge cases, and the decision making around each of them. The ability to deeply understand what problems are being solved and the trade-offs that must be made to build a usable, and beautifully designed, end result.

In other words: designing with intentionality.

Nobody will ever see the research or the deliberate decisions made around trade-offs. Nobody will see the entire system you design, laid out bare on your computer or in your notebook. Nobody will ever see your ideas for personas, or the results from the research you do, or the hours you’ve invested in iterating on a single attribute of your design. Nobody will go through past conversations you’ve had with peers, co-workers, and potential users about your design. But these things will absolutely be reflected in whatever it is you create.

If we look at some of the most famous paintings in history we can see a very real interpretation of what I’m describing here. Using X-ray techniques we can see layer upon layer of old paint hidden beneath masterpieces like Picasso’s The Blue Room, Van Gogh’s Patch of Grass, and even (highly debated) da Vinci’s the Mona Lisa.

Beneath each work of art lies another, often rougher or incomplete work of art, the product the artist slaved away on before smothering it in even more paint, to get the details right. Often we can see not just one, but several paintings buried beneath the final work.

We can see this intentionality in modern design guidelines too. Like Apple’s Human Interface Guidelines or Google’s Material Design. Each design system contains a vast library of design principles and recommendations, some of which are so nuanced it will make any non-designer’s head spin. Just look at Material Design’s color page for an example of the thinking that has gone into color alone; the page is massive and rich with detail.

To put this another way: in anything we do, the gift we give others is investing our own limited time into the work.

Trying to find shortcuts to get to a final design, or focusing on only one attribute of the work, or tabling research or iteration just to get something out the door — these things never help the end result of the work you’ll do. They’ll merely hinder it.

What can often make a product experience so impactful is the work those who created put into it. To build something in such a thoughtful way that makes anyone oblivious to the fact.

To quote the famous entertainer Teller, of Penn and Teller:

“Sometimes magic is just someone spending more time on something than anyone else might reasonably expect.”

— — — — — —
Tanner Christensen is a self-taught product designer at Facebook, author of The Creativity Challenge, founder of Creative Something, developer of some of the top creativity apps, blogger on Medium, former writer for Adobe’s 99u and contributing author for Inc.

I used to be confused about whether I should introduce myself as a front-end developer or as a designer. I would switch back and forth based on the situation and whom I was talking to.

Applying to a design studio? I better call myself a web designer. Being interviewed by a software architect? “Hi, I am a web developer!”

Then I found my dream job at a large design studio:

Me: “So would I be a front end developer or a designer?”

Recruiter: “Both! Everyone here is a designer, but your discipline would be front-end development.”

Me: “Crap. I’d better take a design class then.”

Semi-Pro Tip #1: Do not mention that you have never taken a design class to a design studio recruiter.

Feeling intimidated by designers

So I immediately registered for my first design class to take during my final semester of college. The class helped me grasp some basic user experience concepts, but I still ended up reporting to my new job at IBM with a major inferiority complex.

I entered the role surrounded by research, visual, and UX extraordinaries. They were all focused on user pain points.

Contrast this with me. As a developer, I was conditioned to just ask which features I needed to implement, then decide how best to do that.

Anxiety started to overtake me. I started to think that maybe I had made the wrong career choice.

Maybe I should have joined a department of strictly developers.

Maybe I should have joined a studio that hands off designs to developers without expecting their feedback in return.

Or maybe I should have just given freelancing a shot for a year before joining a large multidisciplinary team.

On the job, this anxiety resulted in shyness.

Semi-Pro Tip #2: The f-word in design is “feature.” There is no product correlation between the amount of features and the quality of the user’s experience.

Learning to walk both worlds

Luckily, IBM Design had a three month entry-level design bootcamp, which taught me that I could be both a developer and designer. So I soaked up skills from my peers and absorbed as much of their expertise as possible.

The program forced me to take part in activities that helped me understand our users. That’s when I fell in love with the process of writing user stories to document their struggles, then trying to solve them using my development skills.

One key takeaway was that our team became more successful the more time we spent together. There was always a temptation to split up to work alone, then come back together. But we had to fight that.

Pair programming with a visual designer helped me greatly. It taught me more visual principles than reading any intro to UI patterns book I could find. At the same time, the visual designer — who had previous worked in print — could learn principles of responsive design quickly from me.

Throughout the camp, I learned the true power of multidisciplinary teams. We taught each other about research, user experience, visual design, and front-end development — all in a natural, conversational way.

Teaching developers how to think like designers

A couple of months after graduating from the design bootcamp, I was given the opportunity to attend a college hackathon as a sponsor.

The event was filled with developers who wanted to make epic solutions for various problems. I thought I was there to help participants debug their web apps, but I ended up helping a lot more with design.

_Check out how simple — but crazy — a hill can be at the [Hill Generator](http://seejamescode.github.io/hill-generator/" rel="noopener" target="blank" title=").

First, a guy came over to show off how he had already used an API to visualize some data. After congratulating him on this technical feat, I asked him what his user goal was. He admitted that he had no idea. So we started writing hills based on IBM’s Design Thinking docs.

Next, another developer wanted help with their color choices. A year ago, I would have been the absolute worst person to ask for help with this. But I didn’t flinch. I asked him what he wanted the web app colors to communicate.

Dev: “What do you mean? I just know that our color choices are ugly.”

Me: “Ah, you are talking about styling. Your colors can do more than just make things look pretty. Why would a user not want to use your app?”

Dev: “Well it is a money management app. I don’t know if people will trust us to handle their money.”

Me: “So let’s see if any research has been conducted about colors that resonate with trust and money!”

With the right question in hand, we were well on our way to researching and selecting the right colors.

The second day of the hackathon, I talked with a team was killing it and getting better with every iteration. The team already had a complete “cupcake” (full experience, but minimal version) of an app. They knew it was time to gather feedback, but did not know how to go about doing this.

This turned into the perfect chance for me to walk them thru their first user testing session. The team learned to provide simple goals to the user, one at a time, then ask the user speak out loud their thoughts during every interaction and every screen.

Semi-Pro Tip #3: If your user is not vocalizing their thoughts to you, how will you know what they’re thinking?

So what am I, then?

Our multidisciplinary team at the design bootcamp may have sucked at hi-fives. But we learned a lot of other stuff from each other.

Of course, I was still able to stretch my front-end developer muscles at the hackathon. There were always plenty of JavaScript and CSS bugs to help out with. I love doing that work. After all, web development is what got me started down my career path. (Actually it was project management, but let’s not go there.)

So who am I? Thanks to my studio’s design training , I now feel qualified to say I’m a designer. But doing this does not marginalize my role as a developer. Instead, I am now able to touch a product’s growth from the first research interview all the way to the production code we ultimately release.

So what are you? Are you a designer with a background in data analysis and/or visualization? Are you a designer who understands product strategy?

I encourage you to engage with full-time designers in your organization. Offer to share your strengths with them. Then stand back and learn from theirs.

For further information: Feel free to contact me by the comments, email, or @seejamescode. I work in ATX for IBM Design and always love conversation with the web design community. Also be sure to share your own career identity crisis in the comments!

Recently in a Facebook group dedicated to designers, known as Designers Guild, a young design student named Marina Candela asked why many modern designs tend to feel so terrible or “backwards” looking, like digressions. Specifically designs from large tech companies like Uber, Apple, or Facebook.

You don’t have to read all the latest headlines or browse the countless unsolicited redesigns on Dribbble to understand what this question entails. For many people, both designers and not, the gut reaction to seeing a new design is typically: that is stupid.

The problem with this is that design is not a process of beautifying things. Designers don’t get paid to make things necessarily look nice. Yes craft is certainly part of the job, but it’s not the job.

There’s a lot of work going on behind the scenes when design decisions are made. More than you might imagine.

This is particularly true for companies like Uber and Facebook, or really any large company today. Design at these companies entails everything from research, experimentation, iteration, lab or small group testing, and real-world testing. Each of these steps can take anywhere from a few weeks to months, with the time invested in researching, conceptualizing, and testing, reflecting the potential impact of the design decision. The larger the design task, the longer it takes to move on it.

It’s common for amateur designers and the average Jane or Joe to look at design projects like Uber’s logo or a new design for Instagram or Facebook, and respond solely with their gut. “This looks worse than before! How can anyone understand this?! What were they thinking? This is terribly designed.”

In reality, these are vastly more surface level responses then what design intends to deal with.

The purpose of the design isn’t always to make something look good, or even better than before. What these design processes are about is solving a problem.

Good design solves problems.

Sometimes the problem is that customers view your brand as a lower-scale version than what they are paying for, which dilutes the value of the company. Other times the problem is that the platform you’ve created is itself outweighing the content it produces or hosts. Or that a primary feature has become hidden, or an influx of new features has crowded the interface, or what you and your team thought made reasonable sense is immensely confusing for people who use the product out in the real world.

Other times still there are issues the common designer may never be aware of: scaling a website to suit the needs of almost everyone on the earth, for example. That’s a really hard problem to solve, and an equally hard problem for most people to wrap their heads around.

My own experience at Facebook is a good example of this. Most designers will say that Facebook is extremely ugly (and as a designer myself, I tend to agree). Yet Facebook doesn’t have to look phenomenal to work well. And this is what I’m most proud of being a Facebook product designer: the problem of scaling a product for the entire world to use is really, really hard, and yet Facebook is doing it fairly well.

Consider a few of the problems a designer working on Facebook may encounter: Every word, every button, needs to be translated to hundreds of languages, which creates issues with layout spacing among other major hurdles. Content reverses sides of the screen depending on which part of the world you’re in (left-to-right text VS right-to-left text). In some parts of the world certain types of content are simply outlawed, and placeholder or legalese must be put in its place dynamically. Some people use Facebook on their $700 iPhone with unlimited data plans while others use it on a $5 flip phone and only 1mb of data to spare each month. Some people have an internet connection that is 1,000 times slower than others, which means things like images and app size really matter

The best designers consider not only the objective of a project (like the ability to live stream from the app) but also the constraints they must work within and the issues they must work around. Not only that, but much of the design process we encounter day-to-day should be about determining whether or not the problem being solved is the right problem to solve to begin with. And if it’s not: how do we go about identifying the real problems?

So while it’s easy to look at a design and think it’s ugly, or lame, or a digression, the reality is that there are many, many, many, many decisions being made and considerations taking place behind the scenes which have led to the latest design.

And if the team behind the design has done their work well, they’ve tested and experimented and validated their work enough to push it to the place where people like you or other designers can finally get a look at it.

That doesn’t mean the design is done, but it does mean that it’s “done enough” to satisfy any major concerns.

One thing you can do to better equip yourself to evaluate design work is to step back and think of all the scenarios the person(s) responsible are attempting to address. I outlined a few we encounter at Facebook above, but I’m sure you can come up with many more of your own.

Before judging a design you should ask questions like:

• What problem is this attempting to solve?
• Who is it solving it for? If not me, then who?
• What problems or scenarios might those people encounter that this design is considering?
• What are the limitations being designed for?
• What about constraints?

Lastly, as additional food for thought, consider the fact that people simply don’t like change. Change presents challenges we mostly want to do without. But change is inevitable, and while new designs can feel strange or unfriendly at first, we inevitably grow into them because… well, time works that way.