Join Drew Bridewell for an in-depth discussion in this video The workflow of a product designer, part of Practical UX Weekly.
- When I first started out in design I was incredibly passionate about the process and the workflow of a designer. I loved seeing how an individual meticulously thought through their solution. I thought it was so interesting to see the sketches, stories, interviews, and critiques and versions of a design that a designer explored. Being a user experience designer at LinkedIn, we see many designers who interview and talk about their design process. In this episode I'll take you on a journey through my workflow being a user experience designer in today's fast culture.
Let's get started. Before we jump into the details it's important to know that not all design workflows are the same, nor should they be. It's all about what you know and what you don't know, how much time you have, the size of the task, and the problem your trying to solve. After you answer these questions, you can quickly prepare how you'll break up the level of effort for each part of your workflow. If you haven't seen my episode on designing a responsive web product, I'd recommend watching that before or after this one, so you can tie together the new project check list.
This can give you a jumpstart for your next project on what questions to ask. I'll discuss a similar process, but in this episode I'll go more into the details of workflow, and not so much coming up with a design solution. Now let's fast forward to getting into the workflow. I start by asking a ton of questions and trying to understand the problem we want to solve. Then the research begins and discussions start happening about what we know and what we don't know. At this point, I understand the goals, the personas, and the market.
This helps inform the product vision or direction we want to take. During this point in the process, you should be able to articulate the member problem you're trying to solve. Remember, it's a lot easier hearing the issues firsthand from actual people that use your product. You might have heard, we should design with empathy. This is when you put yourself in your users shoes so you can feel their frustrations and needs. This doesn't have to be super formal. Just talk to your users, they're just people.
Once I have a clear understanding of the pain points, I'll jump into generating multiple hypotheses that could solve the problems based on the qualitative and quantitative data I have. I then get out my sketchbook and grab my favorite felt tip marker, and start sketching and writing out my thoughts. I'll pull past solutions that worked well and sketch out new solutions that just work. Then I use the experiences and carry them into my research phase. This informs what goes into my sketchbook.
At this point, my PM and I have created the following deliverables: A company Wiki page, we use Confluence to document key metrics of success, research notes, quotes, timeline, and other details that could benefit the rest of the organization who might need to be brought up to speed. We also use an InVisionApp prototype, or board. The purpose of this is to have a home for all the process I'm generating in the discovery phase. This will consist of sketches, screenshots, wireframes, design comps, and anything else that shows my creative process.
Just because you don't go with a solution today doesn't mean it won't be a great solution tomorrow, so don't throw it away. Confluence and InvisionApp are vital because they are homes for the documentation for years to come. It doesn't add a ton of overheard if you make it a part of your process and document things along the way. My professors at Savannah College of Art and Design ingrained great habits of documenting the process. I would recommend you do the same. It has served me well in pulling up past solutions we've worked on, but timing just wasn't right for the feature.
When you know you've tried something and have it to reference, it's a great more booster for the team. And these new destinations get created, I'll add each team member to InvisionApp project and share a link to the newly created Confluence page. I'll share my sketches and ideas with the team. Share as soon as you have something so you can get a heartbeat of the team. Don't design in a bubble. Use the knowledge and experience of your team to benefit an entire project. After coming up with a few ideas, I'll then jump into high fidelity wireframes or mocks.
I'll iterate based on user tests, more research, and ongoing findings from the team. This is a fast process. It's possible to come back with a few mock ups in just a few solid working hours. I'd recommend uploading your design progress within the first day of getting some screens and sketches that your team can react to. Reactions are good. No reactions equal no iterations. Keep a continuous flow of interactions with your team, and try to build some momentum and excitement around your solution.
Depending on your access to your members, you could potentially show a customer or a fellow employee your idea and get some immediate feedback. Once the user experience starts to become more solidified, we'll move on to implementation. This could happen early in the process if you're using box studies. I talk about box studies in one of my earlier episodes on how you can plan better with your engineers in building a responsive web product. It just depends on the goals, timeline, key metrics of success, and making sure that what you're doing is solving problems and improving the user experience.
I use InVisionApp and Sketch to help increase my sharing velocity. Inside of InVisionApp they have this feature called Inspect, which is an on-demand tool that let's your developers click on any element and see the design attribute on the page. Sketch has plugins like Measure, which allow you to mark up your designs with specifications to help your engineers know exactly the right information to build out the CSS in the html. One pro tip when using Confluence is you can simply copy and paste your art boards or vectors into Confluence with ease.
What this means is you don't have to export your designs and then upload them to Confluence. You can simply copy and paste. When it comes to documenting your designs, make no assumptions. If you don't have a hover state design then it's probably not going to be implemented. After all this work has been completed it needs to be documented so others can use it or learn from it. Depending on how complex the work is, I'll provide a workflow map to the engineers so we can walk through a step by step of the desired experience.
We'll also look at how risky a project or feature might be, and if we need to go back to do internal or external user testing to validate the designs. This depends on timing and level of risk for the project. I'll then work closely with front and back end engineers to make sure all is on par with the outcome we desired. We then move to testing environments to polish and refine our work. Then onto release, where we can A/B test or throttle a certain amount of users to start using what we built.
Throughout the entire life cycle of a project, there's constant iteration and new discoveries that we'll have to adapt to. I work really hard never to let one of my designs go to production without seeing it, polishing it, testing it, and making sure it 100% meets the desired expectations of the users. New insights can pour in, so make sure you have a close relationship with your customer success team so you can see the feedback coming in. This is the process I strive to model, but it's not always this smooth.
Sometimes designers have to inherit projects from other designers, so you have a lot of knowledge transferring and rationalization on why particular decisions were made. Don't feel bad about asking these questions up front when you get assigned the project. As user experience designers, we must question the way things were done before, so we can move forward on improving our world in a new innovative way. Remember, not all solutions need to be redesigned. Timelines and compromises are typically made from all parties to help push the project forward to success.
So today we talked about asking the right questions, understanding the user problems, being transparent and proactive, using InVisionApp and Confluence, utilizing your sketchbook, using Sketch, documenting your process and connecting with your engineers. If you have questions and comments or if you'd like to share your workflow, then I'd love to hear about it on our Practical UX Weekly LinkedIn group. You can tweet at me @abridewell. Ping me on Facebook at Practical UX Weekly or message me directly at LinkedIn.
To continue the conversation started in this course, with Drew and other user experience professionals, join Drew's Practical UX: Lessons from the Trenches LinkedIn group.
Skill Level Intermediate
Q: Why can't I earn a Certificate of Completion for this course?
A: We publish a new tutorial or tutorials for this course on a regular basis. We are unable to offer a Certificate of Completion because it is an ever-evolving course that is not designed to be completed. Check back often for new movies.
Q. Where can I ask the author questions about practical UX?
A. To continue the conversation started in Practical UX Weekly with Drew and other user experience professionals, join the LinkedIn group at https://www.linkedin.com/