A succinct way I’ve framed the split is that a front-of-the-front-end developer determines the look and feel of a button, while a back-of-the-front-end developer determines what happens when that button is clicked.
Doing it right requires a different pace of working and a much broader thought process than “ok, let’s get this thing out the door.” Which is super tough because most workplaces place a huge emphasis on getting things out the door, and fast. Little agile tickets that are expected to be completed in micro sprints to me seem to be antithetical to doing it right.
The traditional process of delivering design, vs. delivering design just in time.
Designers are often working at least one sprint ahead of engineers. While one sprint might not seem like much of a lag, a typical product team learns a lot after the design hand-off. ...Instead of working ahead, we should finish designing as close to the end of a sprint as possible: just-in-time design.
Get embedded in the team. Designers should use sprint planning, grooming, standup, and retro as opportunities to provide design to — and receive feedback from — the rest of the team. Designs can take the form of written or verbal descriptions, not just wireframes and high-fidelity mockups.
Only design what’s needed. Use constant communication between engineering and product partners to understand what your collaborators will need next. Then, plan on delivering only what is needed, and nothing more. Use the agile process — grooming, planning, and retro — to find any shortfalls or excesses.
Avoid creating a backlog of designs. Designs don’t age well. In the time between finishing design and shipping code, it’s likely that you’ll learn something new that changes your understanding. If you’re producing more design than can be implemented, focus more on the quality of each design.