Designing for the Real World
Ever seen a beautiful UI design that never got built? Of course you have.
Let’s talk about the long-standing misalignment between design and development, and why it’s solvable with more structured collaboration and more strategic delivery planning.
Perhaps, concept design is one of the greatest phases of the digital transformation lifecycle. After all, designers typically deploy their finest blue-sky thinking, conceptualising beautiful, clean interfaces, engaging micro-interactions, and fluid transitions that are intended to really engage and inspire users.
But how often are these design aspirations actually realised — even months or years after an MVP is released? And, moreover, how much time do designers spend considering developers’ requirements versus those of customers? I would suggest the ratio is 1:4, and it’s one of the reasons design and real-world engineering outcomes remain all-too-often out of step.
Of course, though, blue sky thinking is a critical part of the design process. No organisation will retain its design team if their creativity is consistently reigned-in, and their ability to ideate and explore is frequently constrained. It’s not about removing creativity, though. It’s about letting it occur within the right collaborative environment.
In fact, this whole dilemma is grounded by sequencing and collaboration problems. Typically, rather than embarking early on an unconstrained exploration of design options and then systematically reigning them back in over time, designers push the envelope early… and then struggle to bring things closer to home after engineers overlay their feasibility and viability lens. The result is a rapid succession of design rework over a condensed period of back-and-forward between the designer and the engineering team. This all tends to take place very late in the design lifecycle, simply because active collaboration between the two teams is either ineffective or infrequent from day one.
In the end, neither party really gets what they want. The design is diluted without much strategic thought, and the technical foundations aren’t sufficiently laid to enable progressive design enhancements over time.
And, finally, the business stakeholder group becomes frustrated with the outcome: the last they saw of the design was something progressive and transformational. Something unique. What they see as they head into the first production release is nothing like that at all. History tells them, too, that they’re unlikely to ever see the blue sky aspiration realised.
This problem repeats itself to varying degrees in almost every digital transformation program, in almost every major enterprise. The best design isn’t the one that wows the stakeholder group. It is, instead, the design that has been shaped with the collective customer and engineering input. It is the design that can actually be built.
And the problem goes deeper than the management of stakeholder expectations, too. The design workflow is often also polluted by this misalignment. Through the usability testing cycles, much of the user feedback is gathered based on prototypes that aren’t representative of what can genuinely be engineered. Feedback is gathered, the prototypes are iterated upon through several cycles… but, then, a large portion of these feedback loops become irrelevant once the solution is built and many of the small, but critical, features fall out of scope. This is one of the (many) reasons why redesign activities often yield very different performance results in production to what was seen during concept testing.
Some organisations have moved to address this problem structurally, forcing design and engineering into the same org unit, or at the very least, embedding an operating model that sees them interface more frequently in stand-ups or other Agile ceremonies. This helps — and certainly, creating some structural overlap between customer and technology outcomes is critical — but we still see many businesses who’ve embedded this model continue to struggle with alignment.
One solution to this is in the phasing of design activities. All too often, development and design run almost in parallel, with engineers frequently claiming to be blocked, awaiting final UI to come through. In a mature Agile delivery model, this should almost never occur. Design should be at least two to three sprints ahead of development at any point in time. And, if the gap between the two is ever narrower, this is because unforeseen engineering problems lead to design rework (and sometimes, this is just unavoidable). All things going well, though, this “buffer” time should rarely be consumed.
It’s very similar, actually, to the notion that BA resources should be working several sprints ahead as well. In fact, BAs should be almost joined at the hip of designers, given the former should play a critical role in translating design aspirations into actionable engineering tasks, and vice versa.
Of course, it’s all well and good to talk about reality vs best practice, but why does a gap between the two even exist in the first place? Typically, when a project discovery takes place — and assuming that the session has been well run — the participants will walk away with a collective and aligned understanding of the problem to solve, an appreciation of what success looks like, and a level of awareness around the key milestones of the project. They then carry these into an evolving phase, where they turn them into an actionable plan. Out of this, teams are confirmed and an operating cadence is reaffirmed.
But, hang on. If everyone is starting work at the same time, how can design be several sprints ahead? Exactly.
The step that’s so often misconfigured is the design discovery and ideation; a focussed session where design standards and aspirations are set, and crucially, an environment where engineers are actively involved and overlaying a feasibility lens as early as possible. Designers will naturally challenge and stretch the boundaries of the technologies — and so they should — but they’ll do so early in the project. The concept of design discovery is hardly new, but the presence of engineering input in these sessions is far less common.
Designers generally don’t like engineers constraining their thinking, and often, engineers don’t like their technical frameworks being impacted by transformative designs. Keeping the two functions separate until the final stages of delivery isn’t the solution. Systemically joining them together from day one is.
Here’s a 10,000ft view of what the general project workflow should look like:
The other thing here is to ensure that sufficient breadth of design groundwork is laid as early as possible, well before any major engineering takes place. Using design discovery to explore a small handful of screens within an entire platform isn’t the way to do it. Sketch work and interaction models need to be produced for most major areas of the application, and the interplay, navigation, and user journey between these sections needs to be understood at a basic level. If we’re talking about an authenticated environment, too, designers need to come with a basic idea of where low-state, high-state (or step-up) authentication will come into play, and what impact they want this to have on the user experience. These are just a tiny example of the foundational UX considerations that can materially impact the engineering of a new platform. And they need to be known and discussed early. For authenticated environments, Security input is also needed (and this can have a huge impact on the desired experience), so overlaying this lens in early discovery is also very important.
This entire space is also where a good BA comes into play. They will join the dots between the business requirements, the customer problem, the design responses, and the development considerations. They will also remain the objective conduit between designers and engineers, and facilitate collaboration in the right areas throughout the course of a project.
Really, it boils down to ensuring responsibilities are clear upfront, and also ensuring that each key person is given an opportunity to input their thinking at the right moments in time. The IM or Delivery Lead should be driving these forums, collating the outputs, and ensuring everyone is aware of them. Inevitably, too, there will be design or technology hurdles through the course of the delivery and when these occur, it’s equally important to realign all key people around the resolution, so that every link in the chain remains connected.
This model is very scalable, but it lives and dies by collaboration. Designers that don’t want to engage with engineers won’t see their work come to fruition, just as engineers who don’t remain engaged with designers will end up diverting from the ideal user experience outcome. It’s always important to remember that cross-functional teams exist to ensure the optimal combination of knowledge and experience is brought together. If one person or one small group could yield the same outcome, then project delivery would be very different. As it stands, though, no-one is that capable on their own.
Lean on your peers and respect their input. But, equally, call them out if they’re not respecting yours. Good collaboration is when people come together regularly, in a structured way. Great collaboration is when everyone feels comfortable and empowered to share their views.
