Tech is to digital service design what materials are to furniture, it’s the stuff everything is made of.
Whether you see it, like it, enjoy it, or understand it is irrelevant — data, code, and infrastructure the atoms, molecules, and methods that make a digital service.
The bad news is that digital design is often based on processes, ceremonies, and theory. The ability to create, or even comprehend, tech is not seen as necessary in the same way we would expect a furniture designer to understand how two bits of wood stick together, or an architect to understand why the roof stays up.
The good news is that a first healthy step in fusing design and tech in to one practice is pretty simple, and doesn’t need a degree in computer science or a “C:\DOS\RUN” tshirt.
The easy first step is getting on the same page on what ‘tech’ means.
This is the point at which I’m turning from the observed to the opinion. Feedback is very welcome.
My definition of tech, in the context of service design, is that it’s the material of the building blocks of the service (there’s another aspect to this metaphor, service containerisation, that I’ll cover separately). Tech isn’t the bit that happens after design, and we designers can understand tech without being a career developer, or being neck-deep in words like ‘continuous integration pipeline’. To use the furniture comparison, nobody is expecting us to make the tooling for the factory, but when we design a chair we should know it won’t break when sat on.
As a stab-in-the-dark, consider the following a list of cornerstones:
- Data — Its storage, sharing, privacy, collection and usage
- Code — What’s easy, hard, reusable, an API, a container
- User needs — Not just understanding what tests well, but what people need from your service
- Ownership —Who is going to make sure this service is always active, and never just running
The list doesn’t include tech — the list is tech
As the designers of digital services, we need to understand those building blocks. How they interact, intersect, overlap and affect each other.
If we’re to properly recognise the lean approach, we need to ask ourselves “What’s the simplest thing we can create to meet our users needs?”
- Simplest — What’s the tech behind it?
- Create — Design can be creating, not theorising
- Meeting user needs — How do we measure the viability and feasibility in relation to the desirability
How to start with this
Getting going is easy. You need an open minded design team, a creative technologist, and a shared focus on creating simple things that delight people, and improving them one bit at a time.
Look for developers who take on pleasure projects where they’re quenching their thirst for full-stack service design, find designers who like to hack away and create inventive prototypes using whatever method they’re best with, and find user researchers who’s MO is to find the very very core user need, not get positive affirmation on a suggested solution.
If you have any input on this, I’d really like feedback. I’m particularly interested in the rationale of those who think that a designer is, by design, not very technical. I’d also love to hear about situations where a tech/design mashup has worked. Leave comments!
