3 areas for keeping the tension healthy between Design and Technology
There are many challenges that Design and Technology teams face along their journey to making a conceptual experience a reality. Our Technology Director Darren Shewry (DFJS) explores these, and looks at how teams can work better together.
Although the core challenge is translating designs into a real-world product; this challenge is multifaceted, and requires deep collaboration between the design and technology teams if it’s to lead to a more robust, real world product.
As each piece of the design system is implemented and integrated by developers, they are simultaneously proving and disproving the thinking behind the system’s design. It’s how these teams work together to resolve discrepancies that drives the project forward — there’s no silver bullet because all projects differ, and there’s only so much a team can predict!
At This Place, we focus on three key areas to ensure we create products that make an impact on people’s lives and business outcomes:
1. Systems and Environment Thinking
In the discovery phase of a project, the team’s objective is to gain insight into the system they are building for — by looking at how it works and how its component parts interact, then secondly at its environment and where it will ultimately operate for the user.
An example might be a large, existing ecommerce website that sells physical products. The system is the ecommerce site itself, and our aim is to understand the system from the perspective of the enhancements we’re looking to make.
A system scenario could be about an order being fulfilled from multiple dispatch locations; we may not need to understand how that happens exactly, but we would want to know what that means for the customer, what information is available — and helpful — for the customer, and therefore how we can best share that information as the order progresses from being placed to a completed delivery.
The environment in this context is how customers use the website, including things like their browser, the kind of device they’re using (a desktop pc, mobile device or both!) and their internet connection — fast, slow or patchy. These environmental factors will vary from customer to customer, and our aim is to take these into account so that we can provide the optimal experience for that customer’s environment, and within reason.
How does this help?
This knowledge helps frame the challenge; as both design and technology teams gain a solid understanding of the fundamentals of the system, helping to scope their thinking around its boundaries, and the constraints of the environment.
Having this insight early on means their time is spent most effectively designing and building, and reduces the risk of needing to re-assess previous decisions which have since been proven wrong. Setting the stakes early in the product life cycle ensures adequate time is available to assess and adapt, if this is done too late down the line, time is much tighter.
If a late-stage change in direction is needed without this early insight, there’s a risk the design team is caught on the back foot and a fix may not tie in consistently with other aspects of the design system. This can have various repercussions, including a potentially flawed customer experience that becomes difficult to unravel in the future.
On the technology side, by having an awareness of the system and its environment, the team can build the underlying architecture with known special cases — elegantly supporting nuance and failures, alongside enhancements for the new experience they’re building.
Systems and environment thinking allows the team to maximise what they can take advantage of, and minimise exposure to where the system might fail. The thinking is then tested and grounded by considering the Happy and Unhappy paths.
2. Happy and Unhappy paths
Happy paths are the default scenarios, which generally end in positive responses for the user, whereas unhappy paths deviate for some reason and leave the user unable to travel through their scenario as directly as possible.
How does this help?
With a Happy and Unhappy paths mindset we start thinking in terms of what the user is seeing when things are and aren’t going right, and where it makes — most — sense to get them back onto the happy path.
Planning for both paths means taking into account how the system should behave at various levels, how it should handle failures along the way, and how it should keep the user informed in the most helpful and relevant way.
The technology team can therefore build for failure from the outset — this is key. And although building for failure has an impact on any architecture, it ultimately leads to higher quality builds, and trying to retrofit can be difficult.
Example — ecommerce:
A checkout process that follows the Happy path:
- A user is viewing a product of interest on an ecommerce site
- User adds that product to their basket
- User clicks Buy now
- User is able to checkout anonymously having added credit card details, address, etc
- User receives a confirmation message, and subsequent email confirming the order
Unhappy path thinking — during the checkout process, the user experiences:
- Stock issues — stock availability changes in the time between adding items to basket and checkout
- Address issues — user is unable to deliver to their home address because it’s for a new building that isn’t in the address database
- Connectivity issues — user is experiencing a low quality mobile data connection e.g. it drops out mid-checkout
By thinking with the Happy and Unhappy paths mindset, we are exploring the system as a whole, which is why we see these paths as two sides of the same coin; where one supports the other when modeling the real world.
Although Unhappy paths are generally less expected, they do happen, and because we can’t always predict the Unhappy path scenarios, by designing and building to handle them, we optimise for the unknown and the unexpected.
3. Constant Collaboration
Design and Technology must work together from the very start and maintain that momentum throughout the project. As each team does their work, they are constantly validating their thinking across disciplines, helping identify issues earlier on in the process, and solving for those, rather taking a more linear approach to design and technology work, such as a single handover, which can result in solutions that invalidate other work and lead to inferior experiences.
As the project progresses, there are learnings that come to light, like a change in requirements, or perhaps a previously unknown technical limitation. If the teams are not constantly collaborating and handling issues when they come up, these problems can compound as building continues.
The collaboration itself should happen in the form of standups, project boards, and other project rituals, but also in more ad-hoc communications like on Slack or one-to-ones — the idea is to use whatever enables and keeps this collaboration going as smoothly as possible.
How does this help?
When design and technology teams are working together from the outset there is ongoing validation from both team’s perspectives, even before any build activities have begun.
This helps by not only making expectations and thinking clearer from the outset, but also gains more buy-in (and therefore alignment) across the team. It also keeps feedback loops much tighter, allowing the project to adjust and course-correct as needed much earlier.
Involving the technology team upfront in the design process ensures that the foundations on which the design is laid are technically validated and sound. To facilitate this process designers may produce both static designs and more dynamic representations of the experience they’re aiming for, such as prototypes.
All of this gives the visibility and valuable context that the technology team needs, enabling them to identify considerations that designers may not have considered — and vice versa.
Early design and technology collaboration also helps avoid designs being misinterpreted and, crucially, being incorrectly built. Armed with context for each design leaves the technology team clear on why certain decisions have been made and the desired outcomes.
Accepting features as Complete
A feature may have many moving parts or requirement changes late in the game, which add risk when it comes to acceptance. Despite the deep understanding that the teams have of the features built, the following activities help confirm that the feature has in fact been built to spec.
They also provide opportunities to identify where future enhancements could be made if they’re not feasible in the current project cycle.
Our acceptance generally starts with:
At the very least, the technology team should review a piece of work deemed ready by a developer prior to the next stage of acceptance. This should confirm that the underlying solution is technically sound, and that other team standards have been met too.
When a feature is completed by a developer, a designer reviews the work from a product perspective to confirm it meets requirements and behaves as envisaged.
Product Owner acceptance
Product Owners typically test with the end user in mind, but with the added perspective of the challenge the product is trying to solve. They may lack the context that the design and technology teams have as far as implementation goes, but this can result in higher quality acceptance testing.
Constant collaboration at all stages of the project is important, but absolutely key as the process of translating designs into reality happens. This is enabled through team analysis, discussions, project boards and rituals, where each gives the opportunity for feedback loops and course correcting.
In taking this approach we know that tensions come up between design and technology teams, where there is give and take, and each is coming from a different perspective, but all with the same goal in mind — the best user experience. So we see this tension as a healthy one, which we welcome and embrace because we know that to create the best experience possible, we need to push boundaries.