JIRA for designers — Managing design delivery
Managing design delivery in large organisations was always a risky thing and therefore a task that’s traditionally been siloed.
Big corporations like to create departments and use its authority and autonomy in their own territory — to protect the combined knowledge in a specific area.
Welcome back, and thanks for following up on our previous article.
Now we’ve reached the point where we understand the basics and have unearthed what the product world expects from Agile-Based Design Delivery. This article will focus on design-specific disciplines integrated with peripheral or centralised Agile teams using the different methods or techniques.
Design Research
Let’s start with Design Research.
Research and insight teams are critical departments in any company. They were historically designed to understand the outside market and communicate to the broader internal group what’s happening in the competitive landscape.
Now more than ever, these departments are shaping the very existence of the centralised design functions in many organisations by collecting insights about their customers. And sees them collaborate closely with Product Design Development (PDD in shot) teams while integrating their knowledge within Sprints or specific Releases.
“Our researcher and her well-communicated findings saved us 15% of the development of time refactoring, by validating small prototypes with our customers” — CPO, Sydney.
When the researcher is integrated within the scrum team, they can immediately communicate and apply the findings from testing back to the sprint. This relationship directly increases learning and impacts the overall team performance, especially if the researcher is entirely (at least 70–80% allocation) integrated with the team instead of being assigned as a supporting function (10–20% allocation), something that always causes a problem.
The combination of Research, Copy, UX and UI has been proven to save teams 15% of the time spent on code refactoring thanks to a combined effort and a well-orchestrated iterative testing process.
Our researchers were trained to take advantage of Confluence and represent their findings through the snippets and links shared in relevant JIRA tickets. This inevitably increased knowledge across the engineering team. Essentially, the findings explained why specific changes are happening and the impact of their fantastic work.
Design Questions:
- Can we have a researcher?
(trivial question for some, but sometimes you might get one if you just ask nicely) - How can we closely collaborate with research or at least the QA team?
(it’s valuable for designers to learn from smart QA and research colleagues; we might not be as good as they are, but we can most certainly make their work much more efficient). - Where do we store our findings, and how best do we make sense of it to present back to the team and influence the build?
(collecting valuable feedback and seeing its impact is really valuable. This helps researchers to build a research hub)
Wordswomens’ and Wordsmans'
It goes without saying that people who are good with words are the most underrated professionals operating in the product world, yet they have such a massive impact on the quality of the product.
“Managing copy delivery has been historically supported by MS Word documents being passed from one person to another via Email.”
One might make changes in one document without the intention of feedback from a customer or a focus group. Then there’s the review process from stakeholders and, more importantly, a review from a risk, legal and regulatory requirements perspective.
“Nowadays, the copy is fully embedded in our design and development tools.”
Recently I ran a survey on LinkedIn and Twitter where the majority of the copywriters answered that their work is done primarily in code (which is fantastic) and in design software. More apps than ever are connected to JIRA and are able to track the changes automatically.
Design Questions:
- Who is responsible for the copy of your project?
(if you are fortunate enough to have a dedicated copywriter, then you’re in luck). - Where can I find the latest copy, and how do I manage any changes? (Once you and your buddy have agreed on how to deliver messages in the designs)
- Where and how does sign-off happen?
(to prevent changes within changes, make sure you understand the approval and sign-off process)
Design Thinking
Often big teams try to manage design thinking with scrums or another form of increment tracking.
Although difficult, it’s not impossible to track the empirical research and assumptions, so long as there is a clear objective of what the design thinking exercise needs to uncover.
The scholarly paper “An Integrated Framework for Design Thinking and Agile Method for Digital Transformation” shows how to integrate these two methods. Yet no practical and detailed description of how it’s actually done in practice.
While running a Design Thinking phase of a project with Design at Scale called “Proposition Shaping” (in the figure above), we tend to employ simple Kanban to track our outputs. This allows us to progress faster to identify the more valuable outcomes to the following stage of the proposition.
In other words, using Kanban allows us to see what needs to be done (so-called delivered), and at the end of the week, we as a team decide what we have learned and what will be part of our further ”Design Shaping” (in the figure above).
Design Questions:
- Does the business understand the difference between outputs and outcomes?
(Some corporations are still operating like we were living in the 18th Century production line — that’s why they deliver a set of outputs instead of outcomes. Make sure your company understands the difference.) - Are outcomes being validated and prioritised going forward?
(Once we unearth the challenge is time to validate the impact /detriment and understand how do we prioritise its implementation.) - Outside of CPO, who else needs to review it or sign off?
(It’s easy to get a sign-off from one CPO. If you have multiple stakeholders, please make an extra effort to communicate effectively and as often as possible — the HBR guide to managing up and across will be a great help on your journey.) - How do I, as a designer, smooth the process?
(You have to have one… and you have to constantly evolve it. Don’t copy processes from someone else, either.)
Design Sprint
This brings us to the following stage, which is Design Sprint. Design Sprints are very popular, yet very few teams understand how to take learning to the next level.
Recently working with one of the major UK Retail Banks, designers often said, “We’re making a design sprint”, yet were unable to answer a simple question:
“What’s the impact of these sprints on the team, business or our customers?” — Experience Design Director, Greenwich
If the Design Sprint is integrated within the company ethos and operations, it could bring the most expected competitive advantages.
Equally, when the design department understands the shared value proposition with development, they test their hypotheses speeding up the understanding phase. Design Sprint can also be integrated into a Dual-Track Agile as an evaluation method that feeds every week’s delivery track. In that case, the production line still operates in two-week cycles yet delivers higher value.
Design Questions:
- How does the Design Sprint fit into the entire E2E proposition?
(In other words, how do we know that we’re testing what matters within the E2E delivery cycle.) - How do we integrate the learning into the product/service/feature?
(We have just made the Design Sprint — what’s next?) - How do we integrate the learnings into our design system or other design guidelines?
(We’ve just finished the design sprint — how do we integrate our learnings into design guidelines?) - Who owns the outcomes of the design sprint?
(We validate that the users like to click on BTN — A and not BTN — B, what goes to the next design sprint?) - How do we keep track of all our changes and learnings?
(Miro, Mural, PPTX, XLS, Word, PDF, Axure, Sketch … maybe a combination of Confluence and JIRA? What’s your call?)
Service Design
Service Design under Agile carries several success stories.
No wonder Service Design (SD in short) is on the edge of its popularity. Reflecting on the recent research, I haven’t found an example of how the SD team or SD professionals track and measure the impact of the SD exercise and how it was successfully translated to a delivery.
“That said, from the thousands of post-it notes, hypotheses, assumptions, and extensive large experience maps, business blueprints, and PowerPoint presentations, no actual PM, CPO, or CSM have spoken about how to successfully track and impact of service design delivery.”
I recently had an experience with an FX service for a retail bank in the UK. JIRA was set up as Kanban — simple todo > in progress > done. Not including blocker, dependencies or integration.
Some of the tickets remained on the board for 2–5 weeks due to dependencies that were raised through different sectors. The Service Design Lead drove Mural and PPTX as the presentations ensuring the right outputs with less important outcomes. The mixture of different SD sources suggests different outputs. Luckily, the team was enriched by the professor from the design management institute who coached the team out of the struggles and delivered the expected outcomes.
Design Questions:
- Make sure your team understands what the difference is between Research and Service Design?
(And does the business understand that, especially Design mid-management level. You would save the business and your department significant troubles and faux-pas in front of senior leadership.) - What methods are we using to unearth the truth, and why?
(Knowing the method, you can predict the outcomes and therefore control what to present — that’s not necessarily Customer-Centric it’s more business-controlled.) - Where and how do we report our findings?
(Some of these incredible findings are buried in PPTX presentations. Make sure you peasant an Experience Map that has the ability to zoom in and out between big picture and detailed facts.) - How do we communicate our findings to senior leadership?
(XLS and PPTX might be required, yet make sure that your leadership also understands that you have done X–testing and learning in a customer-led environment). - How do we integrate our findings with actual product development?
(Make sure your findings are well-documented and represented in development circles. Choose the method appropriate to your discovery and feasibility to be constantly updated — We choose Confluence.)
Design System
Challenges around the design systems are ever-rising as many teams struggle to keep up with the demand and constant updates. I can not speak for tracking the elements in Axure, Sketch + Abstract or Adobe XD, but the outcome is simply remarkable when it comes to constant updates of the Design System between Figma + Jira.
In the last year, I have managed four Design Systems with an overall 3.000 elements between combo Jira + Confluence + Figma linked together. The team has had a daily summary of new components built over the following day, so in the next 24 hours, we have replaced the mock-ups with the actual interactive components.
“The JIRA tickets were updated frequently so that all developers know that components are active and can start building — simple yet very effective.” — Experience Design Director, Greenwich.
As you can see (in Figure 5.0) “DS — Component” ticket has three parts. First, the name of the ticket is clearly distinguished from the other features and User Stories and Tasks.
The label is set out to “Design System — DS” so that all tickets can be tracked separately. The last thing is internal Figma updates shays with one ticket to reduce the updates to a minimum.
Design Questions:
- Is the Design System a file or a team?
(If it’s a file, it’s your responsibility to maintain it. If it’s a team, you have to communicate what you’ll be using and how do you contribute to the base) - Who maintains it, and how much time in the project is dedicated to it?
(To maintain the Design System, it’s essential and yet time-consuming work, especially if one system serves different purposes.) - Who signed off the final component and all variants?
(This is not so much about the look and feels, but about the logic and mental model of how the data and document are structured).
Stay tuned; thanks for reading!
Thanks to all contributors, especially Matt Press, for their insight and comments shaping this very article.
Jiri Mocicka is a London-based designer, writer, and coach passionate about Design at Scale — an integrated proposition for design professionals in small, medium and large organisations bringing value to the same businesses through transparent and well-integrated product design development.
