I want to start by sharing that I was inspired by the infographic below from InVision to write this. This may appear at first to be a silly and hunky-dory post about family-like co-worker relationships in the office. While I agree I am writing with this sentiment, I want to show how enriching and successful this way of working together is for everyone—and it lasts. I’ll use the following categories (like the infographic) and talk about some experiences and examples: We’re in This Together, User Focus, Early Involvement, Systems and Processes,* The Pre Hand-Off*, Frequent Check-Ins, and Pragmatic Communication.
We’re In This Together
I need developers. I don’t only need them to build what I plan, design, and fashion but also with making decisions throughout the cycle—the ever-changing, living, and breathing software lifecycle. There is so much to learn as a designer when new technologies and capabilities in programming emerge. Even if I don’t know the code semantics or how to write the languages, I need to constantly learn the new possibilities code can lend design. Likewise, developers can be looking for how new UI and interaction design can inform their code choices and structures. Why not? This makes sense. Well, when both parties don’t see it this way, it doesn’t work well. Stronger communication, in this regard, means taking constructive criticism back-and-forth for us all to better our end users along the way. I can not be afraid to challenge development when I know the result isn’t what the design showcases after we all agree to it. When development already has the same goals and agrees with the direction we design, we can sync easily. I have recently joined a team that started off the bat by asking how they could help in my design process when I first started to learn about what we were building. That was an incredible way to start because I felt respected as a design-team-of-one to six front-end developers. Oh what joy! “Yes! Let’s make together and be considerate of each other the whole way starting today,” I thought. When my design choices were challenged, I really was tested to reciprocate the way I would want them to take my challenge. I don’t own the design; it’s not my child. So, I appreciate that these bright technical minds were always helping my work get better with greater solutions. Collaborate. Collaborate. Collaborate. It’s satisfying.
User Focus + Early Involvement
I could talk about this section in an entire blog post of its own. But I want to relate it to working with some developers here. Why is it so important that we build for our users’ needs? That probably seems like the obvious “Because they are the ones using it,” but I challenge that another huge reason everyone (business, development, and design) should be user-first-focused is because we can all make decisions together about how to best solve the needs and push the result to be better than expected. Getting everyone in the room to huddle around all ideas—good or bad—creates more possibilities and diversity in approach and workflow. Early development and design involvement leads to less self-fulfillment because gathering together lets us sync and get our priorities straight. Then, when the business can prepare to support, when developers can build robust and secure systems, and when designers can give users back time from their tasks that took far less time all to meet the same goal, everyone is better. In one of my projects when we did this and did not skip corners, we were more trustworthy. That’s success.
Systems & Processes
This category gets into the detail and fine-tuning aspect of collaboration. Sometimes, I feel like when my notes to developers are to increase margin pixels or graphic icon sizes or change text in page directions, they would be thinking “I don’t think that will matter, this way works fine.” But I am wrong. In a recent project, I was often asked to look at the fine details to ensure parity from my design. Now that I feel relieved and even confident to give these notes, there is a much greater indication here: mutual respect. When there is trust and reliance across teams, these small changes happen fewer times because the design is not just the designer’s, it’s the team’s. Clarity, brevity, and consistency are values across the whole team. We expect that ourselves as consumers. We can produce work faster with beneficial recent tools like InVision Inspect or Zeplin. Our systems and processes should show we care.
The Pre Hand-Off + Frequent Check-Ins
Now this step in the InVision infographic is actually not what we do. I don’t “hand-off” from my desk to the developers and have to make sure everything is perfect and exactly what I want. Nope. They already have seen my ideas and variations through iterating together along the way. They have seen my hand drawings and whiteboard sketches by this point, so I don’t have to have a ceremonious handoff to development. We may turn drawings to mid-fidelity in Balsamiq or Sketch and development receives that mixed with some hi-fidelity Sketch screens, but we generally keep this step more fluid and put layers of UI down before having the final screens to “hand-off”. However, we will want many eyes and/or user tests, big or small, along the way to validate the workflow and interaction design decisions, like the infographic suggests. The whole team owns this validation. Everyone helps and learns together by the testing so empathy and better problem-solving can be considered. The frequent check-ins is an important measurement of project success. Here is where the excitement turns real and the stakes are higher. It is important not to get too attached to everything being perfectly executed and implemented at once. Software is living and breathing. It is never really done. Here is where the team involvement is put to the test and the development goals will really show and shine. This should not be left to them with all of the pressure to perform. Everyone goes along the building process together, checking in often and making changes where needed.
Pragmatic Communication
We want to do a great job and produce a rewarding piece of work with crafted experiences. But the way to communicate when someone values a direction and someone else another is shared understanding of potential, risks, and reality. We have to talk about these issues and not hide them. They will surface. I have experienced some valued enhancements get swept under the rug, also known asUX debt, in a project due to lacking pragmatism with all who were involved. When relationships are straining, the product—therefore, the users—can suffer. I am a person to prioritize feelings in my decision-making, but I am learning that rationale and logical approaches are the way to release tension. There are mutual benefits when we problem-solve together based on facts and findings. Opinions fall short in this regard. Let’s be meaningful and intentional, even when it’s hard.
That’s my Kasun Point for today. Thanks for reading!
Chelsie
