Engineering design
As much as we talk about the desire for multidisciplinary teams and close collaboration with developers, there still appears to be an overhanging fog of superiority within design disciplines. The feeling that the design team are the arbiters of what should be built, and engineers who question it are punching above their station. I come across this attitude a lot, and it’s deeply disappointing, as well as unhelpful. I see this in people who really, really should know better… and -more concerning — I see this attitude being instilled in graduates and juniors who carry it forward.
So how has this come to be?
The consumer web has a lot to answer for, here. The rapid growth of the web post the DotCom boom-and-bust led to high demand for anything which enabled companies to exploit this new platform. Initially this was a focus on developers, but soon enough the need for design that went beyond ‘make it look nice’ and ventured into ‘make it more successful’, and later ‘make it more inclusive’ birthed the early 2000s surge in UX and design practice.
While development and project management were already largely established, the growth spurt of design of digital products has been left largely to a mixture of psychology, research techniques and, to be blunt, iterated guesswork.
The result of this has been, I admit, a fair degree of success… after all UX is a rapidly growing discipline with rising demand and recognition. The lack of certain rigour has largely gone unnoticed due to the relative simplicity of projects. The corporate sites, e-commerce, content sites, charity or digital forms largely follow a now well-honed set of rules. You go into such a project with a good idea about the content and the flow — the bulk of the job then becomes ordering, structure, research and presentation.
Where the current accepted methodologies fall down is in more complex projects: in enterprise applications, or in government services where complexities such as transactional, multi-user scenarios are commonplace. Wire-flows, wireframes and traditional process flows are simply insufficient, and the fallout can be messy. I’ve seen:
· Designers who are in tears not knowing where to start (they quit);
· Designers vastly underestimating work required and being subsequently sat on by the PM (normally just before they quit);
· Designers being pressured to deliver a fully functional wireframe of a piece of enterprise software, because that’s how wireframes work, right*? (they quit, inevitably)
The main consequence of the above, in addition to unhappy designers, is the loss of confidence in user-centred design in general by technical and project teams, and understandably so. The perception that UCD isn’t sufficient, or ‘it isn’t right for this product’ persists and nothing improves.
It’s all terrible.
But… large systems are designed and built all the time; not necessarily in the best way, and rarely with good user research in my experience, but it does happen. Complexity is handled and realised. By whom? By technical teams. By software engineers***; those lowly implementers of designers’ dreams.
Technical solutions require planning, architecture and design. There is sketching (or there should be) and tools for modelling and designing technical solutions. Like wire-flows and other design artefacts, these models are shared, reviewed and put through their paces before they are built. So, given these tools are being used to model and design the solution we have a hand in proposing, why are we as a practice not using these techniques ourselves? It’s not because they’re unsuitable; it’s generally because designers are simply unaware, and understanding what software engineering can provide to our relatively new and shiny discipline has been overlooked.
There are some within the design industry who’s contribution to better working is to bang the drum for designers to learn how to code, as if therein lies some gateway to truth, or that C# or JavaScript can become a common language by which we can communicate with tech. teams.
Does it help?
Maybe. A bit. Not much.
Anyone can write code. Literally anyone. There is far more to software engineering practice than writing code, and — in my opinion — not much practical value that can be gained by learning to write code as a hobbyist. As a former software engineer, I benefit most from my understanding of the ins and outs of software projects… of how solutions are planned, and of risks and issues which can arise… the importance of traceability, release strategy, continuous integration, maintenance, scale and more. These things, far more than my ability to actually write something coherent in Visual Studio.
In my opinion there are more valuable things to learn, and more useful practical techniques which designers can capitalise on to improve their own work. Are they going to change the world? Probably not, but they can help.
This feels an appropriate stopping point, but I should like to follow up this post with another introducing some of the techniques I employ as a designer in central government and enterprise, and which I teach my team.
— — — — — — — — — — — — — — — — — — — — — -
*Of course there is an education piece here, and I undertook it myself, but where the designer can’t voice how daunting the task is, or that they don’t know how to approach it, a team can request completely off-the-wall things in desperation, and they can’t really be blamed for that.
*** I feel I should include the word ‘good’, here.
