Stop Wasting Your Designers Time

Product design is the combination of the user experience (UX) and user interface (UI) empowered by product vision, marketing strategy, and customer behavioral analysis. Sometimes a product designer’s position is misapprehended, and the required skill set for the position is not always fully understood. First of all, product designers are engineers who need to analyze user problems, find the areas where critical issues exist, and create solutions that fit the users’ needs and meet the business’s goals. A good designer needs to know the best practices in design, understand the development process, and its technical aspects. The process of product design engineering is fascinating to say the least.

Professional product designers can create anything from physical goods to the design process. An effective design department is a requirement at Dashdevs. More than a year ago, however, troublesome situations within this department hit us right in the heart. In defense of the product designers, I should say that the rhythm of our company can be challenging; we work fast, make swift decisions, and judiciously analyze results.

At the beginning of the improvement

All companies have issues during the scaling process. At the beginning of 2018, Dashdevs had 8 UI/UX designers who were regularly working on different projects. The basic overview: we had a process of the design cross-review, file management system on the hard drive, and a maximum of two designers on the same product. Everything was running the way it should, right up to the moment when Dozens application entered our world.

Dozens is a financial institution that became a real challenge for the team. On one hand, creating a product from scratch was a dream opportunity for our designers. On the other hand, everything needed to be done fast and robust. While working with Dozens we came to the understanding that we needed to make critical changes to some of the processes within our company.

The design development process started with only one full-time dedicated designer. However, during the course of the first month, the size of the team was increased to four dedicated designers, requiring strong collaboration among the team.

The design creation process consisted of wireframing, style creation, prototyping, and design finalization. The application has seven significant components, each of which can be separate apps. At the beginning of the design development, the designers were communicating directly with the client, but this process became ineffective with four designers. The product team was growing, so we had to add a product owner and a business analyst on the Dashdevs side. There wasn’t so much time left before we needed to start mobile and web app development, so needless to say, the timeline was incredibly tight.

Troubles concerning the scale

Although it may sound easy, especially now that I am writing it, the process of design creation was not so bright and sunny. We had extremely long meetings every day. The client was always changing the scope, features, and style. This combined with the Clients’ high expectations and natural perfectionism for the design lead to our product team becoming extremely exhausted and worn out. We were trapped in the process, and the fact that it was destroying the results went unrecognized. After two months of the design development, we had a long retrospective meeting that was dedicated to pinpointing and resolving the hindering issues, and moving forward with the improvements. We needed such a meeting. Looking back, I can say it was a necessary as the air we breathe. It was almost three hours long, but nevertheless, advantageous. The team created a list of the most significant time-consumers:

1. The merging of the team results: As I mentioned previously, we stored the design file on the hard drive. We used Sketch as the primary tool for design development. Every designer needed to download the source file at the beginning of the day. After each working day, one designer would merge the results of all the team in one file. After a while, this process became an absolute hell for the team. The file grew extremely large - more than 400 screens that needed to be updated. We would even sometimes loose some updates. It was frustrating and disheartening. After the first month of the design development, two new designers from the client-side joined the process. Accordingly, it was six designers on one product working from different locations and time zones. The merge process was a disaster. Basically, one person spent more than 4 hours per day assembling all the various parts of the work.
2. Style updates: If you work with Sketch for design development, you know that libraries and styles help you keep your style guide up to date. However, during the merge processes, some styles were updated incorrectly. This can cause issues with the original file. Sometimes we had to rework some screens a few times in order to fix the issue after it had been incorrectly updated in the library.
3. Prototyping process: Our client was using prototypes for the idea testing process. The mobile application design had more than 700 screens that were updated every day. As you may know, there are a few ways to create a prototype: manually add and link the artboards or integrate it via plugins (such as Craft plugin). All the merge problems blocked the usage of the plugins because they broke the prototyping links. By the way, we used the tool inVision at the beginning of the design development. Each prototype update took us something like one day.

Engineering of the design process

The understanding and acceptance of these problems was a significant step forward for us. When we took a look from a bird’s eye view and realized that the same problems were met all across the company. They didn’t catch our attention because of the scale of the projects. One person was losing a few hours, and consequently, a team of five designers was losing up to 30 hours per week. It was a critical issue for us and for the company. We started engineering the process of design development by dividing it into the following stages:

1. The first stage — define the issue. We needed to describe all the issues and start the evaluation process. This helped establish a severity and priority scale regarding the outlined issues.
2. The second stage — research. We needed to find solutions and tools that could help us solve the issues mentioned above. The decisions that were made were based on the criteria of each type of tool. We, as a company, were looking for solutions that were scalable, secure, and easy to implement as the best practices.
3. The third stage — choose and try. We chose the tools for design versioning and prototyping. We had several calls with the representatives of different design versioning and prototyping tools. We had the internal trial period for them that allowed us to evaluate their effectiveness. As a test project, we selected three different products for web and mobile development. It was particularly important to have different design teams for these products.
4. The fourth stage — analyze the results. We had a list of metrics to evaluate the results of the experiment. We were using Atlassian Jira for task and time management, so we had a clear picture of the time loses. We liked the combination of the tools we had.
5. The fifth stage — spread the chosen solution across the company. All of the members of the product design team were excited to try the tools, and the process energized them.

A toolset for an effective designer

After a month of internally testing the new solutions of our design process, we came to the conclusion that it completely suits our business needs. This toolset became the best practice for Dashdev’s designers.

Abstract for design versioning - The merging process is the most crucial issue that consumed our time. We were choosing from different apps such as Plant, Kactus, Github, but they didn’t meet our requirements. The Abstract tool’s friendly interface won our hearts and minds. In addition, it uses GIT flow for file versioning. The issues that we solved were as follows:

• One place for all files. Abstract is a cloud-based solution, so we had authorized access to the repository from any place we needed. We always had all the previous versions of the design file and could easily roll back to the old file.
• Responsibility for changes was spread across the team. We could track changelogs and see who broke the file.
• The merge time was reduced by more than 10 times. The application was tracking all the changes and highlighting them.
• Sharing the design with the development team became easier. Abstract has two main roles - Guest and Contributor. The admin role is sidelined, and all the designers are Contributors who can create, delete, and update design files. We can invite developers to the Abstract tool as guests. The process of the design handover boiled down to linking the design commit. As far as it goes with Abstract using Git-flow, the devs understood it clearly.
• The cross-review process was simplified. The design branch was assigned to the reviewer. All the modifications were highlighted, and the reviewers were able to comment on some screens and approve/decline the branch.
• The library management tool was already implemented in the Abstract. The most brilliant thing is that if anyone updated the library file, everybody would receive a notification about it. The process of updating the library was made in one-click for all the users.
• Abstract helped us increase the speed of Sketch’s performance. The file had many elements, and previously with an incorrect merge, the performance would suffer.
• Tracking the team’s results became simpler. We knew when a branch was created, and the changes were submitted to the repository.

Marvel tool for prototyping. We changed the tools set for prototyping too. We found out that Sketch could be easily integrated with Marvel. The links between the artboards and hotspots were made in Sketch. When all the screens were visible, it was easy to link them. We saved about 75 percent of our time on prototyping. The prototype update was done in a few clicks.

In addition to the tools, we created a policy that described the processes we wanted to have and the results we wanted to achieve. Now the usage of the Sketch, Abstract, and Marvel are essential for our company. However, the best is yet to come. We are reviewing the process every six months and are always looking for ways to improve it.