A Modern Design Process
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 go some vague thoughts and ideas and out comes a design. I believe that all design must have a logical and defendable explanation behind it; otherwise it’s not design, it’s art.
Over the past couple of years, I have worked under extreme deadlines and ever-changing conditions. I found myself asking, “How do I, as a designer, fit into an environment that produces a real and operational product?” After many rounds of revisions, I came up with a process that truly integrates design into the real world, and I want to share it with you.
Before I get started, it will be helpful for you to know a little about me.
Who am I?
My name is Mohsin Amjed and I am a full-stack designer. I should mention that I am self-taught but have been mentored by some amazing people along the way.
Why is this important?
Full-stack means that 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
It is this diverse background that has helped me to craft a process that works, not just for me and my design team, but for my whole organization.
Background
I joined Samsung in 2014 as part of a brand new, startup-style team, working on a stealth project within the Visual Display division of the company. I was the sole designer and was outnumbered by engineers, but within a year we built a product at breakneck speed while growing our team. 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 was very design inclined.
Why is this important?
We had very little time to progress through the normal stages of team development (forming, storming, norming and performing). I had to trim down my process, compromise on certain steps, but keep the quality bar high. Most importantly, I had no one around me who understood design, its principles and its practices. Despite all this, I was expected to fill in the gaps and educate people as necessary, 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 include the same basic elements but none of them really explain how they relate to or integrate with an engineering or product development organization. Starting with a new team, with no like-minded people, I found myself spending my time and energy on consensus building. 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 of the team.
The process outlined below doesn’t have to be a hard and fast rule, but it could act as a checklist to make sure that you are doing 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)
To describe the process properly I must first define roles and responsibilities. It took us a few attempts to get this right but without it, nothing works. These roles have been simplified for ease of use.
Product Manager (PM)
The person in charge of keeping everyone on track and, most importantly, making sure that everyone has 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. This person is ultimately responsible for what users get.
Designer — User Experience
The problem solver. The person who takes the requirements, designs a solution, and makes this solution elegant.
The Process
White Boarding (Optional)
This falls more on the PM side of things but is also 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 the project. Each may have a different perspective on this and will ultimately ask different questions. The goal is to get the PM what he/she needs in order to write the PRD.
Product Requirements Document (PRD)
The design process starts here, with the PRD serving as your true north. The journey might take you to a different destination, but having a solid anchor will ensure that all disciplines move together and pass through a similar 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, on the right side, we might be looking at the same thing but will have two very different perspectives. We might both be right, but agreeing on what we see might be a challenge. The PRD ensures that everyone is starting on the same page.
Research
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 as defined in the PRD, including the PRD itself. Look at existing work samples, similar features in adjacent industries, competitors, and the industry in general. You need to really understand the problem that you are trying to solve, why it exists, and how others have attempted to solve similar problems.
This step should, in most cases, result in some form of mood board.
Research Presentation
It might not seem like an independent step but it is an important part of the overall process to 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 have done everything right, you should have a good sense of what the UX flow might be.
Wireframes
I like to say that we wireframe for three things: the PRD, engineering scaffolding and the UX flow. What does that mean? Going back to our roles and responsibilities, you want to make sure that you check off all requirements in the PRD. You also want to unblock engineering to start architecting the system. This provides you with plenty of time to do your due diligence as a designer. Sync up with the feature team regularly, to avoid going too far down the wrong 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 during the design process.
Wireframe Review
Again, this step might seem unnecessary, but it is important for accountability. The 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 basis of your design and the end product; make sure they are strong.
Visual Explorations
Since you have already unblocked engineering you should have plenty of time to do some visual explorations. You should keep the feature team in the loop and share ideas as they solidify. It is important to take your design time to flush out ideas so that you don’t contaminate or bias others with bad ones. However, you shouldn’t disappear for a month and come back with something new. This step should yield at least two options to review as a team.
Design Direction
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 wherever you find vulnerabilities. Remember, design should always have a logical explanation. As a team, come up with a direction and start planning your design review.
Design Review
This is where you show and justify your amazing design to the whole team. Always structure this review as a presentation. Present the base research, the wireframe, the design recommendation, and make sure you include 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 at this point. Take notes and embrace constructive criticism.
Improvements
Use the notes from the design review as your pre-flight checklist. Patch up any remaining holes and limit your improvements to a day. Get the design ready for lockdown.
Design Lock
Setting the expectation and criteria 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 additional feedback.
Lock the design with your design team, then move on to the feature team. The PM should sign off that he/she is satisfied that this design solves the problems it set out to solve, and the engineer should agree that the solution is realistic. If these conditions are met, you can 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.
Redlines
Redlines are your official deliverables as a designer. This is what you use to hold engineering accountable, so make sure this document is detailed and comprehensive. Go the extra mile and make it as engineering-friendly as possible. It might be a pain, but it will ultimately ensure that your design gets implemented and, most importantly, that the users get the experience they deserve. Never redline before a design lock; it only adds to the chaos.
Motion/Interaction Design (Optional)
This step is optional as not every project will require extra interaction design time. Some projects are more complex than others and warrant significant time for prototype development. Prototypes come in many different shapes and forms; use whatever is appropriate for the project. This step doesn’t mean that interaction design should be neglected until the end, think holistically and reserve time as needed.
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 and finish both major and minor design and UX bugs. This is where you sign off on the product as the design stakeholder.
Final Thoughts
This process may not be a perfect fit for you, and your requirements may differ. However, you should be flexible enough to mold this process in terms of what you need, and what the project demands. Every contributor brings something different to the table and 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 an incredibly talented engineer but at the end of the day, design is not an island. You must learn how to work with non-designers and be able to educate and integrate them into your process.
