Starting a design system

Questions you should answer before you get started

This past year my wife and I went through the process of finding a new home. During the many months we spent looking for a home, we discussed building a house. We were frustrated by our inability to find what we were looking for over many months. Maybe building a new home was the way to go.

We had never built a house before, so we were unsure about the process or costs involved. Our first step was to sit down with a builder. Through that discussion we learned the benefits of building a new home, but also the higher costs associated with it. We could get the house we wanted, but we would pay for it up front versus potentially in stages with a pre-existing home.

My wife and I were weighing how we might allocate our resources among other competing concerns we had in life. The same is true of design systems.

A common question I’ve received from designers as they’re starting a design system is where do they start. Do they build something from scratch, use a pre-existing system (e.g. Primer, Tachyons, Tailwind), or start with what you have? Essentially we have the same decision as the one I had to make earlier: do I build a custom house, purchase a pre-fabricated house, or remodel an existing home?

And the answer, like many things, is… it depends.

Dan Mall, speaking about design systems, has this great quote:

[A lot of designer’s] first inclination as to what a design system is is a UI kit, and that’s not what a design system is. That might be part of a design system, but … [it’s something] only designers can use. Part of a good design system is that it’s a tool that everyone on the team can use. (Emphasis mine)

A good design system works for everyone. Designers shouldn’t be building design systems independent of other teams—instead they should be gaining consensus across teams.

So if you’re starting a design system, consider the following items with your team—just like when looking for a new home.

What’s your current state—and does everyone agree?

If you’re looking for a new place, it’s probably because there’s something about the your current place doesn’t meet your needs anymore. Maybe you’re moving to a new location, or your current place is too small or too far away. Whatever your reasons are, you’ve found deficiencies with your current place.

It’s the same thing with a design system. In order to start working on one, everyone needs to agree on the current state of deficiencies. One of the biggest things that will slow down your ability to create and implement a design system will be that not everyone on your team agrees that there’s a problem in the first place.

A great way to start gaining this agreement is to do a pattern and component inventory. Identify people across multiple teams who could help. Have everyone take screenshots throughout the product, gather those screenshots into a shared document, and organize them with your team.

This inventory is helpful for a few reasons:

1. It helps you understand the product’s current state. Before you start a new project, you should know what you’re up against. Doing this exercise allows you to walk into the project fully understanding the problem in front of you.
2. It encourages you while building your design system. Just like when finding a new home, you forget somedays the reason you’re going through all the stress, anxiety, and frustration associated with this process. Having a document like this allows you to be reminded of the problems you’re trying to solve.
3. It helps others understand why you need a design system. Explaining to your boss that you want to start a new project isn’t easy. They have other concerns weighing on them. It’s your job to help them understand how a project like this will help the team and your customers, both immediately and in the long-term. A document like this provides an artifact that illustrates the problems that exist today quickly.

When I started building a design system at Stack Overflow, it wasn’t until we did an inventory like this did people understand the time and effort we were wasting, as well as the poor experiences we were providing to our users. Once people saw these deficiencies, they supported the project.

So before you jump into your project, take the time to find out what your current state is.

What will it cost to get started—and where should you start?

Everyone agrees that you need a design system. Great! But how much time and effort is your team willing to contribute toward a system?

You may want to move to a new place, but before you start looking you need to make sure you can afford it. The same is true of design system projects. Some teams will be able to fully support an effort like this right away, which is great! However other teams will agree a design system is needed, but they aren’t able to dedicate much to the project initially.

At Stack Overflow, people understood we needed a design system, but they weren’t sure about making a big commitment. How much would that cost? How big of a project are we talking about? How much time will it take to implement? Will this slow down the team as they learn a new system?

If you find yourself being asked the same questions, here are a few things you could do to help make a case for a design system.

1. Identify what’s most important for your team. For some teams, maybe a HTML/CSS pattern library is the best place to start. For others it’s a copy style guide, UX patterns, or motion library. You don’t have the time to do it all. Instead focus your efforts on your area of biggest need.
2. Keep your scope limited at first. At Stack Overflow, our initial focus was a pattern library composed of utility classes (padding, margins, grid system, typography, colors, etc), buttons, and forms. That’s it. Eventually we added other items, but it was enough to get us started and show the power of the system.
3. Set deadlines—and be accountable to them. It’s easy to get excited working on a new project, but then the weekend comes and the project gets forgotten among the more pressing project needs the following week. One way to make sure that doesn’t happen is by setting project deadlines and holding yourself accountable by sharing those goals with others.
4. Keep an open line of communication with your team. As you start to implement your system, ask others for feedback. What’s confusing? Where could the documentation be better? How could the system support them better? Figure out how you can support the team by regularly gathering feedback.

What could we do today—new builds versus remodels?

At the end of the day, what people care about is how will this system help them do their job better. Now that your team understands the effort involved and resources available, you can determine what you can do today. Do you build a new house or remodel one? Do you build a system unique to your team or modify one to meet your needs?

There’s no wrong answer here. It depends on your team needs, time, and ability to adjust to new systems. No matter your approach, here are few tips to consider when you start the process:

1. Stand up your design system alongside your current product — don’t try replacing it all at once. We tried multiple times at Stack Overflow to replace existing styles with new styles. And time and time again we would find undocumented implementations that would end up breaking when new systems were implemented. Not only is this frustrating, but it looks bad for your team. Instead stand up a new system alongside your current system. This allows you to either cut over to a new version immediately or slowly move older items over time.
2. Figure out what’s in your Design System MVP. Design systems should meet your team’s needs. Just because something is in Lightning, Polaris, or Solid doesn’t mean you need it. Those teams built those systems for their teams. Once you know what your team needs the most, figure out what items within that area you need to get started started.
3. Documentation is the life-blood of a design system. If you don’t document it, it doesn’t exist. You can’t expect people to use a system if it isn’t documented well. Writing documentation is difficult. It takes practice. But the payoff is that you’re enabling others to quickly understand how to use a tool to help solve their problem without you being around.

Starting a design system can be an exciting time. Like looking for a new place, it seems only your imagination is the limit to what your design system could do for your team. Yet every great system out there didn’t happen overnight. Instead it took diligent, methodical work over time, building on previous efforts to get where they are today.

Focus on what your team needs first. Work from there. Eventually you’ll find that you’ve built an amazing home in the process.

Starting a Design System was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

This year marks five years working remotely for me. After spending the previous decade working in a traditional office environment, I’ve learned what helps make distributed teams work well—and some of their shortcomings as well.

Given my experience, I’ve had the opportunity to chat with a few people on the topic of distributed design teams recently. Most questions surround the topic of getting started and how to make sure remote team members feel included with the team.

Working remotely is different. It’s forces organizations to move from an oral culture (i.e. “Hey let’s just hop in a conference room and talk about X for 30 minutes”) to a written culture (i.e. “Let me document my thoughts and share with the team so we can discuss it”). This is a natural, growing step for most organizations. Organizations typically make this transition when grow beyond 50 people and becomes more pronounced the bigger the organization gets. As organizations expand within a location or add office locations, it becomes harder to communicate orally.

Instead organizations need to move to a written culture, creating historical artifacts for others that help document the purpose, focus, and scope of decisions. These artifacts can then be revisited weeks, months, and even years later to provide needed context for those who had forgotten why a decision was made or weren’t around at the time.

Remote teams are no different. By distributing your team, you are forcing your team to adopt a writing culture. However remote working also introduces some unique challenges. Unlike a new office location, remote team members are very much by themselves. They don’t have an office support staff or HR department close by. There aren’t any other co-workers physically near them. This can lead to remote workers feeling alone at times, which is why it’s crucial for organizations who want to hire remote team members to properly support them.

The more remote team members you add, the easier it becomes supporting them. While it may be hard initially, the pay-off is it allows you to expand the potential candidates you can add to your team and retain current team members who may have to move, but still want to work with you.

So if you’re considering hiring a remote team member, here are five key lessons I’ve learned working remote the last five years:

If one person is remote, everyone’s remote

For teams thinking about adding remote workers, the biggest thing I can stress is that adding remote team members changes how everyone works.

Far too often I hear stories of organizations who hired remote team members, but never properly changed how they worked to account for this new dynamic. It left everyone frustrated by the experience. Remote team members didn’t feel involved and non-remote team members didn’t have insight to what remote team members were doing.

Adding remote team members changes how everyone works.

At Stack Overflow, the company’s core philosophy for remote working is if one person is remote, everyone’s remote. But what does that mean? It means that no matter where you work, in an office or remotely, everyone approaches things the same way. It’s the only way remote teams are possible.

A few practical examples:

• If you need to schedule a meeting, don’t hold it in a conference room. Instead everyone should join from their desk in a video hangout. Too often people joining a conference call remotely can feel left out or forgotten about in a conference room discussion. By having everyone join the same way, no one is at a disadvantage.
• Product decisions aren’t decided on a whim over lunch or after-hours. Instead any discussions which may take place are documented and presented back to your team so everyone has the opportunity to review and provide feedback. This not only helps remote team members feel involved, but also helps them know that they could propose ideas in the same way and receive similar feedback.
• Communicate via chat first before hoping in a call. Not only does this respect your co-workers time and priorities, but allows others to respond you may not have considered asking initially.

Even if you work in an office, these are simple things that you can start doing today to help remote team members feel included.

Treat everyone the same way

When you’re a remote team member, it’s easy to feel left out. When you see office co-workers enjoying perks you’re unable to enjoy, that exasperates the feeling, making you feel unappreciated and as an after-thought.

To combat this, companies need to consider how they might include remote team members—even if they’re unable to be physically present. A few practical ways:

• Does the company provide a working area, desk, office chair, computer equipment, and internet access for people in the office? Of course! Well, do the same thing for remote team members. Set them up for success by giving them tools they need to get the job done.
• Is the company throwing a party? Great! Invite remote team members to join you if they’re close-by or allow them to expense their own party if they’re too far away.
• Do you hand out new swag to team members? Make sure someone is sending it out to new team members as well.

These are some of the ways Stack Overflow makes sure remote team members feel like any other employee—whether they’re in the office or not.

Embrace flexibility but have overlap

One of the great things about working remotely at Stack Overflow is that you can work from anywhere and when you want. You don’t have to spend thousands of dollars and countless hours every year commuting into an office. Instead you choose where you want to work and when works best for you.

Having remote team members means you have to embrace being flexible. Maybe some team members will outside your time zone, work earlier hours, work later hours, or may have to take a 2–hour break in the middle of the day because of some personal items. That’s okay—as long as you communicate and still have have overlapping working hours.

At Stack Overflow, my product team is composed of 9 people, each working in a different area of the world: Brazil, Poland, London, Boston, New York City, Los Angeles, San Francisco, North Carolina, and Pennsylvania. That’s 9 different places spread across 9 hours! The only way we make it work is that we all share at least 3–4 hours every day during a normal 8am–5pm Eastern Time Zone (ET) workday.

When you have team members living in different time zones, it’s unlikely they’ll be able to share the exact same hours as you—and that’s fine. Just be sure to use the time you are working through outstanding items that require conversations when everyone’s available.

Communicate asynchronously

Hiring remote team members means everyone won’t be working at the same times. This means you can’t rely on having face-to-face conversations to relay information. Instead you need to write down your thoughts, questions, status, or roadblocks so team members can respond when they’re available.

Google Docs, Trello cards, chat messages, GitHub pull requests—use the tools your team already uses. Whether you’re remote or not, this is a great habit to get into regardless. It respects a co-worker’s time by allowing them to respond when they’re available—not when it’s top of mind for you.

This could introduce some lag, yet that lag can be kept to a minimum by setting short deadlines for responses and holding team members accountable. Video hangouts will still happen, but they’ll serve more as an opportunity to review and clarify.

Get together at key moments

When I worked in an office, I was interrupted (intentionally and unintentionally) regularly. As I worked on increasingly complex and difficult design problems, it became harder and harder to properly concentrate at the office. Instead I found I needed to work somewhere else or come in earlier before any else showed up.

By working from home, I now have the ability to concentrate every day without countless interruptions. Yet there are some office benefits I do miss: being able to more quickly build repertoire with co-workers and some tasks I’ve found are better done in person than remotely. For these reasons, it’s good for teams to schedule meet-ups to get together. There are a few different reasons to meet-up:

• Company meet-ups: These exist as a way for the whole company or large departments to get together. By having the larger team together, you encourage interaction that you don’t normally have on a day-to-day basis. As a company you can celebrate successes, challenge each other for the coming year, and spend time getting to know each other.
• Team meet-ups: With some much going on at company meet-ups, it’s hard to schedule large blocks of time to discuss more pressing issues for your immediate team. Invest in your team by scheduling a separate time to meet-up. During this time you can talk about more practical items that affect your team.
• Product team meet-ups: A few times a year, product teams will need to conduct a few days of brainstorming. In these moments, it’s good to get key people together in one place and work together. While this can be done remotely, I’ve found it a frustrating experience because of the time zone differences. Instead of making a difficult process even tougher, schedule some time together in the same place.

If you’re considering adding remote team members, do it! While change can seem unpleasant in the moment, these positive changes will allow your team to more easily include amazingly talented individuals who happen to live somewhere else.

Five key lessons learned from five years working remotely was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

Two weeks ago, we released Stack Overflow for Teams — a way for teams to share information privately. A ton of work over the last year has been done to release this exciting new product. This post goes into how we designed the custom Team onboarding experience and how we see this feature possibly expanding in the future.

Hard problems

The hardest problem at Stack Overflow isn’t creating the functionality to post questions or answers, notify users of these posts, calculate reputation, commenting, voting, or any of the other various tools that are used within a community (These are all core features to a Stack Overflow community.) The hardest problem is starting a community.

If you’ve ever tried to start a forum discussion, chat, or other type of online group, you’ve experienced the massive amount of effort needed to start that group. And once the community starts generating some momentum, your work doesn’t go away — it shifts toward increasing the community’s momentum. It’s difficult work, which is rarely recognized.

In fact, if you’re a part of a community like this — take a minute and tell the community owners how much you appreciate the effort they put into helping shepherd and guide that community.

Small(er) communities

One interesting feature about the Stack Exchange network is that anyone can suggest creating a new community. If there’s a knowledge area that interests you and potentially interests others, you can submit your idea on our “Area 51” website. This website walks you through a number of steps to help you go from a community idea to an actual Q&A community.

One criteria we’ve held for new communities is that they need to be of a certain size and show consistent growth for us to “graduate” that community as an official Stack Exchange network site. There have been hundreds of proposals submitted, and failure to reach the needed community size is consistently a top reason for a community’s inability to graduate.

Understanding the problem

One of the largest, initial problems for Stack Overflow for Teams then was a three-fold problem:

1. Communities are hard to start.
2. Smaller communities are even tougher to start and maintain.
3. An inability to solve problems 1 and 2 will mean Stack Overflow for Teams doesn’t have a future.

This is a big problem. It’s also a unique problem. How do we help anybody start their own private Q&A community and be successful at it?

Some key findings

Thankfully we had already been starting to think about this problem for our Stack Overflow Enterprise customers. Through this team’s work and other work the User Research team conducted, we started to learn a few key things:

1. Identify people who really care about this.

It’s hard work to start a community, and it becomes even harder if people don’t care about the community’s success.

2. Starting with an empty community rarely works.

It’s really tempting once you create a Team to let everyone know about it. The idea is that if you build it, people will come — right?

What we find though is that people prefer to have some content already in place. This seeded content removes the decision paralysis that comes with a blank canvas: there are so many possible questions that could be asked, that you end up asking none.

Seeding content provides some ideas right away and helps people overcome this paralysis a lot quicker.

By sharing the community setup workload … , the task becomes easier for everyone.

3. Don’t go it alone.

If we find that starting with an empty community doesn’t work, the goal during setup becomes about creating some initial content before everyone else joins in. While this content could be created by 1–2 people, we found that the task becomes a lot easier if its shared with 7–10 people. By sharing the community setup workload with this core group, the task becomes easier for everyone.

Testing ideas

Taking this initial research, our next step was to test out these ideas. A typical project at this point at Stack Overflow would have had us writing a spec, creating some wireframes, designing artwork, and building a prototype before testing it with users. This process would take weeks for us to learn crucial information. We didn’t want to waste weeks to test an idea, so we changed our approach by testing lo-fidelity versions within a couple days.

Using slide decks and clickable prototypes we were able to test and adjust our ideas within a couple weeks versus a couple months. We knew that above all else, clear copy would win the day. So we created a simple Google Slide presentation with our proposed copy and interviewed a number of individuals to gauge their reactions.

By testing the ideas out early and in such a low-fidelity manner, we discovered two things:

1. By keeping things low-fidelity, we didn’t become attached to the idea. Since we hadn’t invested a lot of time in the ideas, letting go of them became easier.
2. Because we were able to let go of ideas more easily, we were able to iterate more quickly.

Altogether we were able to test multiple low-fidelity versions within a two-week period.

Finalizing our checklists

One thing we learned during our research was that people responded well to being provided a setup checklist. One person, upon seeing the checklist, remarked that it helped them better understand the effort level required to start their community, which they had not considered before.

Every feature or task holds some value — otherwise why would we have it? The hard part when creating onboarding workflows is identifying the core items people need to understand at specific moments in the process. For example, while it might be a good idea for someone to understand how to create a new tag, this isn’t a primary concern. Understanding how to create a tag only becomes important when people are asking and answering questions.

Our goal was to help a Team focus on specific, core tasks during certain stages in their first 60–90 days. We divided these tasks into three groups:

1. Setup period: Initial 10–14 days during which 5–10 people help seed content and get the Team setup for everyone else to join.
2. Launch day: The day you’re ready to invite everyone into your community.
3. Post-launch: Provide community goals for the next 45–75 days to help continue and maintain momentum.

Every task within these checklists reinforced core activities that are regularly found within successful communities.

Along with the checklists, we also created starter questions. Going back to one of our original key findings: “Starting with an empty community rarely works.”, we found this applies to Team creators and guides as well! To help this first group get started, we provide questions that range from identifying people within a team to type of questions that should be asked. These unanswered questions allow for admins and Team Guides to jump in right away and start providing thoughts.

Looking ahead

This is just the beginning for onboarding. Our goal isn’t just to start communities, but to create strong, healthy, lasting communities that are trusted sources for a team. But that doesn’t happen if people don’t continually participate. So we’re exploring how we can continue to help teams as they reach the 90-day period and beyond.

That said, we know it’s not perfect and we’ll continue to test and observe communities as they use the current onboarding process.

We also excited about the possibility of taking this work and bringing it back to Area 51 for public communities. Much of what we’ve done within Teams applies within a public community setting as well.

Healthy, strong communities don’t just happen. They’re products of purposeful, diligent work from a cohort of dedicated individuals that help provide a place for others to join in and share. By providing initial guidance, we hope that everyone will feel confident in starting their own community today.

This post was originally published on the Stack Overflow blog.

How we tested, designed, and built a brand-new team onboarding process was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

Before applying for your next job, plan where you’re heading.

Q: I’m graduating soon and entering the job market. What tips can you give for someone starting out?

That age-old “getting started” question: how do I get started? It may get asked a lot, but it’s a great question—and here’s why: you’re thinking ahead, and that’s a great first step. Instead of letting things happen as they may, you’re proactively think about how you can land a job. But before you start, you need to start much broader.

Make a plan*

*Plan subject to change.

The first thing to do is step back and ask yourself what do you want to be doing 2, 3, or even 5 years from now. Do you know? If not, think about it. Look around. What jobs look interesting? Or is there a particular industry that intrigues you? Think about where you want to end up changes your perspective.

Are you interested in being a product designer? Great! Find a bunch of product designers you respect and reach out to them. If possible, meet in person or over a hangout. If that isn’t an option, do it via email. Ask them how they got started, their career path, and what they would do differently in hindsight. Most people are happy to help others, especially when passing along lessons learned.

Like a qualitative user research session you might run, reach out to at least 10–15 people. Vary the people you’re reaching out to as well. Whether that’s by age, gender, ethnicity, company size—whatever you want your criteria to be. Just don’t get 10–15 of the same people.

Treat this like a user research session, except for your career. Your goal is to learn what you don’t do know. After interviewing people, you’ll start to see patterns emerge. This is beneficial for two reasons:

1. You’ll have a roadmap

A roadmap is beneficial because now you’ll know the general path others have taken to where you want to go. You’ll have a rough idea for the possible skills, knowledge, and experience that you’ll need to acquire. Your plan can change, but now you have a roadmap to get there.

2. You’ll have realistic expectations

Looking back, this is my biggest regret. I had improper expectations coming out of college. I overvalued my skills, knowledge, and experience. I was looking for that amazing job right away because I felt I was ready, but I still had more to learn. I would have been better served finding a group of great designers to work with then finding a specific role.

Based on your interviews, you’ll know what a “first job” will look like for you. Yeah, it’s not probably not going to be glamorous or exciting, and some days it might suck—but you’re going to learn a ton. Remember your first job isn’t the end, it’s your first job. It’s a step. It’s a short period, allowing you to grow personally, so that you can take that next step. Enjoy it.

Get started

With a roadmap and realistic expectations, you can now start applying for jobs… a lot of jobs. Before starting at Stack Overflow, I applied for almost 100 different positions. I heard back from maybe a dozen, had multiple interviews with maybe 6, and a design test or portfolio presentation with 3. That’s a lot of “No”.

But that’s okay. All you need is for someone to say “Yes” once. Don’t take rejections personally. If you do get a rejection after a few interviews, reach out and ask why. They may not respond, but sometimes they will. I did this once and discovered my portfolio presentation skills needed some work. It was great feedback, which helped me in subsequent interviews.

Applying for your first job should be exciting. It’s the first step of many to the place you want to be. So put some time into thinking about where you want that career to head.

The most interesting things the Stack Overflow Design team shared for the week of March 19th, 2017

Stack Overflow 2017 Developer Survey Results

Stack Overflow Developer Survey 2017

The annual Stack Overflow survey results were released this past Wednesday, and—naturally—it was the main topic of conversation for us this week. It’s been neat to see this survey grow to become one of the largest industry surveys. This year over 64,000 (!!!) developers took the survey. Some key findings:

A common misconception about developers is that they’ve all been programming since childhood. In fact, we see a wide range of experience levels. Among professional developers, 11.3% got their first coding jobs within a year of first learning how to program. A further 36.9% learned to program between one and four years before beginning their careers as developers.

Only 13.1% of developers are actively looking for a job. But 75.2% of developers are interested in hearing about new job opportunities.

When we asked respondents what they valued most when considering a new job, 53.3% said remote options were a top priority. A majority of developers, 63.9%, reported working remotely at least one day a month, and 11.1% say they’re full-time remote or almost all the time.

A majority of developers said they were underpaid. Developers who work in government and non-profits feel the most underpaid, while those who work in finance feel the most overpaid.

You can view the full survey results here.

On Loser Experience Design

by Matt LeMay

On Loser Experience Design

Shared within various product teams this week, this was a conversation starter. Matt’s discussion on “loser experience design” made us immediately think how Stack Overflow and the Stack Exchange network is potentially reinforcing negative experiences.

If you treat casual users like failed power users, they will start to feel like failures — and they will leave.

It’s easy to fall into a rut when you cater products, features, and workflows to power users for fear of losing them or because they’re your product champions (and it feels good when they’re happy). Being reminded that the casual user is our normal user, and we need to focus more on creating positive experiences for them.

Ethics can’t be a side hustle

by Mike Monteiro

Ethics can’t be a side hustle

You can’t buy ethics offsets for the terrible things you do at your day job.

A popular article this week that’s worth highlighting again. Mike’s does a great job arguing that we cannot compartmentalize our day jobs and extra-curricular activities. And this can be said throughout our lives. Whether it’s how you interact with different groups of people, environmental decisions, or health choices; everything we do in life is connected. It’s our job to understand what we’re creating, its potential ramifications, and if those ramifications align with our ethical beliefs.

Design principles: what to do when nobody is using your feature

by Brendan Fagan

Design principles: what to do when nobody is using your feature - Inside Intercom

Make sure the problem is crystal clear to all stakeholders, across teams

Brendan’s article is a great peek behind the curtain at Intercom’s process. We really enjoyed this in-depth look at their process, complete with wireframes, Google Doc screenshots, and designs.

The Boat

by Nam Le, adapted by Matt Huynh

The Boat | SBS

Matt Huynh’s online adaptation of Nam Le’s graphic novel, The Boat, is 👍. Spend a few moments today taking a look.

Meg on Twitter

Some thoughts on designing empty states..

Meg on the perils of being funny at the wrong times. Amen Meg. Amen.

Enjoy reading this? Then follow our publication, Dribbble, and Twitter.

The most interesting things the Stack Overflow Design team shared for the week of March 5th, 2017

“Writing Well”

by Julie Zhuo

Writing Well

Write for your reader. Know what you want to say and what you hope they take away. In those precious moments that they have given to you and your words, write so they might learn or feel something. Write so that it’s easy for them to remember your message in the days and weeks to come.

We’re big fans of Julie here. And again Julie provides some great, practical advice on how to develop a skill–namely, writing.

“Help! Is There a Cardiothoracic Surgeon in the Room?”

by Jared Spool

Help! Is There a Cardiothoracic Surgeon in the Room?

One of our early results is that roles don’t matter, skills do. It doesn’t matter if a team has an interaction designer or information architect. It does matter that interaction design and information architecture skills are present amongst the team.

CSS Protips

by Matt Smith

GitHub - AllThingsSmitty/css-protips: ⚡️ A collection of tips to help take your CSS skills pro 🦾

There were many facepalming moments reading through this list from Matt. A great resource!

“Linting HTML using CSS”

by Ire Aderinokun

Linting HTML using CSS

CSS-Tricks on Twitter

Repeating backgrounds can be fairly smart. Check this out. 🎓 https://t.co/IOuqJlV5y1 https://t.co/MnUzF5mTXm

Design Overflow, №5 was originally published in Stack Overflow Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

The most interesting things the Stack Overflow Design team shared for the week of February 27th, 2017

“The Hierarchy of Engagement, expanded”

by Sarah Tavel

The Hierarchy of Engagement, expanded

Growing users without growing users completing the core action is the empty calories of growth. It feels good, but it’s not good for you.

This generated a lot of discussion within not the Design team this week, but also within other product teams, which we found very beneficial. It made us pause to consider if what we’re asking people to do on are simply busy-work or reinforcing the core action.

“Against ‘shoot first, ask questions later’—my response to ‘User research is overrated.’”

by Barry Prendergast

Against “shoot first, ask questions later” — my response to “User research is overrated”

My job as a designer is not to make deliverables for my team and stakeholders per se. That’s a common output, but I exist to uncover and to share, to build common understanding. It’s about the outcomes!

This rebuttal to “User research is overrated” is spot-on and we’re thankful Barry did it so well.

“On Women and ‘Good’ Places to Work”

by Nora Jenkins

On Women and “Good” Places to Work

When reviewing a job offer, there are certain questions every person who wants to do quality work will ask themselves. Do the company’s goals align with my own? Will I be doing really great work? What long term impact can I have? It’s a major life decision; where you work is where you learn, hone your craft and spend a huge amount of your time and energy.

Hoefler&Co. on Twitter

Ahoy @mantia. Nice work so far - here are some thoughts that might be useful. (Continues...)

Twitter threads like this are what makes the internet so amazing.

Joshua Davis does amazing work.

During the run-up to Super Bowl 51 this year, Joshua Davis teamed up with Club Nomadic, Pepsi, and LIFE WTR to make some amazing visuals.

Design Overflow, №4 was originally published in Stack Overflow Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

The most interesting things the Stack Overflow Design team shared for the week of February 20th, 2017

“Design research at Dropbox”

by Cristen Torrey

Design research at Dropbox

We’ve identified three key points of leverage: connecting to the organization by embedding in product teams, collaborating closely with stakeholders through facilitation techniques, and systematically bringing researchers from different product areas together to address key strategic questions.

Image-to-Image Demo: edges2cats

The team had some fun creating some truly freaky—and hilarious—images.

“How to construct a design system”

by Colm Tuite

How to construct a design system

A design system (as it pertains to tech products) is more than a framework, UI toolkit or component library. It’s more than a style guide or set of code guidelines. It’s even more than the sum of those parts. A design system is an evolving ruleset governing the composition of a product.

“Tips for Becoming a Design Leader”

by Andrew Lucas-Walsh

Tips for Becoming a Design Leader

If you’re looking to grow as a leader, don’t wait for someone to promote you into that position.Uncover the areas where you can lead and just start doing it.

Andrew lays out seven great suggestions for how you can personally grow your career. This article especially resonated with some design team members. We’re a medium-sized design team with a flat organizational structure. We aren’t dramatically growing our team. Our challenge is helping people feel that they’re growing in their career even if they aren’t moving into more management roles.

Thanks to Andrew for sharing his thoughts!

“Why Less Choice is a Better Choice”

by Paul van Oijen

Why Less Choice is a Better Choice

Rather than informing me of all the available options and forcing me to make a decision on whether or not I’d actually like to use these services, Google made this decision for me. And the experience ended up being delightful. Less choice, or no choice in this case, ended up being the better choice.

Anticipatory design is increasingly become an area we find ourselves discussing as a team. How can we think ahead for our users? How can we help them achieve their goals faster and better? Paul shares the merits of anticipatory design and why you should be considering it more.

Enjoy reading this? Then follow our publication, Dribbble, and Twitter. Interested in joining our team? We’re hiring!

Senior Product Designer at Stack Overflow

The most interesting things the Stack Overflow Design team shared for the week of February 13th, 2017

Setting correct expectations. That was this week’s topic. Whether within our product teams, the company, or the 40+ million visitors to Stack Overflow every month; we need to remind ourselves that biggest part of our job as designers isn’t pushing pixels—it’s framing the conversation so we’re getting the right feedback at the right time.

“How Stack Overflow Redesigned the Top Navigation”

by Kurtis Beavers

How Stack Overflow Redesigned our Top Navigation

The new site navigation is the first major update to Stack Overflow in 4 years. And the internal and external reception to this update dominated our team’s discussion this week. To kick off this week’s links, Creative Director Kurtis Beavers breaks down the problems with the previous navigation, solutions we explored, and our testing and implementation details.

“Design for the Feedback You Want”

by Denise Spiessens

Design for the feedback you want

But if you’ve spent hours pushing pixels only to get feedback that the flow doesn’t make sense, not only was that time wasted, but you might be more reluctant to change your design after all of the time you invested. (Emphasis ours)

We completely agree with Denise’s article here. Sharing journey maps, creating wireframes, critiquing designs, doing code reviews—the level of feedback needed (and desired) with each step changes. You want to make sure you’re building the right thing early, and sweating the details later.

“Proper Etiquette for the Advancement of Design”

by Dan Mall, presented at SmashingConf SF 2016

There are so many great pieces of advice in Dan’s talk. Dan practically walks through not only the reasons why designer should care about “setting the table” for design, but how to do it successfully.

“The User’s Journey: Storymapping Products That People Love”

by Donna Lichaw, Rosenfield Media

The User's Journey - Rosenfeld Media

I’ve seen what happens when people feel good about what they can do with your product. They love your product. And your brand. They recommend it to others. They continue to use it over time…as long as you keep making them feel awesome. They even forgive mistakes and quirks when your product doesn’t work as expected, or your brand doesn’t behave as they’d like. People don’t care about your product or brand. They care about themselves. That’s something that you can and should embrace when you build products.

At the core of great products and brands are great stories. So argues Donna Lichaw in her book, The User’s Journey: Storymapping Products That People Love. In this short, insightful read, Donna explains why you should consider stories, how they’re structured, and the ways you can apply them to large, medium, or small ways within a product.

“Simple products for (many) users”

by Anisha Jain

Simple products for (many) users

A clear purpose enables us to create a North Star that the whole team can rally around, keep any V1 product simple, and communicate a product’s purpose through its design. It also makes it easier to say no to features that don’t matter and identify ones that do for the future.

If you’ve worked on a project long enough, you find you have seemingly competing user expectations at times. Anisha outlines a number of ways you can break down these seemingly impassable chokepoints to deliver great product experiences.

Enjoy reading this? Then follow our publication, Dribbble, and Twitter. Interested in joining our team? We’re hiring!

Senior Product Designer at Stack Overflow

Design Overflow, №2 was originally published in Stack Overflow Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

In-house, distributed, or fully remote: it doesn’t matter. No matter how your team is constructed, you share helpful, insightful, and hilarious things with each other every week. And the Stack Overflow design team is no different. Here are the five most interesting things we shared with each other.

“Change aversion: why users hate what you launched (and what to do about it)” by Aaron Sedley

Change aversion: why users hate what you launched (and what to do about it)

By sampling a small percentage of users continuously, we can see attitudinal shifts that signal how much pain users are experiencing as they adjust to the changes we’ve launched.

Posted almost 4 years ago, this article by Aaron Sedley is still insightful today. As product designers, we’re always changing things–trying to make things better. Aaron lays a number of practical ways your team can help turn a potentially painful experience for your users into a delightful one.

“Space in Design Systems” by Nathan Curtis

Space in Design Systems

Don’t give up on systematic clarity because of exceptions. Try to solve them. If you can overcome such nuances, even with a bit of CSS trickery, you can persist a simpler concept everyone can stick to.

We’re in the throes of finalizing our type and spacing systems right now for the Stack Overflow Design System. Nathan’s article was a timely one for us. Nathan not only makes strong arguments for a strong spacing system, but then breaks down the various ways to approach creating that system.

“Why don’t email clients use modern rendering engines?” by Ted Goas

Why don’t email clients use modern rendering engines?

But remember: the primary job of an email client is to render emails, not web pages. Mimicking “modern browser engines” needn’t be a requirement and should be considered more like a nice-to-have.

Full disclosure: Ted is a product designer at Stack Overflow. That said, we still felt this was a great article about why email clients and browsers render HTML differently.

“CSS Grid Layout Terminology, Explained” by Ire Aderinokun

CSS Grid Layout introduces a lot of new concepts; there are 17 new properties to learn, and many more new terms to understand. This can make getting started with CSS Grid Layout difficult, as new terms reference other terms and you can get into a spiral of confusion. So, here are the basic concepts and terminology of CSS Grid Layout, explained.

CSS Grid Layout Terminology, Explained

We’re excited about the new CSS Grid properties coming out soon. To help us understand what’s coming, Ire Aderinokun breaks down the new terminology.

World and Science on Twitter

Magnetic Putty eats Piece of Metal https://t.co/DfVTdHd6nT

Thanks for reading! Follow Stack Overflow Design to receive future articles.

Design Overflow, №1 was originally published in Stack Overflow Design on Medium, where people are continuing the conversation by highlighting and responding to this story.