How research, design and development collaborate
Last updated
Was this helpful?
Last updated
Was this helpful?
There are many benefits to close collaboration between research, design and development.
Working together allows us to take the risks our of projects and lets us spend budget where we can make the most impact in the time available. Our researchers and designers help the team understand exactly who we’re designing for and why. We plan and review the design, architecture, and development together. So what we create is effective for users, as well as being technologically feasible and efficient.
For our clients, collaboration means we deliver better value for money. The delivery manager has a clear view of the expected team workload and can prioritise the areas where we’ll deliver the biggest impact. This helps to improve our working relationships too.
And finally, it’s good for us. It’s good for morale. We all feel more involved in the decisions we’re making as an organisation. We understand them better and that equips us to deliver better work.
When opportunities for a service are being explored, we need to understand the user needs, business requirements and technical landscape. In addition, we take into account other factors such as the political landscape around the service, retirement of any existing service, approach to accessibility, and possibilities for roll-out - including training. We work together to consider these factors as we plan projects and propose solutions.
Before we dive into the designs and development, first we assess the technical constraints, possibilities and approach for the full service before going into the detail on each individual feature. The solutions and technical architect will gather with the lead researcher, designer and developer to ask the following questions:
Is this functionality best created through:
bespoke code (where we start from scratch)
reusing existing code we’ve developed on a different product of ours
licencing existing services
using OpenSource components for specific functionality?
If we are writing bespoke code, how feasible is the challenge within the time available? We need to know if this is something we can and should be building. And if we are building it, what technology do we need to support it?
What's the best way to approach the user or business need? The software developers might have a suggestion for how those needs could be met in a simpler or easier way.
While this planning is going ahead, the solutions architect takes a strategic look at the infrastructure that supports these elements and how it fits into the bigger picture. This way, we don’t develop something we can’t support further down the line.
With the approach confirmed, we can move into design.
When the design team have finished the low fidelity prototypes (the minimum functionality and visual elements needed to share a concept), we sense-check those designs with the wider teams.
The researchers and designers host a meeting with the architects and development to share the prototypes and collaborate on their progress. They talk through what they have designed, and how it addresses the business requirements and user needs. The architects and developers review what it would take us to deliver these plans. This gives the designers the opportunity to address challenges, revisit the design and make realistic plans for the next sprint. As we progress through the different phases, this moves from a high-level overview of the full service into more detailed features.
Once we’ve reached an agreement, the designers create high-fidelity prototypes for the user researchers to test. The business analysts interrogate the plans to make sure they meet the client’s needs. The prototypes will go through various iterations as feedback is built back into the designs. This is a good opportunity to share the prototype with the client. If they're happy with a feature, they can sign it off. If the feature isn't quite meeting the user needs, the client may choose to deprioritise it and put it in the backlog to be revisited at a later date.
With the current design phase signed off, it’s time to hand over to development. In a prioritisation session, we review the designs and break down the project into deliverables. That work is divided into sprints, and the development can begin.
We run show-and-tells at the end of every sprint to show the progress we’ve made. This presentation is to the internal team working on it as well as the client. It’s a great touchpoint for a progress update from development and for the researchers and designers to review how the plans are being brought to life.
The client reviews the feedback from the most recent sprint, including usability testing and quality assurance testing, and prioritises future requirements according to what will make the most impact in their organisation. Based on that rating, the requirements move into internal project planning to progress through the design and development sprints accordingly.
Once a deliverable is completed, we’re ready for the next one.
It’s not just the regular meetings in our sprints that are important. As well as regular weekly ceremonies and status reports, we also have monthly check-ins for the project as a whole. We assess if we’re running to schedule and budget, and adjust the plan if we need to.
If we spot areas where we can save time or money, we raise them here. For example, that might be a less feature-rich design in a low priority area.
This is a good opportunity to step back from the project and assess how we’re doing, where we can improve and how to make those improvements.
