developers designers

Empower developers and designers to become pals
Bas van Essen, Wednesday, August 15, 2018

According to certain researchers developers would look down to the work of designers. Developers would believe that ‘design is unnecessary or a luxury that is not needed in order to create successful products’, concludes the scientific paper ‘Perceptions of Software Developers’ Empathy with Designers.’ But another study shows that this assumed arrogance rather is frustration about the way designers work.

In ‘Collaboration Constraints for Designers and Developers in an Agile Environment’ researchers from public broadcaster BBC and the University of East London investigated if User Centred Design (UCD) can unify and satisfy developers and designers that work in an agile development. You probably know what agile development stands for, and for those that don’t know UCD: this article provides a nice summary. It tells you that ‘User-centred design puts the needs of the end user first, which means testing ideas and processes out on real people from the very beginning of the creation process.’

UCD is a typical approach that designers work with, but does it conflict with Agile Development, the working process that most software developers follow?

1*Z1u2bzDdi0NfDL-QoargVw.jpeg (540×540)

The researchers conclude: it does at the BBC. The UCD workflow of designers, that is also applied at a lot of startups, does not thrive within the way BBC approaches agile development. Both designers and developers consider the design work to be happening too much in a plan-driven way. Too many times design work is established upfront, when sprints still have to start. As a result, developers feel they cannot engage or contribute early enough.

What designers and devs say about each other

As the researchers used a qualitative approach to examine what’s being experienced at the BBC, they literally noted the comments of interviewed designers and developers. These comments provide nice insights in the problems that both groups are facing and therefore we decided to display them as conversation. BTW: we haven’t deliberately chosen a female emoticon for the designers, but we indeed have chosen a female one 😉

male-technologist-type-6_1f468-1f3ff-200d-1f4bb.png (160×160)

“Designers are still working too upfront, there’s not enough communication and feedback. They always seem to spend a long time designing for the ‘Full Fat’ version of the product – the ideal version, big upfront glossy designs, which have all the features and the best user experience.”

female-technologist_1f469-200d-1f4bb.png (160×160)

“A problem is that this whole agile process is biased towards developers, UX is just an afterthought. We’re not given enough time to design, or to give feedback later, or warning of things is coming up.”

male-technologist-type-6_1f468-1f3ff-200d-1f4bb.png (160×160)

“That is because the agile process is focused on delivery, not quality (of UX). The design process itself feels waterfall-ish. The designers go away to work up some stuff and then bring it back to us to implement. We often find when it becomes time to start the development on a story, that the UX assets we need are not ready. There still seems to be a resistance from many designers to move away from drawing pictures of websites in Illustrator and get things in the browser.”

female-technologist_1f469-200d-1f4bb.png (160×160)

“UX can be more involved into the agile process by just making that process more designer friendly. I pair with developers and go to their stand-ups on a daily basis, but admittingly it still feels like we as designers work in more of a waterfall manner.”

male-technologist-type-6_1f468-1f3ff-200d-1f4bb.png (160×160)

“For a start, it would be helpful to see designs (even just wireframes) earlier in the process.”

female-technologist_1f469-200d-1f4bb.png (160×160)

“I agree. It would be useful to engage with developers earlier in the design process to gauge what is possible and come to a consensus on a practical way to iterate. Working together in such a way that we understand the key technical challenges of developers is very important, a tiny tweak in designs can shaves days (or even longer) in development costs.”

female-technologist_1f469-200d-1f4bb.png (160×160)

“But frequently developers are just not able to take part in the ideation process because they are assigned to other work – the Product team requires them to continuously write code and build stuff rather than getting involved in our early design phase.”

male-technologist-type-6_1f468-1f3ff-200d-1f4bb.png (160×160)

“Yes true, but historically developers haven’t had a chance to really participate in the “design” process.”

male-technologist-type-6_1f468-1f3ff-200d-1f4bb.png (160×160) female-technologist_1f469-200d-1f4bb.png (160×160)

Both say: “It currently feels very much like a ‘them and us’ situation. For me, the only way to successfully build great responsive products in an iterative way is for the developer and designer to collaborate on the product itself (i.e. the production web site). This means sitting next to each other, and focusing most of their time on the product itself and less of their time on static mockups/prototypes. Working in a Design & Dev pair on every new feature from the beginning works great.”

So what did we learn?

Sprints shouldn’t be isolated to a team or division as many times one user story can stretch across the whole organization. If there’s a straightforward job such as creating a login form that stretches through design, front-end development, and then backend development, a corresponding user story can be created for every discipline. This supports the whole organization to stay on track and schedule and see who is being delayed, obstructed and why.

Sharing should be part of the company culture. The longer one is building in a bubble or without connection to other colleagues, the greater probability a colleague will be forced to wait, does not like the work, or makes unnecessary efforts. Show work and demos frequently. For example at the daily stand-up, do not summarize what you have worked on, but show a quick demo to the team.

Also involve developers in the ideation phase

The BBC researchers state that Agile Development is pushing teams to omit much of the up-front planning work ‘to remain responsive to changing requirements’, adding that consequently there’s little time for the usual research, analysis of requirements or any other elaborate prototyping characteristic that User-Centred Design is evangelising. But with the rapid development of technology that supports research, analysis and planning, and the prior involvement of developers, should we not be able to pass these stages faster?

1*Hz57sWHFHYVkS0i1lourhA.gif (400×333)

Let’s take away the frustrations that now are separating designers and developers. Otherwise authors like the ones of Perceptions of Software Developers’ Empathy with Designerswill continue to conclude that ‘developers see development as the most important part of the development process, and developers take design decisions on their own, many times based on a limited understanding, or disregard, of the design as a whole.” In doing so, the understanding among developers for design work and design processes will increase, just as designers will better be aligned with the fast-paced culture of software development.

9owei9tdqizr32yc.jpg (740×329)

Separated? 😉 At the left: one of our designers, Kasper, watching the devs playing foosball.

Also published on Medium.

Tags: , ,

Categorised in:

This post was written by Bas van Essen

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.