Design is not just about visualization

May Nguyên Huỳnh
5 min readJan 28, 2022

You might think that our daily scope of work only starts when the task is received and will end when it is delivered or released to the production environment, that’s it. But no, the work around it, how we organize, operate and store files is equally important. Believe me, if we have a clear and smooth operating system, it will save us hours and hours of rummaging around and looking for a certain file that we designed long long time ago.

Why does our data need to be organized certainly and when should we do it?

Let's talk a bit about our situation at that time, we had several designers and each was responsible for a different domain, also our company had several products on different platforms as well. Then each platform we had 1 design file used to contain all works and ongoing projects belonging to that platform. There were multiple layers for the master files of the platform, 1 layer of handoff designs contained all ready-to-delivery projects, and the remaining layers are ongoing projects of each designer, in which we named ourselves along with the project name to distinguish them. At first, this way of working seemed convenient because all data was centralized in one place and did not require us to spend time searching for related files. But obviously, this approach was showing more and more weaknesses when we have more people working on 1 platform at the same time. Since the designer was limited in the amount of working layer, it led to the confusion the PM took place whenever reviewing the design by mistaking the draft and the final versions. While the developers kept complaining about the correct place to view the design among other works, even though we had repeatedly reminded them. The most important problem was that we couldn’t save the previous design files if we kept working with this approach.

The old way of organizing working files caused us many problems

Obviously, we need a more efficient working way, both for us and for the stakeholders involved in our work.

So, where do we start?

Every solution needs to be approached by its problem first, so we started by listing the difficulties we were facing at each stage, the actor involved in, their problems and needs.

Startedby collecting feedback, then we organized and came up with a user journey that looked like this

The arrangement and systematization of information provided us with a better overview of the needs and weaknesses that needed to be addressed. Then here came our favorite part, brainstorming solutions, at this stage each person in the team would have various personal views, so we gave each other time to research and made an appointment for another day, in which we exchanged our solutions with each other.

Our brainstorming session

Communication is the key, that’s true, always!

It was a very interesting discussion, where each person came up with the best idea and hypothesis they could think of. Then we all agreed that we needed a system where each project would be personalized for 1 person, 1 purpose and 1 team in charge of it. In addition, the master files for each platform must be separated for specialized purposes.

A system where each project is a separate part

This approach was based on the sprint technique of tech companies, where each sprint the whole team would sit down and list down the tasks the team needs to complete in an amount of time. Obviously, each task could be a separate project, and the involved people needed to care about the problems in that project only.

So it would be better if each project was an individual, which helps to focus on the problem more effectively by eliminating other extraneous elements.

A project was named by the platform (for easy searching) and the project name. We also tried to utilize the thumbnail image by attaching it with the team name, the ticket ID, the project name, the platform logo and the in-charge designer of the project.

A project's thumbnail

Each project would be stored by the project’s stages, this is how they were divided and named the stages, based on the steps required in our journey.

How design files were stored in Figma

There were details and attached documents included in a project, this might take a little time to set up at the beginning, but most importantly, it helped us store information related to the project in the most specific way. Additionally, from now on, the design link attached in the Jira ticket wouldn’t be affected or disappeared over time.

How we organized a project information

A project file could help store old versions of a project while creating new layers for the new version.

How we stored previous version of the project

Besides, the storage of master files also became neater and clearer when no longer involved with ongoing files.

Master files were separated

As a result, if we can optimize the workflow better, it will greatly reduce the errands or potential risks in the future. The less time spent on non-design tasks, the more time used on meaningful things.

The realization and desire to solve the daily problems make us realize that design shouldn’t be confined to the scope of work, it’s the ideology, the way we perceive and be aware of everything happening around us.

Thanks to my dear teammates Phamdotuanh, Nikiprojek, Thai Lam, Cheol Jun Lim, Amy Nguyen, Phuong Han and more, working with you guys is a fun experience, sometimes we might disagree with each other, but at the end of the day, I was glad cause we have grown and learned a lot from each other.

--

--