Demystifying and integrating design within a non-design organization
What is this post about?
In my career, I have spent a lot of time working with people who are not design oriented. If you’re not a designer, chances are, it all looks like magic. In goes some thoughts and out comes a design. I personally am of the position that all design must have a logical and defendable explanation behind it or it’s not design, it’s art.
Over the past couple of years, I worked under extreme deadlines and ever changing conditions. I found myself asking “how do I, as a designer, really fit into an environment that produces a real and operational product?” Through many rounds of revisions, I came up with a process that really integrates Design into the real world, and I want to share it with you.
Before I get started, I just want to lay some of the ground rules to this post.
Who am I?
My name is Mohsin Amjed, and I am a full-stack/unicorn/generalist designer. I should also mention that I am self-taught but mentored by some really amazing people along the way.
What does that mean?
Basically, I scope like a project manager, think like a UX Designer, design like a visual designer, animate like an interaction designer, and code HTML & CSS like a web developer. I do this all in my own way. It may sound ridiculous but it’s true.
Why is this important?
This diverse background helped me craft a process that works not just for me and my design team, but for my greater multi-disciplinary organization.
I joined Samsung almost two years ago, in a brand new startup like team, working on a stealth project within the Visual Display Division of the company. I was the sole designer for a year, outnumbered by engineers. Within a year, we built a product at breakneck speeds, and I helped take an idea from the conceptual stage, and turn it into a real product.
Another thing you need to know is that my boss was a perfectionist, and fancied himself as a designer.
What does this mean?
I can’t tell you the specifics of how this process evolved, or what I built, due to confidentiality issues.
Why is this important?
We had very little time to go through the stages of team development (Forming, Storming, Norming, and Performing). I had to trim down my process, compromise on steps, but keep the quality bar high. Most importantly, I had no one around me who understood a thing about Design, it’s principles and practices. Despite all this, I was expected to fill in the gaps and educate people to get the job done.
I am sure you have seen dozens of diagrams and infographics depicting the cycle of a design process. They all have the same basic parts, but none of them really explain how they relate to or integrate with an engineering or a product development organization. Starting on a brand new team with no likeminded people; I ended up spending my energy on consensus building most of the time. I was forced to take a step back and look at the situation not as the designer or even the employee, but as a co-founder to this startup like team.
When I arrived at Samsung and walked through the door, I met my boss, the product manager, and the engineering generalist*1. We had nothing but a crazy idea. A month and a half later, we had a preliminary proof of concept, and pitched it to upper management for survival.
This process doesn’t have to be a hard fast rule, but it should act as a checklist to make sure you did your job properly. As a designer, the onus is on you to show why the final product is the best option.
Roles & Responsibilities (R&R)
In order to speak about a process, I have to define the roles and responsibilities. It took us a few tries to get this right, but without it, nothing works. These roles are highly simplified and might be a bit controversial.
Product Manager (PM)
The person in-charge of keeping everyone on track, but most importantly, getting everyone what they need to do their respective jobs. This person scopes out the product and gives it meaning.
Engineer – Generalist
The person who codes, and brings everything to life. Without this person, you might as well be unemployed.
Designer – User Experience
The problem solver. The person who takes the requirements and designs a solution for it, and makes the solution beautiful.
White Boarding (Optional)
This falls more on the PM side of things, but is equally an important part of the design process. Before the PM puts together the Product Requirements Document (PRD), the designer and PM should get together and white board the scope of project. Both individuals may view this differently, and ultimately will ask different questions. The goal is to get the PM what he/she needs to write the PRD.
Product Requirements Document (PRD)
The design process starts here. The PRD serves as your True North. The journey might take you to a different destination, but having a solid base will make sure that all disciplines move together and go through the same thought process. I look at this as one’s perspective alignment. If I am standing on the 5th floor – on the left side of a building, and my PM is standing on the ground floor – at the right side, we might be looking at the same thing but will have two very different perspectives. We both might be right but agreeing on what we see might be a challenge. The PRD ensures that everyone is starting on the same page.
This should look familiar. Any good design process starts with some form of research. Research should include anything and everything that is relevant to the product defined in the PRD, including the PRD its self. Look at existing work samples, similar features in adjacent industries, competitors, and the industry in general. You need to really understand what problem you are really trying to solve, why it exists, and how others have attempted to solve similar problems.
This step should, in most cases, result in a mood board of some form.
It might not seem like a step, but this is an important part of the overall process. Present your findings to your entire design team. As one unit, you should look for any unknowns and try to answer them. This meeting should reveal what additional research is needed, or if you are ready to move on to the next step. If you did everything right, you should have a good sense of what the UX flow might be.
I like to say we wireframe for three things. The PRD, Engineering scaffolding, and the UX flow. What does that mean? Going back to our Roles & Responsibilities you want to make sure that you check off all requirements in the PRD. You also want to make sure that you unblock engineering to start architecting the front end. This provides you with a whole lot of time to do your due diligence as a designer. Sync up with the feature team regularly to make sure you don’t go too far down the rabbit hole; sync ups are a hard requirement for everyone.
It is worth notifying the engineering team that the wireframes are for flow and that items may get moved around.
Again, this is step might seem meaningless but it is for accountability. The entire feature team should already be on the same page, so this review is for the entire extended team. Invite all team members interested in joining this review. Vet the flow as a team, and let everyone poke holes. Wireframes are the base of your design and the product; make sure they are strong ones.
Since you already unblocked engineering, you should have plenty of time to do some visual explorations. You should keep the feature team in the loop, but share ideas as the solidify. It is important to have your design time flush out ideas and not contaminate or bias people with bad ones. However, you shouldn’t disappear for a month and comeback with something new. This step should yield at least two explorations to review.
Once you have enough visual explorations and you feel comfortable, set up a design review with just the design team. This needs to be a safe environment, so avoid having other disciplines in the room. As a design team, go through the designs and poke holes where ever you find vulnerabilities. Remember, design should always have a logical explanation. As a team, come up with a direction and flush it out and start planning your design review.
This is where you show your amazing design to the whole team. It is also the place where you have to prove your design to the team. Always structure this review as a presentation. Present the base research, the wireframe, the design recommendation, and make sure you put some explorations in an appendix. Ask the team for their comments, and do a last round of examination. You want to make sure that you have buy-in from the entire team. Take notes and embrace constructive criticism.
Use the notes from the design review, and use them as your preflight checklist. Patch any remaining holes and limit your improvements to a day. Get the design ready for lockdown.
Setting the expectation and criterium to a “design lock” is paramount. Use the R&R as your saving grace. The only subjective feedback that matters at this point is from the design team. You have kept the feature team in the loop throughout the entire project, and incorporated their feedback. Now is not the time to use them for that purpose.
Lock the design with your design team, then move on to the feature team. The PM should agree that this design solves the problems it needed to, and the engineer should agree that the design is within reasons. If these conditions are met, call the design locked.
Publish the design document to the team as the locked design. This is your PRD, this is your code review. Make sure this document is pixel perfect and an accurate representation of your skill set.
Never redline before a design lock. It only adds to the chaos. Redlines are your official deliverables as a designer. It is what you use to hold engineering accountable, so make sure it is detailed and comprehensive. Go the extra mile and make this document as engineering friendly as possible. It might be a pain, but it ensures that your design gets implemented and most importantly, the users get the experience they deserve.
I set this step as an optional one, because not every project needs extra interaction design time. You should always be thinking about the Ix, and it should be apparent in all of the previous steps. That being said, sometimes the project is more complex and it warrants significant time for prototype development. Prototypes come in many different shapes and forms, use what is right for the project.
Fit & Finish
This is one of the most crucial steps. Set the understanding with engineering that they will be held accountable for implementation. You should spend a good amount of time working with engineering to fit & finish both major and minor design and UX bugs. This is where you sign off on the product as the Design stakeholder.
This process may not be a perfect fit for you and your requirements might be a bit different. However, you should be flexible enough to mold this process into not just what you need but to what each project may need. Each person brings something different to the table, but the key to success is to show respect and work with everyone. I may have been lucky to work with an extremely seasoned and mature PM and a incredibly talented engineer, but at the end of the day, design is not an island; you must learn how to work with non-designers; educate and integrate them into your process.
Let me know if you have any thoughts.
- there were two other individuals who I’m leaving out