In a complex product, designers, business analysts and developers need to work through questions together before they can consider a feature ready to build. A requirement may describe what the business needs without explaining how someone will use it. A design may show a complete journey while leaving questions about the data or implementation unresolved.
When those questions move between teams through documents and handoffs alone, people can interpret the same feature differently. The differences then appear during development or QA, when changing the work becomes more difficult.
I experienced this during the Credit Suisse International Wealth Management Platform redesign. My responsibilities grew from designing investment features to coordinating six designers as interim design lead, and eventually working directly with engineers to resolve issues before launch. Across those responsibilities, I kept encountering problems that required the teams to understand and review the work together.
Understanding where the collaboration was breaking down
I joined the redesign midway through the project, and a few clear issues became apparent right away. Designers and developers did not have any contact, and were even discouraged to do so. Because of that, many defects or gaps only appeared during the QA phase, which caused pressure among all the teams involved in this project.
There was also a gap between the financial complexity of the platform and the design team’s understanding of it. Business analysts sometimes provided instructions for how screens should work, while designers were expected to turn those requirements into interfaces.
That left designers with an important responsibility: understanding the financial rules well enough to assess the proposed solution. Without that understanding, it was difficult to question a requirement, recognise a missing step or explain why a different interaction might work better.
The separation from engineering added another problem. Designers could work through a solution with analysts without knowing whether the developers shared their understanding of how it should behave.
Using analysis to give the teams something concrete to discuss
We analysed the existing application and interviewed business analysts and process experts to understand the journeys and the screens they required. I created application architecture maps that connected those screens with their rules and data dependencies. We repeated this approach across projects within the platform.
The analysis mattered because we needed to understand what we were changing. A redesign could otherwise carry forward a misunderstood rule or leave out a step that the existing application handled.
It also gave us something concrete to review. We could look at a journey and discuss which information someone needed, where it came from and what happened after an action. Those questions crossed the responsibilities of business analysis, design and engineering.
Looking back, I would bring engineers into those reviews from the beginning. The analyst can explain the business rule, the designer can work through its implications for the user, and the developer can explain how the system supports it. They need to be able to question each other’s assumptions while the solution is still open.
Working through financial features together
My design work covered portfolios and payments, hedging and leverage tools, and adjustments to generated investment proposals. These features made the need for that shared understanding particularly clear.
For the mandate experience, I worked on keeping risk parameters, allocation and constraints visible while someone reviewed or adjusted a proposal. Portfolio and mandate information appeared alongside each other so the person making an adjustment could retain that context.
Designing the screen required an understanding of the investment rules. Reviewing it with engineering also needed to cover the information available and how the interface should respond to an adjustment. A visual review alone would not answer all of those questions.
Payments involved account context, foreign-currency accounts, cross-border transfers and authorisation. I designed the flows across desktop, tablet and mobile, but the underlying requirements still needed to hold across those versions.
This is where I see a practical role for collaboration during design. Before a feature is handed over, the people responsible for its rules, interaction and implementation should review the same journey. Any unanswered questions should remain visible rather than being treated as resolved because the screens look finished.
Combining user research with engineering review
I built InVision prototypes and worked with the internal research team on repeated testing rounds. Sessions ran over two days, with five users per day, and we used the findings to refine the flows and interface.
That research helped us understand how people used the proposed journeys. It could not answer all the questions about implementation, because a prototype did not behave like the underlying banking systems.
We needed both kinds of review. User research could reveal difficulty with a flow or the way information was presented. Analysts could help us understand the business implications of changing it, and engineers could help us assess what the change would require.
I also presented designs and prototypes to stakeholders across Credit Suisse’s international project teams. Although several groups reviewed the work, the lack of direct contact between designers and developers still left gaps that appeared during QA. Having more reviews did not resolve that separation.
Leading six designers through requirements and changes
As interim design lead, I coordinated six designers while continuing my own feature work. Shifting requirements were causing recurring problems, and I created a process map to make the steps, reviews and approval responsibilities explicit.
I used it to keep the team accountable for the work we had agreed to deliver and to challenge requests that fell outside our scope. When a change affected earlier decisions, the process directed us back to the relevant phase for review.
For collaboration to work, the team also needs to understand what a discussion changes. An analyst may clarify a rule that affects several screens. An engineer may identify a constraint that requires another design decision. A designer may uncover a missing requirement while working through the journey.
As a lead, I need to make room for those discussions and help the team follow through on them. That includes recognising when a question needs input from another discipline, bringing the right people together, and making sure the agreed changes reach the requirements and designs.
Clear responsibilities help here. Designers still own their design decisions, but they need enough understanding of the business and implementation to make those decisions with the other teams.
Working directly with engineering before launch
As the release approached, I worked with the global project managers to bring designers and engineers into closer contact and focus on the high-priority implementation issues.
Over a 12-week QA and hypercare period, I worked directly with developers, including late-night sessions alongside two external engineering consultants. We reviewed the implementation against the designs and worked through the gaps together. My understanding of front-end frameworks and back-end data structures helped me discuss those problems with the engineers.
We resolved high-priority defects before launch and prevented another development and testing cycle. According to the project’s figures, that avoided more than CHF 100,000 in additional costs.
Working together helped us get the release ready, but many of those conversations came after the design and implementation decisions had already been made. I would have wanted that contact much earlier, while we were analysing the application, discussing requirements and testing proposed flows.
That is what I took from the experience into both design and leadership: involve the people who understand the business rules and the people who will build the product while there is still room to work through the solution together. Keep that contact through implementation, so the teams can check that the result behaves as intended.