As a lead UX motion designer, I think a lot about process and pipeline with our multi-disciplinary teams. Whether or not we are as streamlined as we can be, is a question that should and does come up often. It's always a good idea to take an audit, compare, contrast and adjust accordingly to adapt to the changes in production. Outside of obsessing over our customers and making sure we are designing intentionally, there is a need for streamlining and integrating motion into the process. The most important thing I've learned however, is If designers and developers work together on features from start to finish, there is less work and rework during the collaborative process, resulting in a project that can be completed in less time. But how can this be achieved? Let's take a look an an ideal pipeline,. and identify some key moments of collaboration in each step.
Starting with the basic design pipeline, we can integrate a motion workflow into each step. Framing, Researching, Designing, Reviewing, and implementing.
Framing is the most important step to get everyone on board with the task at hand. Being open with scoping about what you think a feature might entail will help engineering surface any foreseeable roadblocks to development. Defining clear goals, and most importantly actually addressing the UX problem at hand will allow the tasks to remain grounded and on track during the process. Finally, making sure all leadership team members sign off on direction, enures that everyone is on board and all aspects have been communicated out.
Reasearching is my favorite stage by far. Starting out with motion brainstorms, I like to include as many disciplines as possible to get a wide breadth of ideas. Everyone interacts with motion on the daily in our tech submerged world. Ensuring people out of our motion bubble give insight is imperative to a more well rounded vision. Next, exploring examples out in the wild, and story boarding or collecting those to share ideas and gather feedback from the team. Moving next into prototyping, which usually requires more time than we are ever given. This is really the stage where I like to pair with my favorite engineer and brainstorm different ways of implementation and roughly prototype them out in code. Or if without an engineer, roughly prototyping in any tool handy. I've in a pinch even used PowerPoint, and set up fake click points that trigger animations. There really is a way to prototype with the simplest of tools, it's just getting your idea out in any way possible. Where there's a will, there's a way! Finally, reviewing once again with entire team, and making sure everyone is on the same page going forward.
And coming to our favorite stage of all, design, or in our case, animate! Generally, I'll be at this stage at the same time the UI designers are roughing out design concepts. So in turn, this sometimes will force me to just start animating ideas using grey boxes. Anything that can roughly get the framework down that the team has talked about, and showing initial interactions. Next, narrowing down those ideas with the creative team, and Seinfeld or sharing those ideas around with people outside of our team, maybe using clickable prototypes. User testing if available, or dark deploying to a subset of users. Ironing out final motion tests, and then of course getting the creative leadership team to sign off on the final renders.
Coming in to our last stage, we have implementation. I always start this off by handing over my motion redlines to engineering in tandem with the creative team's UI and UX specs, in order to hand everything over using a "silver platter" approach. Where I currently work we have internal interactive motion redlining tools at hand, but in the past using expressions, have rigged a redlining tool for rendering out specs, and I've even gone to such lengths in a pinch as to writing them out long hand (ugh), I've also used Inspector Spacetime for certain projects. It's really just a means of finding something that gets the information across. Then, after engineering has had time to get things in the build, I love to pair with the engineer responsible for the features I worked on, and review it in the build together. Sometimes, even when incorporated to spec, things can seem a bit off, and really this time is for polishing out any little nuances you may see. Reviewing performance with them comes next, and addressing any bug that comes out of that before they become a larger issue. Finally, reviewing the build with all newly implemented features with LT and all key stakeholders.
It seems perhaps the underlying theme here is over communicating with your team members, and stepping out of your comfort zone to make sure that everyone is on the same page, without making any assumptions. Keeping track of all motion features, correlating them to engineering tasks in your tracking system and prioritizing will keep the engine chugging along smoothly without any huge bumps throwing everyone off.