Welcome to the Jira for Designers series brought to you by Design at Scale™ – Academy. In a previous article, we discussed the Definition of Ready and how it impacts delivery within the in-house and remote teams(↘︎Link). This article will look one step further at how designers support engineers in delivering the proposition and integrating it with the outside world. Undoubtedly, from time to time, some designers have the tendency to own things when they do not need to.
Process
If you believe that the DoD – Definition of Done(↘︎Link) is written for designers, you are making a mistake. This definition is mainly for our engineering colleagues, where the design function becomes purely supportive.
In the first phase, we all co-define proposition. In the second phase, we designers co-create user acceptance criteria, functional and non-functional requirements, and other pillars of software development. This face is mainly about the contributions of designers and developers. In the third phase, the ratio of support and leadership exchange is from 80/20 to 20/80, and the leading position of design moves into the peripheral supporting function. While our engineering team delivers the code, we designers support them with additional testing(↘︎Link), assets(↘︎Link), documentation(↘︎Link) and so on. Weing them to test, retest, and observe only one say of the desired experience.
Deployed vs. Integrated
Often, we see that the design team wrongly assumes that deployed code means the “Definition of Done”. In many cases, especially in big integrations/platforms, regardless of whether the code is deployed and the pages pass all acceptance criteria, it still has to be integrated within the larger ecosystem. It could often take another life cycle(↘︎Link) before the functionality is fully out in the hands of the customer.
It is important for any designer to see how the work has been deployed and integrated and test it against the criteria, but more importantly, how it actually behaves in the hands of the customer.
Please ask your engineering team what it means in the context of your product delivery deployed and integrated. It will help you avoid some basic misconceptions, and it will allow you to communicate a better value proposition to your client.
Agency Time-Lapse.
One of the things that the design agencies usually underestimate is the time lapse between the different projects and the deployment. Often, when the feature is delivered and marked as “Done”, it doesn't mean that it is being fully developed, deployed and integrated. Often, we see when beautiful designs and great prototypes wait in the delivery pipeline for months and months before being revisited again and refactored for development prior to deployment.
One way to avoid it is to have DoR and DoD documents ready and link them to your Figma files(↘︎Link). All our boards are clearly marked with a Jira ticket that represents the delivered task while equally linking the confluence of DoR(↘︎Link) and DoD(↘︎Link) requirements.
That way, the design team did their utmost best to support the external engineering team with all definitions. If, for whatever reason, this documentation is not reflected in the development, it’s the responsibility of the CPO(↘︎Link), who is on the engineering side, and she/he takes full responsibility for delivering it or not.
Quality Control, so-called QA
Even if your agency does not deliver the code and you are the only design provider, make sure that you have your own QA – quality engineers(↘︎Link) in place. This is not to blame engineers of the opposite team but to help them resolve the upcoming challenges swiftly.
It also gives the agency extra leverage to deliver quality work that can be broadcasted and bring benefits to both integral and external integration.
Internally, leveraging better team integration and transparency helps both designers and engineers to collaborate closely and release the proposition in a shorter time, not even mention cost reduction in code refactoring. Externally, broadcasting the change helps the agency win more clients and ensures that clients have continuous support from the agency even though their work has already been finished.
Partnership
Conversely, in regards to achieving a quality design and quality code, an agency does thrive in a partnership where both parties hold each other accountable for
a/ quality of definition,
b/ quality of design and the overall experience and
c/ quality of code and speed of the deployment.
That way, you benefit from better integration with your partners but also bring your partner better quality for the delivery as a design agency. Please make sure this is a transparent relationship above anything else. This way, you prevent additional hassle and maintain both teams in the area of operational excellence where both teams benefit from the partnership.
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.
