Process optimisation

Before I joined the company, even the marketing designer used to spend a hour every morning listening to reports from the developers and testers. The product designer had an art background but wasn’t very tech-savvy, so taking part in joint conference calls with the developers didn’t really help her much.

I changed this practice by setting up a separate morning call for designers, where we discussed progress on current tasks and helped each other find the best solutions. Drawing on my own experience as a developer, I was able to answer most of the questions. So there was no longer any need to attend the developers’ morning scrum call. Instead, the designers established a more personal connection with the specific developer they were working with on a particular task. As a result, the new process significantly improved decision-making speed and design quality.

I soon noticed that people tend to lose focus towards the end of meetings. So I proposed a new rule, which was adopted company-wide: meetings should last no longer than 45 minutes (except in very special cases, such as quarterly presentations).

I allocated 4 days for the designers to work on the tasks, and set aside Friday for brainstormings, sprint planning, design presentation, and retro. As a result, we were able to complete more story points and tackle complex tasks more quickly.

I introduced the practice of breaking tasks down into subtasks so that several designers could work on a single task. Each was assigned the part they were best at. This collaborative approach also meant that one designer could cover for another whilst they were on holiday or sick leave.

I also started adding holidays and sick leaves to the shared timeline – this has made it easier to plan work. We have started grouping urgent unexpected tasks under the heading ‘Design duty’ and taking the time spent on them into account when forecasting the workload for future sprints.

It is better to set KPIs that measure the quality of the outcome rather than the quantity of work. However, tracking time can also be useful in some cases. As InvestEngine did not have a dedicated tool for this, I began tracking how many story points each designer spent per week. By discussing workload during retros at the end of sprints, I was able to determine the optimal number of story points and how they should be allocated across different types of tasks. This helped us spread the workload evenly, avoiding both downtime and burning out. In this way, I achieved predictable delivery, which had a positive impact on planning across the whole company. I then gradually optimised the workflow and increased the number of story points a designer could complete without compromising on quality.

Time-to-market, as a KPI, was rolled out across all departments of the company. Design speed was never a bottleneck – I hired professionals who get the job done quickly, especially following the process optimisations I’ve carried out within the department. The problem lay in a shortage of product owners and a reluctance to hire business analysts. Each designer was expected to take on all these roles themselves. Broadening their skill set and increasing their autonomy is beneficial for designers’ development, but for the fast-growing company it meant a blurring of responsibilities and a lack of consistency in decision-making.

I therefore took on the role of business analyst, clarifying the requirements for tasks – most of which arrived in the design department without description. Consequently, the percentage of tasks received by the designer without a description has become a KPI that measures our contribution to time-to-market.

Every month, during 1:1 calls with each designer, I discussed which skills needed improving and what had been achieved over the past month. I helped cover the cost of training courses and introduced a practice of one learning day a month, completely free from the daily routine.

Monitoring is not an end in itself, but a means to an end. When I noticed that the designer’s productivity had dropped, I gathered statistics on his auto-saves in Figma and compared them with my own. It turned out that I had spent more time finishing the designer’s task than he had spent on it himself. With these statistics in hand, I explained to the employee that his productivity was lower than that of the rest of the team. I suggested that this was due to his move to Asia and persuaded him to return to Europe. He returned to Europe very soon afterwards, and his productivity returned to normal.

I’ve set up Asana to collect information about the design tasks for the current sprint from all other teams boards, so that we can see the designers’ workload in one place.

On the Asana board, I’ve set up the stages ‘design review’ and ‘waiting for the owner’s feedback’. When a designer moves a task, tags are automatically applied and messages appear in the Slack channels. The information appears only in the relevant channels and only the relevant people are mentioned.