I spent part of 2017 working on a self-service online platform in which media is segmented and annotated through a series of discrete tasks assigned to remote workers. Due to NDA I am not able to share insights around the design work. On the other hand I will share some insights on design process that will motivate everyone to improve and keep on working on big complex data projects.
UX Design UI Design Documentation Design process
One of the most challenging parts of the product was how to incorporate a design process in an already developed platform that is shipping features every week or two. As designers we tend to orchestrate the development of products. We often fell into the loop between business, technology, user and visuals. Everyone knows that working on big international projects with teams from different time-zones and cultural background is challenging. Complex data projects tend to isolate design from the development process, but there is a way to keep the motivation flowing, be productive and helpful to your team by integrating a correct design process as instrument for development in the product's future.
1. Design is just another tool for communication.
The process is all that matters at the end, not your designs. Layouts are going down the drain at the end of the sprint, the icon set is not in a living repository so you leave the set behind once too much work occurs, the color consistency gets disrupted once you start using the color picker more and more just because it is more convenient and faster, many of the design files are sent through email, slack or just showing it to your team-mate sitting right next to you, you screen-share if you need to show something and explain it. Keeping up to date is hard, but if the team is aware of the process and the end goal, then there is no problem.
Yes sure, visual deliverables are the easiest way to approve a change or new feature but this does not mean that the implementation will be similar to the perfect pixel design which was not communicated before presented to the decision makers. Selfishly I started thinking more and more how to keep the motivation going while my designs were getting rejected sometimes completely, sometimes partially.
I found out that I should love the process, the communication supporting my decision, the questioning of other team members decisions, the team members questioning my decisions.. Not the actual layouts and visual deliverables. This is super important if you want to be part of a team on a bigger scale not a startup company with few people working as many positions as they can.
(Don't get me wrong working in a startup is great, you can check the Tripscout case study to see how the design work can be appreciated and make an impact for the future development of an application.).
2. Get to know your team-mates
Accept that your team-mates are your friends. Would you take it personal if a friend tells you the truth? What about a team-mate saying those designs that you spend like 7 hours twisting and doing the perfect-pixel layout are not worth the work.
"We can use a component already developed and introduce the change in the application and be done with it."
Yes, it is not serving the perfect design purpose and maybe it is not communicating clearly the end goal but it surely says we got the job done and you can get yours too. With time we will update and improve it. Is the dev team now the design team, are the project managers the product owners and business evangelists now, are they the decision makes now. Who is the decision maker? Why are you spending time working, thinking, talking with everybody involved in the product and at the end, your idea gets shut down? Working on big international software solutions is hard because you hardly see your ideas coming to life. Maybe you can squeeze some motivation and ownership because that primary button change was your idea and now every primary button in the application is blue and it is focusing on the main task of the section or page and it is corresponding to the brand guidelines coming from the marketing team. In a way everybody is happy and you are trying to be happy with them, owning something.
Your friends will never think of something that will make you feel bad, if they do they are not your friends. This can be assumed in terms of product teams as well. There is no alpha person in a product, except the product itself. Sure the owners/ directors/ stakeholders or whoever is at the top of the product chain is the so-called boss. But your team, they are there to get the job done, so the product can keep on living and improving and providing a service, so people can use it and get their job done. So you see, it is a cycle, it is a process with which you have to devote yourself as not the creative power innovator who is the creator of this abstract, super high-tech and complex system. You are just part of a team pushing the product for a better tomorrow. By getting to know your team-mates, what they do, how they do it, how they do their research, what tools do they use, do they keep a documentation, what framework do they use.
Having the repo with the icons used in the application, so the front-end team can call them and render them. You as a designer can easily jump in GitHub and start adding the icons there. Once you handle your designs you can talk it out, which icon is used, where and why, so the dev team can call them straight from the repo and be done with it. Caring about easing out the process of the next person on the chain is crucial for growing up in the communication between the participants and the improvement of the product, it is not about the features only. Same as your friends, you would help a friend in need so he can jump on his feet and start doing what he wants to do.
3. Systematic approach is innovation
While entering a team of developers, business analysts, architects and project managers your role is to mediate across all those people and their own understanding of the product, while having the user need in mind. Sometimes this means stress, argumentations, questioning your decisions, questioning other people decisions, tight deadlines, not enough information, requests for calls, chaos. But at the end you are not innovating or creating something that has not been done before, you are just trying to figure out what is the best approach for the case that we are trying to solve. Get out of the zone that layouts are needed,design system is needed (just because the internet says so). Learn your frameworks, understand how to build components, understand the back-end logic of the application, have the business side of things, sometimes pretty does not mean money. Try to provide the best possible solution either if it means just a paper pen design which is ugly or a simple flow-map showing the logic behind every action. Just have your process in your mind and try to explain it to your team-mates.
We are working on products on multiple-level of involvement, product people, creative people, development teams, business people but we have on thing uniting us, the product itself. There is a common thing between us, we are working in a technical discipline. People involved in software development should have technical understanding of things. Sure not a straight up developer, but have the technical understanding of how tools are build and what do they do. Being the only designer in a software solution is a heavy burden, but at the same time it is the challenge that pushes you for a deeper understanding of the discipline. Approaching the design decisions the same way as being constrained by a framework during a front-end implementation is the perfect way for embracing your full creative power. The best way to communicate designs is to have a common language, a system, a design language. This systematic approach to problems is a challenging task but once you identify how to communicate them you can jump straight up to designing in the browser or just providing some simple documents to serve the logic behind, no need of pushing yet another layout, just to make the job.
We had three defined roles in the application which were related. So once a change in one of the roles was made this immediately interfered with the other two roles. At the same time because of constrains, the application used similar classification of components across the system. If a design change need was identified in one of the roles this was quickly changing the view of the other two roles. Solving such complex problems is hard, but by making a total design review of the application and entering through different roles is the knowledge base with combination of the framework restraints that allowed us to push for the best solutions. Constantly communicating between everyone in team, we did not separate the design work from the development process, we unified them so there was no need to wait for final design approval. We simply scaled the whole process by connecting visual layout and development together to provide better and faster solution which was reviewed and tested. We were able to create a common language between the design and development. That way we had more time to spend on back-end logic not on actual layouts and front-end magic.
I've spent more than a week isolated from my team-mates in order to layout the logic behind every role and the connectivity between them.
All those parts of the whole picture are the things that matter, at the end the most important goal is the product. By accepting other people opinions and knowledge on the product, by understanding feedback coming from users, by having in mind the constrains coming from the business side you can push changes and improvements which could take long time. The almighty misconception that designers are ego-centric and narcissistic is a common thing in the internet. While working on big projects those assumptions are completely wrong and must be set aside. Design is not personal and is not suppose to be personal while working in a team. By the end of my involvement the design system methodology was accepted as a best solution in order to develop new features.