Best Practice: what can Designers learn from DevOps?

Posted on September 20, 2018 at 4:31 pm Written by

The advent of agile methodologies means software projects now tend to evolve through frequent and incremental updates (‘continuous delivery’) rather than the infrequent major version releases of old (‘waterfall development’). This ‘fail fast’ environment of rapid deployment, testing, learning and fixing has increased the importance of software Development and Operations teams regularly sharing information, content and tools, rather than working in isolation from each other.

Developer and Operations Teams must work closer together

If you’re working in any kind of technology field, chances are you’ve heard the term ‘DevOps’ bandied about. It all sounds exciting and futuristic, something possibly only software developers and IT technicians would really need to know anything about. But as designers, there may be lessons to be learnt from this new approach to software production.


First off – what exactly is DevOps

Taking lessons from real-world large-scale manufacturing practices, DevOps has been developed as a way of combining 2 important, but necessarily different, parts of a software project team:  Development and Operations (see what they did there?).

Developers – such as coders and programmers – are all about innovation, changing and improving software. In order to add new features and update older ones, Developers tend to destabilise a system.

Operations – such as SysAdmins or IT infrastructure technicians – are all about maintaining the software and ensuring it is stable on a day-to-day basis. They are the ones that deal with any bugs that arise, and handle final testing of software changes before deployment to live users.

Operations keep systems stable, Developers tend to destablise systems

Naturally, the potential for conflict between these teams is high if they work separately. DevOps is an organisational philosophy designed to bring them closer together through better communication and collaboration.


So, how can this be achieved?

DevOps isn’t tied to any particular set of tools or pieces of software. What you use isn’t as important as how you use it. Whilst DevOps as a way of doing things means slightly different things to different organisations, the following guiding principles will give you a flavour of what to aim for in yours.

  • Collaborate and communicate
    Everyone in a team has particular responsibilities on a software project, things they specialise in. However, being in regular communication with everyone on both teams means knowledge can be shared, expert help can be brought to bear, feedback from a different perspective can be gained. Regular communication is key: quick daily meetings to review work and assign new tasks means everyone knows what they’re doing day-to-day. Documentation of all processes and code means no one person is the repository for key information. For every task, ideally at least one other member of either team should be able to pick it up and carry it forward.

  • Always consider the whole system
    Rather than focus on one way of fixing a problem or creating a feature, DevOps philosophy asks that everyone involved in a project takes each one and considers all potential solutions, not just those involving their own particular specialist field. You may not need to write a code fix for that UI problem: it may be that extra customer training can be provided, or a database fix will solve it – maybe even outsourcing to a dedicated service or company will be more cost-effective.

  • Gather rapid, meaningful feedback
    Rigorous testing combined with meaningful feedback loops should be set up to find and fix issues before the live release of any software. This is where collaboration between teams comes into play, fresh team perspectives will often spot flaws that the original developers may be blind to. Ensure there is a clear way adding and receiving this feedback, and after deployment set up ongoing monitoring and feedback from the software’s day-to-day use in the wild.

  • Automate whatever tasks you can
    Humans tend to be not-so-great at repetitive tasks or testing. On top of that, time is a precious commodity – ask any Project Manager! Automation tools allow such tasks to be delegated to the machine, allowing the human to concentrate on more creative endeavors. For example, batteries of tests that are always the same and need to be consistent, or deployment of software to testing and live environments. Do ensure any automated processes give meaningful feedback on exactly what they’ve done, and what the results are.


What does this have to do with Design?

The Design workflow works in a very different way to how Development and Operations workflow tend to do. For instance, due to the way design applications work, creating iterations of designs is quite different to how developers iterate code in a version-controlled environment. Collaboration on the same design file at the same time as another designer is also very difficult.

Development and Design workflows are very different

However, there has recently been a movement toward establishing some kind of ‘DesignOps’ strategy, based on some of the principles of the DevOps philosophy. The aim is to come up with a way of working that will help Design teams deliver consistent high-quality work regardless of how big or small an organisation may get.

3 things to look at when creating your own DesignOps strategy:

  • Quality
    Ensure the Design team has all the training, tools and right type of organisational structure around them to help them produce the best quality work they can.

  • Efficiency
    Streamline the design workflow by removing unnecessary hurdles. Use the same design tools and processes across the organisation to produce work at a consistent quality in the shortest time. Enhance collaboration and feedback between Design team members and other stakeholders in the design process (Project Manager, Customer support, the customer themselves).

  • Design values
    Establish a cross-organisation design ethos and use documentation to communicate these effectively. Everybody in the organisation should be able to relate to them, understand their value, and implement them correctly.

Establish a cross-organisation design ethos



If the success of DevOps is anything to go by, establishing a DesignOps strategy for your own organization can help reduce stress and boost efficiency. Maybe now’s the time to join the movement towards a better Design workflow?

Follow Mike Nicol on Twitter

Mike Nicol

Digital Designer & UX Craftsman at NewZapp


Get the latest Email Marketing updates & insights