Design Operations
I learned early on in my career that there can be gaps between what I design and what actually gets built.
Part of this is human - engineers do engineer things and they don’t always understand the importance of the details in a design. So I need to bring the development team along with me and make sure we focus on the value we’re delivering to our clients and their users, not just working through the product backlog with one eye on the deadline.
Another part is practical. If I want the rest of the team to understand those important details, I need to speak in their language and communicate with them in ways that fit into their workflow.
Problem: Quality management
This is a big one for me. Most places I’ve worked run a hybrid waterfall/Agile delivery process.
Waterfall methodologies have built-in quality control processes. In Agile, quality is owned by the whole team.
But in hybrid approaches, although there are QA engineers reviwing the details, quality often isn’t directly managed by anyone at product level. This can be a real problem when requirements don’t pull through or designs aren’t implemented accurately.
Solution: Close the Loop
The fix here is to close the loop. Designers need to be involved in writing user stories to ensure that all the requirements are captured, QA engineers need to be in contact with the design team so that there’s full vision across the delivery pipeline, and project managers need to implent regular and early reviews of work-in-progress code.
Strictly speaking this is just basic Agile good practice, but when time and budgets are tight, these things often get regarded as overheads rather than investments in time and fall by the way
Example: GAA Redesign
In Summer 2024 I led a design rework of the Gaeilic Athletic Association’s website. The project manager coudn’t see any value in me turning up to the regular Agile daily standups but, once I’d reassured him that I could hide the hours in my timesheet and wouldn’t be billing them to his budget, he eventually agreed.
As well as the numerous small queries and design issues we addressed, the daily contact created strong relationships with the engineers, who then felt more able to contact me during the rest of the day with questions and suggestions. The result was a pixel-perfect product.
Problem: Design documentation
I’ve found that, counter-intuively, writing detailed functional specs can be unhelpful. In hybrid delivery methods there can be separation between designers and engineers and the temptation is to try and plug these with detailed specs.
But if they’re too detailed, they become cumbersome and time-consuming to manage and important details can get lost in the mass of annotations.
Solution: Treat it like a product
As a UX designer I treat developers as users of my documentation and apply the same principles as I use when designing products to make sure that what I deliver is what’s actually needed.
Taking a user-centred approach means that I get to understand how best to hand over designs and where to surface requirements so that they easy to consume and things don’t get lost.
Example: SYZYGY Functional specs
At SYZYGY we were experiencing a high volume of design QA issues in our products.
I did some user research among the developers and found that our functional specs weren’t well structured. Everything looked like it had the same priority and details were being missed because they were too hard to find.
So I worked with the design a new functional spec template with annotations grouped by who would consume them. Then I added clear headings to sign-post the content.
The result was a significant decrease in design QA issues, and a closer working relationship with the developers. They appreciated that we’d taken the time to understand their needs.
Example: T.Rowe Price Delivery
While I was at ELSE I worked client-side in investment bank T.Rowe Price. The development team worked on the floor below the design team and this was causing communication issues.
I noticed that there was a large whiteboard behind where the developers sat, so I moved our reference printouts onto that and held our design review sessions there (see image).
Developers couldn’t help but eavesdrop on our dicussions and often spontaneously joined in. This created a natural communication channel for very little effort.
Problem: Minimum Viable Products
I have to admit, my heart sinks slightly when people talk about delivering an MVP. They probably work well in a startup with a single app, but most of my projects are redesigns of existing, mature websites for established brands and this creates problems.
Firstly you’re delivering a less good version of what the client actually wants and probably already has. Apart from increasing the risk of scope creep, that also reduces the impact of the product. After a long and costly redesign process, clients generally want to launch their new sites and apps with a fanfare, both publicly and internally to their stakeholders. MVPs naturally mute that ‘ta-da’ moment.
Secondly, I believe in the mantra that broken gets fixed but mediocre sticks. In times of tight budgets, there’s always a more pressing use of time than using it to fix something that’s basically working. This often means that design debt run up delivering the MVP doesn’t ever really get paid off.
Solution: Plan long, deploy in stages
One problem I’ve seen with the MVP approach is that the team only plans as far as go-live. If you’re going to knowingly deploy a sub-standard product then it’s important to extend the planning horizon for 3 months beyond that. This ensures that any debt is properly captured and a prioritised set of fast fixes is planned to pay if off.
One other approach is to avoid a ‘big bang’ launch and deploy the new site in stages. This isn’t always possible with a replatforming project, but if it is then it makes total sense to get code live and earning its keep as soon as possible rather than holding things back until everything is ready to go.
Example: GAA Redesign (again)
The GAA redesign was also a technical replatforming as we upgraded the site to a new version of Deltatre’s proprietary content management system. Working with the tech lead we developed an approach whereby we prioritised the changes we’d make in order of value to the client and their users and deploy them in stages.
This more Agile approach meant that the new designs were out there delivering value, not only to fans and the business but also to the delivery team through the ability to harvest data about the impact of the new pages and ensure that the overall design direction was working
Example: Marks & Spencer replatform
One of my client-side roles was as part of the team bringing M&S’s ecommerce platform in-house. This was a long project with a lot riding on it - our first year target was to deliver £800million of turnover through the new site.
While the launch was obviously a milestone, the business rightly took the view that it was the start of a conversation with our users - an opportunity to harvest real-world data. I was part of a team that was already looking beyond it.
We’d identified some issues in pre-launch user testing that there wouldn’t be time to fix before the product went live, and so we were working on proposals to fix them.
We had some hypotheses from the pre-launch tests that we investigated with A/B testing post go-live. For example, we knew there were issues with the filter drawer in the product listing pages so we proposed and tested some fixes (see image).
Although the optimisations we made were quite small in percentage terms, with such a large turnover even small wins amounted to tens of millions in increased revenue.