Welcome to the Jira for Designers series, brought to you by Design at Scale™ Academy. In a previous article, we discussed ReDefine the Relationship(↘︎Link) and how we might approach entering development environments. This article will take a more practical approach to product design delivery in complex development environments. 

Despite the basic product development routines like sprint planning(↘︎Link), stand-ups(↘︎Link), daily calls(↘︎Link), and retrospective(↘︎Link) allocation(↘︎Link) show and tell(↘︎Link) empower large organisations. Design, on the other hand, has to align with their design system teams'(↘︎Link) central function(↘︎Link), which is operation design leadership(↘︎Link) and management(↘︎Link). If we get all these routines together, we might soon end up having more meetings than actually producing any qualitative or quantitative work. Therefore, our weekly deliverables tend to combine these meetings into shorter, more productive slots.

Sprint panning 

Sprint planning is no different from development spring planning. However, we tend to differ in what we discuss in the context of existing and new components in a design system. Importantly, we often align with our colleagues in the central team to understand what each sprint delivers and when it can be integrated with other design teams across the organisation(↘︎Link). 

In order to reduce the bureaucracy over complicated Slack teams or any other forms of communication, we will establish a simple confluence repository that reflects the weak deliverables and their RAG report status(↘︎Link). 

Therefore, each week, we can evaluate what has been done according to the plan, what is in the process, and what is missing or on our critical part to deliver the release as originally planned. 

Refinement

You would not need a refinement session unless you are in a team of 40+ designers serving 600+ developers. It’s a simple alignment across the organisation as to why the dependencies on specific features and behaviours play a vital role in the success of collocated or remote teams(↘︎Link). Especially when you match your design to the hardware requirements, and performance needs to be maintained across the product. 

Another possibility where the refinement makes sense is to have regulated software development. Whether you are working in healthcare, finance or logistics, you will need a refinement session to understand the dependencies and articulate the impact of your designs according to the specific timelines.

Routines 

It’s commonly understood that well-defined routines can be a pivotal point in an organisation's success(↘︎Link). One hundred, if not thousands, managers organise the time through planning and various frameworks, yet we all still end up extremely busy and stressed about the deliveries. Without a proper plan for the task size and the appropriate delivery time, we can not understand the commitment – that is where Atlassian Jira’s(↘︎Link) helps. Sprint planning(↘︎Link), in many cases, is not just about saying what needs to be done but, more importantly, how long it will take to create, manage, integrate(↘︎Link) and redistribute (not even mention standardise), the design across the organisation(↘︎Link) – sideways and UP and DOWN the stream so that all parties contributing have their say. This reduces the refactoring and constant adjustment. It allows the team to use the defined feature/component in different scenarios rather than use a deprecated component for 12 months because the new one has not yet been delivered. 

Stand Up

Stand-ups have become an organisational acronym for time-wasting.
Why is it that so many teams use it for discussing problems and challenges instead of one-minute updates?
Does it need to be governed and protected?
Do we need the time restrictions?
Why we cannot make it happen in a given timeframe? 

Who is to blame?
No one is to blame.
We all have to be blamed. 

The stand-up in his spirit is a one-minute update of the following: 
—Yesterday, I worked on the feature act delivered why in the location so that everybody can access it.
— Today – I’ll be working on the new feature, potentially a ticket Jira DASTM–123, and I believe I have all the information in place <LINK> in order to deliver the task before the end of the day <PLACE>. 
— I do not have any “blockers”, so I can proceed without any delay.

This update is less than 30 seconds long and gives everyone a full understanding of what is happening with the design and where it goes.

The update you might hear could be the following:
– Yesterday, I updated all components in the Design System.
— Today, I’ll be updating the components of our design system.
– I don’t know why you ask me. I’m updating the components in the Design System. This standup is a waste of time.

Sadly, this update does not show any progress or specifics and has a negative impact on the team. Neither of the members understands what has been updated, where they can access it, or how they can use it later. This will be followed by where the file or piece of documentation that I can continue to work on is located. That is why, for more than 17 years, I have learned and coached other teams to introduce so-called drop-offs(↘︎Link).

Drop Off

You can call it however you would like. It is an essential end-of-the-day update from the design team reflected in Jira every day. The update from one line of text in a comment saying:
– I’ve finished
– I’ve progressed
– My dependencies are on the specific feature that I’m designing. 

– Recently, I’ve started including a Figma print screen to show what has been designed and what is missing.
– To provide a full-blown update of a finalised feature delivered, including the Figma link + link to the development link to assets and link to documentation on Confluence, mark the ticket done, and assign it to CSM or CPO for the Development. 

By introducing this simple act as one of the design routines, we have increased the satisfaction of designers by simply marking things done. More importantly, we create continuous transparency(↘︎Link) across the small, medium and large teams by broadcasting(↘︎Link) the changes on the continued development(↘︎Link); this way, anyone was related to the project understood where the feature is and when it will be delivered. This has increased the capabilities of the teams with more precision on planning and resourcing while equally contributing to the overall satisfaction of the design team within the large organisations to thrive for the transparency(↘︎Link) across the design team that can reuse work and contribute to one single design system(↘︎Link).

End of Sprint 

The end of the sprint is often marked as a delivery gate where the feature is built, tested and deployed, and in some cases even integrated. In terms of the “design delivery”(↘︎Link) and “design sprint”(↘︎Link), it means that the feature or the artefact is fully designed according to the high requirement, fulfilling the acceptance criteria and reflecting on the functional and functional requirements. This way, the feature can be added to the development backlog(↘︎Link) and further proceed with the product delivery(↘︎Link). 

If, however, your feature is designed in Figma without an appropriate description or link to documentation having no acceptance criteria, let alone not being based on the high-level requirements nor fulfilling a specific uses story, it’s quite impossible to make any sense in development to make it work.
Our Engineers are very good at coding and systematic thinking. They are not a magician and or wizard of product owner’s thoughts. This leads to 40 to 60% of code refactoring down the line without the ability to be influenced otherwise.

Token of trust

Therefore, we have created so-called tokens of trust. These little artefacts are part of our Figma space that signposts the co-existence between user research, user experience, user interface and the knowledgebase. The interlinks allow designers to reflect on the TASK = Jira Ticket(↘︎Link) HLR = existing documentation in Confluence(↘︎Link) without making any assumptions about the behaviour, mental or navigational models. We, therefore, design our project on HLRs(↘︎Link), KPIs(↘︎Link) and ROIs(↘︎Link) instead of assumptions and wizard magic.

One more thing.

You might say that all the above sounds harmonious, but the reality of the product development teams and the agencies is completely different. I agree, to some extent. It is only different because the designers didn’t take ownership of the end-to-end experience.
We are often tasked to deliver a solution with 100+ pages without templates and content strategy, where some kind of UI Kit has to save £50+ million in business by reflecting on assumptions and simple colouring of the wireframes. Forgetting one of the most important factors, which is a well-defined user experience, means you do not pay the UX team to wireframe; you pay them to define and document. 

For the last 20 years, I have supported the hindered transition of Design Leaders stepping into the role of Design Directors who drove the company out of darkness by transforming the design function through design automation and product integration. Having this ambition requires ownership. A well-structured plan and a knowledge base that can be easily shared across the organisation. If we have nothing to share, there is no knowledge, and no one will ever follow. This means there is no ownership, and our ambitions will never shape to their potential. 

For more information, please visit the Design at Scale™(↘︎Link) or reach out to our DaS™ – Community(↘︎Link).  

Happy scaling through design!

Hey, I’m Jiri Mocicka.
London-based Design Director, Trusted Advisor and Author of Design at Scale™. The method that empowers individuals to shape the future organisation through design.
If you have a question, join our Community and reach out to like-minded individuals who scale design propositions. An online Academy can help you to find your feed in teams of 01, 10, and 100, supported by Grid Magazine and Supply section, where we weekly bring more insights on how to become a design leader in your organisation.