Reminds me of a little feature I like in Notion where if you type dash-arrow (like ->) it turns into → — but intelligently — like it doesn’t do that with inline code or a code block.
On one side, an army of developers whose interests, responsibilities, and skill sets are heavily revolved around JavaScript.
On the other, an army of developers whose interests, responsibilities, and skill sets are focused on other areas of the front end, like HTML, CSS, design, interaction, patterns, accessibility, etc.
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.