I talk about a lot of subjects… user experience, game development, coding… But this is a different kind of talk, one that is just as important as a traditional design talk. It’s more about processes and time management.
A presentation at Pixel Up! in March 2019 in Cape Town, South Africa by Catt Small
I talk about a lot of subjects… user experience, game development, coding… But this is a different kind of talk, one that is just as important as a traditional design talk. It’s more about processes and time management.
I’m so excited to talk about this because I’m a time management nerd. Like Marie Kondo, I love tidying messes. Finding ways to improve my use of tools like Google Calendar gives me joy.
I try to be efficient and improve at my work each time I focus on a new project. I don’t always succeed at improving, but I learn along the way. I’d like to share things I’ve learned today.
The goal of today’s talk is to help you worry less about the how (processes and tools) and more about the who, what, when, where, and why (the purpose of your project).
We’ll do this by discussing the following topics: why & when process can be helpful, why process can be unhelpful, and ways to focus less on process. Overall, this will help you focus on getting more done rather than getting caught up in the process.
BUT FIRST, I want to start with the positives! Processes and tools CAN be helpful.
They help us properly center our energy into something that “works”. Sometimes people are unsure about a good way to do things, and process can help people pull in the right stakeholders to help get things done. For example…
When I was a newer designer, I’d read a book called the UX team of one. It helped me figure out what to do next when I was stuck because the book included a range of approaches one can take during the various stages of the design process.
When effective, pre-existing processes and tools help us get things done quicker. Overall, the agile methodology (or movement) has great ideas! Pair programming helps share knowledge across teams; early and continuous delivery makes sure products are tested in the real world so people don’t launch duds. Sketch helps me design much quicker than before thanks to exporting tools, and it’s made for digital devices. Most design teams I’ve worked with switched to Sketch after realizing how much faster it was.
Existing stuff also just works! It prevents us from re-inventing the wheel (frameworks).
Processes and tools also help us improve at our craft. Learning from others’ successes and failures is great! The creators of the things we use today experimented and found what worked for them. Now we can avoid making some of their same mistakes.
The following are some use cases when thinking about processes and tools can be useful.
Case 1 is if you are lacking clarity
Confused about who should be doing what? Roles are unclear? Process time.
For example, I have had situations where I wasn’t sure exactly what we were building. I worked on a game for several years but we kept changing things. In the end, it never got built. Probably could’ve used some agile thinking then.
Case 2: Feeling frustrated.
If you aren’t sure why something feels wrong, process can give you a framework to identify what’s not working. It can also help you figure out ways to resolve those issues.
For example, I was working on a project and felt frustrated. I sat down and realized it was because I needed more structure. In response, I asked to include more team retrospectives, create more concrete timelines, and be involved in standups.
The third case is when you feel like you are being kept out of the loop.
If you don’t know what others are working on or if someone doesn’t know why they’re implementing a feature, process can really help!
These cases are voids that need to be filled by structure. Structure can be great in moderation.
Ok, now that we’ve outlined the positives, let’s get sad.
We’re going to go back in time a bit for this story. I want to talk about a time when I failed spectacularly because of my mild obsession with process.
A year after graduating from college, I worked my way into a Product Design job. I was still quite junior - for example, I didn’t know much about user research! As training, my boss sent me to conferences, bought me books, and shared articles with me. I was learning what was “good” and what was “bad”.
The company I worked at employed a waterfall process, meaning people with different roles didn’t communicate much. Here’s an example of how projects went at this job.
First, the PM was given a set of requests from upper management. The decision maybe doesn’t make sense. But it’s their paycheck so they move forward anyway and turn the requests into formal design requirements.
Then it moves to design. The designer works based on the requirements and tests the design when it’s close to done. Maybe users say the solution isn’t ideal for their needs, but because the solution was defined without getting the right people involved. But it’s too late to give feedback, so they move forward anyway — they can’t push back or they might lose their job.
Engineers look at the design and it makes no sense. It designed by someone who has no idea about the technical limitations. It’s way out of scope for what’s possible in the given time limit, and it’s missing a lot of details like error and empty states.
At this point, no one is happy, but you all keep going because you’re too far in.
And of course, as a result, the final product looks totally different from the original agreed-upon design. The designer is like, WTF?! It me.
In the end, you launch a project no one wants and everyone is sad. I’m sorry if this has ever been your situation because this process is a massive waste of energy.
And it’s what piqued my interest – what is a better way of working?
The dev team at my job was learning about the Agile product development process. The Agile movement is an alternative to traditional project management. It focuses on quick iteration and feedback.
The team implemented standups, scrums, sprint plannings, retrospectives, and sprint reviews. Yay, more meetings!
So I also did research I read about new methodologies like Lean UX, a collaboration focused process. The goal of the Lean UX process is to obtain enough user feedback in order to make quick decisions. It involves lots of co-creation with fun sticky notes!
I tried to implement lean UX processes at this company.
These methodologies didn’t fit well within the company, which had larger architectural issues. It was a decades-old company with a lot of baggage.
Our teams were also siloed; we were located in different states, talked over the phone without video, and had different working hours. It was tough to communicate, which is harms the chance of new processes sticking. Eventually an “us vs them” attitude formed.
I should’ve known this would be a recipe for disaster, but it taught me that you couldn’t just use a process and expect it to work all the time.
I thought these methodologies were a one-size-fits-all package that could be applied to any company, no matter the scale or team setup.
I’m an adaptive person!
The process I currently use at Etsy is inspired by methodologies like Lean UX, but it’s not set in stone. We change this process, and we continue to use what sticks because it works for us.
Now I get to do user research early and often. We ask them questions, and their answers (plus lots of other research!) help us to define our hypothetical, initial requirements.
Then we get to work, and everyone is involved throughout the process. We continuously check-in with engineers about the technical feasibility of ideas, invite them to usability testing, and have them involved in product conversations. By the end, my designs don’t get mangled!
This process was created specifically for the intricate ways Etsy works. As with any process, there are occasional frustrations. BUT the change has been highly beneficial! And it only works because we’re not focusing on rules but rather context.
Thinking about the HOW completely distracted me as a junior designer. My work suffered for it. I’m going to dissect this a bit.
Firstly, I got caught up in the idea of right versus wrong.
An example of this might be Sketch vs. Photoshop.
Or, as it was for me, Agile vs. Waterfall.
Everyone has an opinion. Opinions create barriers to making decisions. They abstract the problem by making it about the validity of our thoughts rather than the facts: our contexts. They destroy nuance and prevent us from being able to properly evaluate problems.
Next, there’s the hierarchy! It’s a constant competition.
Like now there’s Figma and that’s the new hotness to use over Sketch and Photoshop????
This is more pronounced within code. Lots of engineers have a programming language preference. Some of them express that opinion and it is completely distracting from the point.
Because within the hierarchy, there’s even more hierarchy. Picking a framework to use can be a harder conversation than defining the scope of your project.
Expecting a process to work out of the box is like asking to be disappointed. Practicing processes by the books means you can’t be flexible, and that can cause unnecessary frustration.
“Following the rules” doesn’t allow for variables that come with things like pre-existing team structure and teammates’ preferred style of working.
Running things in a scripted way can also be incredibly challenging for people.
This all boils down to a sense of perfectionism.
Defined, perfectionism is the refusal to accept anything except perfection. Everything must be the best at all possible times.
Meredith Arthur wrote about perfectionism in tech. You can find these words in a blog post on Medium. Even though perfection is not sustainable and failure is natural, our brains ignore that fact and pressure us to deliver upon impossible expectations.
Perfectionism is pervasive in our industry.
Perfectionism causes a sense of anxiety. Fear that we won’t be perfect because we can’t be perfect! Fear that people will find out we’re not magical unicorns after all.
You might know that last fear as impostor syndrome.
Impostor syndrome grows from an endless cycle of perfectionism, failure, and anxiety. Perfection isn’t possible, but you have to be the best. This pressure looms over many of us in the industry.
Here’s what all of this leads to — and why we need to change course when it comes to the way we think about our work.
When one person pushes their professional agenda onto the rest of the team, it can create power structures and vacuums.
Here’s one example. A former coworker spearheaded the use of a new programming framework, but didn’t teach anyone else why or how to use it. The coworker didn’t want to even pair program.
The person then left after the project launched, which meant no one could maintain it. We spent months reverse-engineering the work that was done. It was a colossal waste of time.
Lastly, a focus on constantly abiding by a perfect process can contribute to burnout.
Burnout is physical or mental collapse caused by overwork or stress. Perfectionism is quite stressful and leads to overwork because we keep trying to compensate for our imperfections.
If you don’t follow process perfectly, if you don’t use the best tools, you think about what you should’ve done differently. It removes the opportunity to celebrate!
This self-deprecating process has been studied and written about. Stressing about perfection fuels burnout. It’s good to be introspective, but it’s also important to celebrate accomplishments.
Now that you’ve heard ~~both sides~~, I want to discuss ways to take your mind off of being perfect!
Step back and realize what it’s all about: making things.
The whole point of everything we do is to create stuff and put it into the world. You’re working toward that every day, and you’re learning along every step of the way! So BREATHE and let go of the stress about perfection whenever you can.
Take a moment to do this right now with some focused breathing. Slowly inhale and make your stomach expand with air. While you inhale, notice the source of your breath. Then exhale slowly and keep focusing on your breathing. Repeat until you feel nice.
Air is great.
Next, create objectives. Who is this for, and why? Identify the goal of your project.
Change the conversation. If you’re starting a new project, make sure you clearly define what you’re making and why. This will help ensure that you don’t get involved in unnecessary discussions too soon.
If you’re already midway in a project but feel the need to step back, zoom out by defining objectives. Reaffirm your commitments to your goal if you already had one. This will help clarify the conversation and hopefully create a sense of direction for the team.
If you couldn’t tell where this was going, well, here we are. You will have to define your own process.
I’ve found it useful to try a test run without getting too process heavy. If that doesn’t work, experiment with methodologies and tools.
Making your own process can be challenging. Look at what works for teams and companies similar to yours, then take the parts of the process that sound helpful and throw out the rest.
Remember not to think of sticking to this process as a hard requirement!
Company size, team composition… All of these things affect a process.
Want more variables? Here are some. What’s the scale of your project? How do the people on your team work best? Is there a hard deadline? What are the project goals? Are there hard requirements set by an outside force?
So many variables.
If you don’t have an outside deadline being imposed, sometimes a goal deadline — a time when you would like to complete a first iteration of the project — can help. Even if you don’t stick to it, this will help you determine milestones and manage your time better. You can even create calendar events for milestones and move them as needed. Make sure to define a single source of truth with all documentation, otherwise people may get confused by a proliferation of sources where information is stored.
By defining the W’s, the how will come naturally.
The following are some things to remember when you’re thinking about the how. When creating your own process.
Encourage communication early and often
Ask people how they like to work. The more experienced you get, the more you understand what you like and dislike, so always ask others if they have preferences from their previous experiences.
Don’t try something trendy because you hear it’s good. Please.
Lots of people jumped onto Angular because it was the new thing to use ○ We used it on a project at a company I worked with because the tech lead wanted to ○ Every time a new version was released, everything broke
The tools you choose should be the best solution for what you need to do. There will always be something new out there! Just use what works for you.
If you decide to make a project using a new tool, share your knowledge with the team. If you’re working on a on a new project in general, share your learnings.
If you’re an engineer, work with other engineers. You never know when staffing changes will occur or if someone will be on vacation. It’s also just great to make sure everyone is aligned!
If you’re a designer include people in the design process so they feel involved. They can contribute to design decisions earlier.
Accept that there is no perfect process that works every time. There is no right or wrong way to do something, only a way to do something.
One time I was on a project with a group and we launched a small design change without user testing. A coworker got angry with the team because we didn’t test it first. But the context was important: this wasn’t a HUGE design change, and we iterated multiple times post-launch.
If something isn’t agile, that’s okay. If you’re not using the newest, hottest tool or framework, that’s okay. As long as what you’re using works well.
None of us are perfect. It’s not possible to be perfect. You can strive to be awesome without beating yourself up.
Speaking of not beating yourself up… Pat yourself on the back sometimes!
Find satisfaction in what you create. You’re making cool things. You deserve to celebrate every now and then!
Even if something didn’t work out, try to remember positive aspects in addition to what could’ve been done better. What did you learn? What did you do well? These are all good things to think about!
To wrap up…
Process can be useful but also detrimental. Context matters most – what might be right for you may not be right for some.
Finally, power shifts and vacuums can happen when one person advocates for a new process or tool. What if they leave? Has knowledge been shared appropriately?
Some advice…
Consider your context. The scale of your team, size of the project, and timeline. These all affect the outcome.
Define objectives upfront. This will help you figure out what is necessary to accomplish your goal.
Nothing will ever be perfect, so ACCEPT IT!
There will always be something new out there. Don’t jump on it unless it helps you achieve your goal.
And finally, always share what you learn. Maybe you’ll be on stage one day sharing with me!
Always be celebrating! You have unique skills! You’re making cool things! Never forget that you are a magical human being.
Some resources!
Books…
Therapy and meditation are also great.
Thank you. Questions? Tweet @cattsmall.
Come to our gaming event July: gdocexpo.com!
