Design Organizational Process | Lauren Medved

Design Organizational Process

Summary

  • Company: MIM Software

  • In Collaboration With: Zach James (UI/UX Designer), Divya Thomas (UI/UX Designer)

  • Tools: Figma, Figjam

  • The Problem: In 2022, the UI/UX team at MIM discovered that we did not have a well defined process for managing and organizing our design projects. This led to disorganized and inconsistent work between each project.

  • The Goal: Our goal was to improve team efficiency, stakeholder confidence, and internal utilization. We believed that a well defined process would lead to consistency amongst each designer, which would ultimately support our goal.

Highlighted Skills

Process Design

⬤

Team Collaboration

⬤

Critcal Thinking

⬤

Documentation

How We Got Started

Before this project, our design team had an organization system in place that wasn’t really used as intended. We had statuses assigned to files in order to track progress, yet a majority of our files were left in the Work in Progress status. There were unclear expectations on when to move projects to the next phase and it led to things piling up in one place. Our team lead saw that things were getting messy and suggested for us to investigate further. We agreed that there had to be a better way, so we met daily in order to find a solution. 

Before beginning our hunt for a solution, we decided to create a Figjam and lay out the facts. We investigated our current process, decided what worked, and what needed to be reconsidered. We also discussed what was important to us and decided to realign our process more closely to our goals. Senior UI/UX Designer, Zach James, helped lead our team through this process and guided us through important questions and considerations.  

The Problems

Ineffective Statuses

Early in our discussion, we discovered most of our files got stuck in WIP because the In Review status was intimidating. Our original process said that completed files would get moved here to get reviewed by another designer before being classified as Official. However, each designer specialized in their own products, which made peer review difficult and often pointless. Additionally, this process gave the original designer less responsibility to keep the file clean and hurt our communication with engineers because nothing was intentionally organized for development. The final issue with our file statuses was that Official mockups did not always reflect the live product and often files were only "Official" because our design work was complete. This lack of clarity made it difficult to start designing for existing products because we didn't know if the Official mockups reflected the actual implemented design patterns.

Unclear Communications

Files that remained stagnant for awhile often lacked information that was critical for us in understanding the project. We didn’t know who owned a project, what engineer to reach out to check on its status, if the project had even been handed off to an engineer in the first place, etc. This made it difficult to clean up our existing files as well as pick up on projects where other designers may have left off. In fact, we had one designer leave our team shortly before beginning this process. Many of his projects were in this limbo state of us not knowing what’s done, what’s next, and who to contact. And this was not a problem we wanted to encounter going forward.

What Needed Change

We agreed that we wanted to organize our files in a way that indicated the state of the project both on our end and the engineer’s end. We wanted a way to know whether or not particular mockups reflected a live version. We also wanted to find a solution to prevent build up of Work in Progress files that were stagnant due to being in development. Finally, we all agreed on wanting more documentation for each project so that it was easier to pick up a project at any moment, regardless of who started it. 

The Solution

File Status

Obviously the current process wasn’t working for us- the statuses we had were not reflecting things that were important to us. So, we adjusted the file status to reflect more detail on the state of the project. I suggested for us to replace In Review with Engineer Ready. This solved our problem of understanding whether or not design work was compelted and if a file had been handed off to engineering. We then rewrote the process for Official designs to require a product or feature to be live before marking a mockup file as Official. This way we could be confident that all our Official designs were the most accurate and relevant mockups to reference. 

Process Map

As a team we drafted a process map to figure out a process for every one of our files. After getting our draft laid out, I took a further look at filling any gaps for more complex situations. Something important to us in this process was ensuring our Official Design folders did not get cluttered. We wanted to have a single file for every product and merge all new features with these files. However, this added a layer of complexity when there was remaining material in a file that may not have been developed yet. Thinking through this process in a way that could be mapped out was challenging, but eventually I figured it out by walking through what the process would be for our current projects. I knew every file had two ultimate fates: Official Design or Archived. Making sure every path could land in one of those two statuses made it easier to determine the process in complicated scenarios. Ultimately I created a process map that could account for every situation.

File Structure

In addition to figuring out our file statuses, we also took a look at reorganizing the structure of our files themselves. We never had a standard process for this, which meant there was little consistency between our files and how we presented them. If we had to help out on a project that another designer started, it was overwhelming. This was an early frustration of mine when I started working at MIM and I began to pioneer a consistent file structure. Before we even started evaluating our process in this project, I had conversations with the team about using a similar structure. However, it was until we started analyzing our process that the rest of the team agreed on creating standard file strcutures. Eventually we landed on using file templates with these 6 pages:

  • Thumbnail
  • Overview
  • Mockup
  • Prototype
  • Sandbox
  • Local Components

To make things easiest on the team, we created blank file templates that comprised of these pages with preset information based on the project. To accompany these new file templates, I redesigned our default thumbnails to represent our new file statuses and rearranged how important details were being communicated at a glance. These thumbnails would help us quickly find a project and learn about its details without needing to fully open it.

Documentation

One of the pages in our file structure was the Overview page, which would quickly become the most important page in every file. This page held a robust overview template that gave us a space to document details regarding each project. This would make it easy to hand off files to other designers or pick up on a file that had been stagnant for awhile.

I was the primary designer who created this template and I began drafting it based on the information I wish files had when I started working at MIM. I collaborated closely with the team to determine the amount of detail that should be included for each section.

One area that I included had pleasantly surprised my team- it was a links section that could connect to other files and documents. I initially included this so that engineers could reference relevant design files easier from within another (this was a pain point during projects that comprised of multiple Figma files). However, this section quickly became the go-to spot for our team to save task links, requirement documents, and server access links for specific test servers relevant to each project.

Conclusion

All in, collaborating as a team to reorganize our files created significant benefit to our consistency and efficiency. It helped minimize the time needed to get started on a project, it removed hiccups when handing off projects, and overall it gave us more structure to how we worked. 

Want to See More?

Check Out My Design System