The very definition of a Creative Technologist

I’m walking through the double-doors of what turns out to be a brightly lit office. My palms are sweaty and I’ve got those pre-interview butterflies. A friendly smile melts away any nerves. “Are you Dave? Have a seat - make yourself comfortable”.  I’ve felt at home ever since.

Last month marked 18 months since I walked through the doors at cxpartners to audition as a trainee developer.  I’ve needed more than my technical knowledge. Creativity, business-savviness and emotional intelligence have played an important part in the projects I’ve undertaken here.

cxpartners has a culture based on principles of iterative development, cross-functional collaboration and customer-centricity. But what does all this mean? And why are these principles important? Well, let me explain.

These days, every company, whether they realise it or not, is a “tech” company.  You may believe that because you aren’t in the technology sector that you aren’t a “tech” company.  But in 2019, every industry uses technology to some extent. The “tech” that you employ can either help or hinder your efforts of creating value for your customers. Off-the-shelf solutions don’t give a competitive advantage. Your competition can just buy the same software and match your capabilities. By really understanding your customers and their needs, you can employ technology to enable real innovation and open up new markets.  How and what you empower your staff with matters.

Design in software development used to be a distinct part of a linear process:  design, test, build, ship. This process makes sense when the product is a physical format, such as a computer game distributed on a cartridge. The costs of getting it wrong, when you can’t go back and fix it, can break you. Release a flawed product and your users can be left frustrated, angry, dejected and ultimately they’ll lose trust.

These days, IT Services are no longer deployed on floppy disks or CDs. Applications are delivered and updated instantaneously on the internet. This has revolutionised software development. Rather than taking a gamble on projects with long incubation times, we can release products early and iterate on our solutions as change demands.

To make things happen in this iterative fashion requires small, empowered, multi-disciplinary teams.  I’ve seen how a broad range of skills helps collaboration in these teams.

Working iteratively cuts out sources of delay, inefficiency, and risk that dog larger projects. The need for comprehensive documentation is avoided because the output of each iteration is working software. We remove guesswork or assumptions through regular feedback, and we respond rapidly to change.

Last summer, I worked on a project creating a government service for local authority and utility company workers to collaborate on street and road works.  I worked alongside our user researcher and user experience designer to co-design map-based tools. We created interactive maps based on user needs our researchers had uncovered.  Designing the interactions was a collaborative approach that merged our researcher's detailed knowledge of user requirements, our designer’s experience of interaction design and my technical know-how.  When we put our prototypes in front of users, we saw first hand which interactions were intuitive and which weren’t. We then put our minds together to improve the map using this feedback and repeated the process. Incrementally, we produced a tool which will enable people to understand what street works are planned in an area and facilitate collaboration on street and road works in the future.

When my stint on the project was over. Handing the baton over to my successor was straightforward. Rather than having to interpret how the software should perform from written documentation, they could see how the prototype operated and work from this.

At cxpartners, solutions are co-designed, bringing together different disciplines and views. When people visit our offices, they find it hard to tell who are the clients, who are the designers, and who are the developers - everyone works together. We typically work with a clients' product owner as part of the team. Involving the client reduces the need for complex contracts, creates transparency and deepens relationships. A collaborative approach means that consensus-driven decisions can be made.

Last spring, I saw the power of co-designing first-hand. The product owner on one project wanted to deliver a raft of features into the next iteration. We embarked on a process of prioritisation but they deemed every feature as a high priority. I was uneasy about committing to do so much in such a short space of time. But when we sat down as a team to sketch our ideas about how the product could work, everyone realised how complex it was to fit all the features in.

From this point on, we were able to prioritise together in a constructive fashion. By taking a different tack - a fresh impetus had been released into the project. We worked out which features were essential to achieve the outcomes the users most needed.  With this wind in our sails, we developed and launched a product that made a real difference to our client’s users.

Another reason for the success of the project was that over the course of our time together, we became a tight-knit crew.  This had a lot to do with team size.

Smaller teams communicate more effectively than large ones and are quicker at solving problems. Small teams also reduce the possibility of silos forming and encourage the exchange of skills. I’m flexible enough to work on a wide range of problems: both design and engineering so I fit naturally into a small team, working on whatever is needed at one moment in time.

At cxpartners we love T-shaped people - and I definitely fall into this category. T-Shaped people are open and enthusiastic about other people's disciplines. Whereas an ‘I-Shaped’ person has a depth of expertise in one discipline - represented by the vertical stroke - a T-Shaped person has a breadth of knowledge in other areas - represented by the horizontal stroke.  Rather than viewing problems through the lens of single expertise, a multi-disciplinarian draws inspiration from the interfaces between disciplines. They are able to explore experiences from many different perspectives and recognise patterns of behaviour to reveal deep insights.

I enjoy working with people with different skill sets. Having good knowledge of other team members’ disciplines means that I can empathise with them. The ability to build on other people’s ideas in ideation sessions requires the ability to be attentive and use active listening skills. To follow with “yes, and...” rather than “yes, but” can help snowball an idea. It’s not just empathising with team members that’s important, co-creation also happens with the user.

We all have our own unique perspective, or lens, on the world. This outlook been shaped over the course of our lives by our life experiences, our culture and our innate nature. When designing a product, it's tempting to think how would this work for me? However, we rarely get the opportunity to design a product just for ourselves. When we design for other people we must realise that our intended audiences’ background can be wildly different from our own. As experience designers, we must set aside our own biases and assumptions and seek to understand the problem from others’ perspectives.  At cxpartners we gain real insight through talking to users.

Because we spend time deepening empathy with the user, we begin to understand what they value. When we align business goals around what people value, we create a desirable product. Successful products differentiate from existing solutions in the market. True innovation doesn’t come from plucking ideas out of thin air. It’s using research to shine a light on unmet needs and thinking of solutions to meet them. To test these ideas, we build prototypes.

These prototypes are experiments that either validate or disprove any assumptions made in design.  The prototypes help us see how real people act in our user testing labs and out in the real world. They can also demonstrate that the service we want to build is technically possible.  Prototyping enables us to uncover any problems, find solutions and identify any risks. Prototypes enable us to test ideas at a low cost. We do just enough work so that we get enough feedback to move from a place of uncertainty to certainty.  As I wrote about in my blog post, the creative technologist and digital service design, the more realistic the prototype, the more valuable the feedback from testing will be.  We're trying to create conditions in which people will behave naturally so we can learn about what they do. Because we focus rigorously on peoples’ behaviours and needs, we build things that people want.

It turns out that I love creating prototypes.  Feeding off the exuberance and imagination of my team members to co-design and realise cost-efficient, hands-on experiments is awesome. I use a tool-kit of technologies: simple HTML pages, patterns libraries and templating systems. The internet enables me to connect prototypes to an array of devices and services through APIs. This can add a sprinkle of magic dust - adding functionality or live data - to produce a realistic test scenario.

Validating my belief that I’m in the right place - I got the best Christmas present last year.  My boss pulled me aside to tell me that I had been promoted to Creative Technologist. You might imagine that a creative technologist is just a coder who understands design, but this definition barely scratches the surface.  I’d argue that a Creative Technologist is a true team player - someone who collaborates to uncover solutions to complex problems where innovative breakthroughs and time-to-market are important. It’s a new job title here at cxpartners, but one that recognises the changes in modern working practices and the breadth of my skill set that I’ve talked about today.

Imagine what you could achieve by having a Creative Technologist on your project team...