There’s a common problem in making digital products. Designers and developers need to work together, but sometimes they don’t fully understand each other. Now, let’s analyze how a user story (a technique used in Agile software development) can contribute here.
The challenge: designers vs developers
Typically, developers wait for designers to complete their work before starting their tasks, while designers wait for working software in order to gather valuable user feedback. This usually leads to a slow development process, mainly because designers and developers get disconnected within their own silos.
To solve this, you can have a multidisciplinary team, i.e. a team with designers and developers working together, while maintaining their individual roles. This is how many successful product development teams’ work.
Of course, alternate methods exist to organize the team’s tasks but this particular approach deserves to be explained in more detail.
A typical multidisciplinary team configuration
Here are the roles and responsibilities of what I consider a standard product team:
- Product designers: They’re responsible for the overall UX and proposing specific interaction decisions for each new story as well as the implementation of the visual design of the platform,
- backend and frontend developers: They convert those proposals into functional software,
- and a product owner (PO): The person responsible for prioritizing the stories while considering business needs, development constraints, the feedback from their community of users, and their previous design decisions.
They should have a high level of autonomy throughout the entire software development process. Of course, there are more roles involved (QA, infrastructure, etc) but in this article I’m only focusing on how designers and developers can collaborate.
The lifecycle of a user story
To explain how a product team can manage all the work involving the design and development of a new feature or user story, let’s see a typical workflow with this diagram:
The workflow follows a linear approach, inspired by my preference for the Kanban method. In your Taiga project (Settings > Attributes > Statuses), you can define the following states for a User Story:
- “New”
- “Defining”
- “Ready to develop”
- “Developing”
- “Ready for test”
- “Testing”
- “Done”
Icons marking “New”, “Ready to develop”, and “Ready for test” represent queues, meaning no one is actively working on those tasks at those moments. Conversely, the “Defining”, “Developing”, and “Testing” stages are considered as work in progress since tasks in these stages should either have someone working on them or be on hold due to specific issues. The final state is “Done”, and a story should reach this status only when the software increment is accessible to the users.
NOTE: The distinction between states representing queues and work in progress is very relevant if you want to measure your Flow Efficiency. I’ll write about this concept in a future post.
Let’s go through the detailed lifetime of a User Story that goes into the team’s backlog:
Current status: NEW
The Product Owner (PO), or someone else in the team, creates the story because it seems a good idea that deserves to be considered, so it can be prioritized in the backlog. When does the PO prioritize the backlog? It depends, but I prefer that it is part of the Refinement meetings. You can also do it at the beginning of the Sprint Planning meeting (so everyone in the team is aware of that update of priorities, can ask questions, etc), or at the end of the sprint, as part of the feedback the team receives during the Sprint Review meeting.
After the Sprint Planning meeting (if you are using Scrum) or the Replenishment meeting (if you are using Kanban), some of those ideas are moved to the state DEFINING, and Product Designers (PD) start working on them.
Current status: DEFINING
If your product is very mature, the output of all the activities done during DEFINING can be final designs (not mockups or wireframes). Otherwise, using low-fidelity artifacts to drive the discussions it’s a better practice. Those designs are discussed and adjusted with the developers in the Refinement Meetings.
NOTE: In some teams, I’ve observed that such a degree of completeness can discourage developers from challenging the designs because they may think that changes can be very expensive.
The Refinement Meeting
The diagram includes an icon named “refinement meeting” between DEFINING and READY TO DEVELOP. In this meeting, product owner, designers and developers collaborate to review and prioritize user stories. Although Scrum doesn’t specifically require these meetings (they can be more than one per sprint), many teams find them beneficial. In my experience, this is a key activity where teamwork and collaboration among all team members need to be at their strongest.
Refinement meetings help to ensure that the user stories are clear and prepared for the next sprint. You should also break down complex stories (also known as “slicing”), pinpoint dependencies, and clear up uncertainties, making sprint planning more efficient. They also help teams to anticipate and resolve challenges, leading to smoother sprints.
Current status: READY TO DEVELOP
When the definitions are accepted, the stories are moved to the status READY TO DEVELOP. It’s a good practice to review their priority because, during the definition process, you may have learned things that could change the expected value, the estimated cost, etc. You can also discard the story.
NOTE: I have not added a DISCARDED state for the sake of simplicity in the diagram, but I encourage teams to have it because then you can have a nice metric. Discarding an idea that won’t be used by our users saves us time and money.
In the next sprint, if they have the capacity, the team will work on stories that are “READY TO DEVELOP”. It’s also a good practice to break down the stories into tasks during the Sprint Planning meeting because everyone is present so it’s easier to have early feedback on the decisions you are making.
Nevertheless, each team has different approaches for this, e.g. some teams prefer to think of CRUDs (create, read, update, delete), whereas others don’t, because maybe their product is more driven by user interactions. My advice is to try slicing your features with an iterative and incremental approach and define very simple stories so your task breakdown can be a short to-do list.
Current status: DEVELOPING
Each story should be moved to DEVELOPING to signal that the team has already started to work on some of the planned tasks.
It’s very important to agree on how to manage the impediments that they will eventually find during development. Usually, it’s just a doubt about something visual or regarding the user interaction that can be solved with a short conversation on your chat, but sometimes it can be more tricky (and time-consuming). In those cases, having explicit working agreements avoids uncomfortable situations due to too many interruptions. If those interruptions are very frequent, it’s probably because your refinements are not good enough.
If your team is not autonomous, i.e. you have many dependencies during the development activities, your stories will be blocked while you are waiting for the other team to deliver so you can continue. This is something that significantly reduces your agility and it should be one of your most important priorities. In those cases, having a status BLOCKED (or BLOCKED DURING DEVELOPMENT) can be useful to have a metric that you may use to understand the impact of those blockages.
Current status: READY FOR TEST
I like to have a checklist, as part of the working agreements, to show everything that must be done before moving a Story to the state READY FOR TEST:
- Development tasks done
- Unit tests passed
- Acceptance criteria verified (at least by developers)
- Code reviews passed
- No known blockers or dependencies in progress
- Documentation updated
- Deployed in the testing environment
- Data for testing available
NOTE: The management of Pull Requests and the Continuous Integration system is crucial for the effectiveness of the team at this stage. We are looking for having a smooth workflow, so the stories are not waiting for people.
Some teams have a state to show that a story has been paused during the development because it needs more analysis. Other teams show this moving back the story to the state DEFINING. And also you can find teams having a state NEED MORE ANALYSIS (or something like that).
In my experience, none of them are a good practice because, somehow, you are not respecting the priority assigned. I’d rather see the team make an effort to eliminate whatever impediment is blocking the workflow for that particular story. Naturally, this relies on the given context.
Current status: TESTING
Testing in software development is a crucial process made to ensure software quality by identifying anomalies and ensuring the expected behavior. There are two main test execution methods:
- automated testing, which uses scripts to test software repeatedly and consistently,
- and manual testing, where humans evaluate the software’s functionality.
This article isn’t primarily about testing. However, in certain contexts, automating tests can be a great way for designers and developers to collaborate and improve the product, as it accelerates the feedback loop.
NOTE: I always encourage teams to do their own QA (quality assurance) because it gives one of the quickest and most valuable feedback. If you ask other team to test your stories, you will probably have a bottleneck due to the lack of accountability of developers with the quality of their delivery and a slow feedback loop that may produce reworking.
Current status: DONE
This is the final state for a User Story. Depending on your team agreements, it can be moved by a tester or by the product owner.
The Sprint Review offers an opportunity to showcase the work done during the sprint. Using the list of finished user stories as a foundation provides a structured way to conduct this session. During the presentation, while developers can demo the functionalities and explain the technical nuances, designers can shed light on the user experience aspects, articulating design choices and their alignment with user needs.
After the review, feedback collected can be jointly analyzed by designers and developers to refine and iterate on the product. This continuous collaboration improves both user satisfaction and technical robustness.
Conclusions
In this article, I’ve explored the relationship between designers and developers in product teams, emphasizing the importance of their collaboration. From my experience, these roles can sometimes work in isolation, which can hinder progress. To illustrate a solution, I’ve described the lifecycle of a user story and how this workflow can bridge the gap between these roles. While I’ve shared my preferences (as NOTES), every team and project has its nuances. You should tailor these insights to your specific situation, ensuring they fit your team’s unique dynamics.
You may also want to read my previous article about the dual-track development model, which combines perfectly with the workflow I’ve presented.
