Why Great Products Need Great Collaboration

Developers need to be more vocal about the need to be included at these early stages, because working with designers to build useful prototypes, meeting users, and representing the technical requirements at the design stage, has a direct and positive impact on our ability to build good software efficiently, and gives users a better experience.

Address Preconceptions About Your Role

Usability is typically seen as the responsibility of our design-oriented counterparts. The perception is that developers can skip the initial user research because the user interacts with the design and not the inner components.

In other words, developers aren’t welcome to become involved in the project’s look and feel because they apparently don’t need to be. It’s another way of implying that it would be a waste of the developers’ time because they should work behind the scenes without any need to interact with the user at all.

This is especially true in large organizations, where the separation between roles is more distinct: rather than cross-functional teams, each discipline tends to form its own team. Why the segmentation?

• Do developers see design as something that’s beneath them?
• Do designers consider development as something that can be bolted on once the visuals are complete?
• Is a developer’s input regarding the design considered unnecessary?

The answer to all of these, sadly and far too often, is yes; sometimes these roles are seen as mutually exclusive.

Design Isn’t Just For The Design Team

The narrow view of a developer’s role isn’t solely a preconception that others have; I’ve heard developers exclaim vehemently that usability isn’t their responsibility, and sigh when they have to attend a design meeting. We’re concerned with building the engine, so why should we care about how easy the page navigation is, or how simple it is to add a product to the basket? That’s someone else’s responsibility. Yet, as Paul Boag explains, “Excluding the developer from the design process will do nothing but prevent the project from living up to its potential.”

During one project meeting, I suggested that rather than working from templates simply handed to us, we could partner with the design team and build the application together. I thought this was a fairly sensible suggestion, but I was met with confused looks. How could that possibly work? One developer quipped that we would have to teach the designers MVC for them to work with us – and that would be a waste of time.

Personally, I didn’t think we needed to go that far, but even if we did, so what? Wouldn’t designers benefit from having a working understanding of the framework we used? And in return, wouldn’t we benefit from learning how they worked?

The benefits I saw from us working together were:

• Both teams would have a better appreciation for the other team’s work.
• There would be less blame laid on each team by the other.
• We might actually learn something from each other.
• No wasted work building an HTML template that was impossible to maintain once the coding started.
• Shared pride and ownership in the project.

Of course, it’s not practical for the entire development and design teams to work together all the time; not all tasks require such close collaboration. That’s why it’s important to designate an emissary that can act on behalf of the technical team.

Designate A Technical Emissary

Meetings are boring. There is very little benefit in having both the design and development teams in their entirety at every meeting; there would be a lot of frustration and very little work. A much better way to approach meetings is to assign emissaries. Designate a technical representative, perhaps one of the senior developers, to attend design meetings on the team’s behalf, and make sure that they feed back any relevant information to the rest of the developers.

Limiting the technical representation to a single person has a number of benefits:

• The project manager isn’t losing their entire development resource each time there’s a meeting. Coding will continue.
• Technical concerns are raised and fed back to the tech team.
• The development team doesn’t always work on a single project. Iif attention is needed elsewhere then an emissary ensures that each project has at least one technical representative, and the rest of the team are kept updated.

Working collaboratively will align everyone to the project goal. A handover fosters an abject disconnect between each team, so it’s important that each team is represented during meetings where critical decisions are made.

When assigning an emissary ensure you don’t create an unnecessary, additional silo. Consider rotating the emissary role among the development team rather than assigning a single person, and make sure that any information discussed during the meeting is disseminated to the entire team so that a single person isn’t responsible. What happens if they go on holiday, or are off sick, for instance? Rotating the role and ensuring the information is available to the entire team ensures that everyone is informed without wasting everybody’s time attending a meeting.

It’s also likely that development team members who weren’t in attendance raise questions during the emissary’s debriefing that need to be communicated back to the design team. There are a number of options here:

• Make it the emissary’s responsibility to communicate any questions or issues with other teams.
• Organize another meeting where additional members are in attendance in order to work through the issues.
• Communicate the issues raised via email.

The methods you use to communicate any additional questions are largely determined by their importance and other factors; what’s most important is that the issues are communicated. The importance of having cross-team meetings is for questions and issues to be raised and ironed out. The people in attendance can address most points that are raised, but that’s not always the case, which is why it’s important that the emissary debriefs the team once the meeting has finished.

Define Meeting Objectives

If you’re holding a meeting – any meeting – it’s important to be clear about the objectives and make sure that someone enforces them; this is usually the person who has called the meeting. This is especially true when hosting a meeting consisting of developers and designers. Define an objective like: “We’re going to discuss the technical implications of building a shopping basket based on these three design ideas.”

A clearly defined and enforced set of objectives will be a lot more constructive than an open discussion about designs. I’ve attended meetings that turned into a long debate about how a chunk of text should be worded because developers disagree with designers; it’s a waste of everybody’s time, and usually just adds to the frustration between both parties.

Make Sure You’re Involved

There seems to be a common assumption that once a project reaches the development stage, all problems become the responsibility of the development team, but then the development team lays the blame firmly in the lap of the design team. I’d say that any problems that arise at this stage “because of the designs” are usually because we developers didn’t ask enough questions.

Being excluded isn’t an excuse: perhaps it’s not obvious to others on the team that you should be part of the design stage, and as a developer you should make sure that you are involved. If you don’t engage with the project design early then you’re setting yourself up for failure.

Ask if you can see how the designs are progressing, then ask questions like, “Have you considered how long X will take to build?”

Meet The Users Of The Product

Working solely from a list of requirements without ever meeting the people your work is supposed to help immediately puts a barrier between you and your users. At the UK Government Digital Service (GDS) they “believe that research is a team sport and encourage all team members to observe research sessions for at least 2 hours every 6 weeks. There is good evidence that this helps teams create better products.”

Even if your responsibility is primarily working on the database, it doesn’t mean you won’t benefit from seeing things from a user’s perspective. As a technical contributor to the project, you’re approaching the problem from a different perspective to team members with other disciplines, and so with your combined skill set you’re likely to spot issues or see opportunities that you simply wouldn’t otherwise.

See People Using Your Software

I was once on-site training a client’s staff in the use of a new EPOS system we had installed when I noticed a lag as staff members were making a sale in a certain way. They were interacting with the system via a different path than the one I used while building the product. They appeared to have stumbled across an inherent performance issue that I’d never noticed. When I got back to the office, I traced the issue back to a missing table index, so I added it to the next round of software updates for the client. Problem solved – but I wouldn’t have known there was an issue had I not been on site watching how the users interacted with it.

The Nordstrom tech team took this concept one step further and held a flash-build in one of their stores. They documented the results. Their app was built alongside shoppers (the users of their software) and so they worked in a constant user feedback loop over the course of a week. In the video they discuss how they discovered a fairly significant design flaw by chance, just by monitoring how users interacted with the app.

Invite yourself along to user training sessions, or, if another department uses your software, ask your manager if you can arrange a port of call to sit with them for the day. If your users aren’t directly accessible (perhaps you’re responsible for building a shopping cart) there’s a number of analytics packages that let you play back a user’s session to see how they interacted with your site.

Understand Your Users’ Frustrations

In his book Work Rules!, Laszlo Bock, the senior vice-president of people operations at Google, explains, “Having workers meet the people they are helping is the greatest motivator, even if they only meet for a few minutes. It imbues one’s work with a significance that transcends careerism or money.”

In “Fast Path to a Great UX – Increased Exposure Hours”, Jared Spool further explains, “While the core design team became very familiar with what users needed and wanted, they were constantly battling with these other individuals who didn’t have the same experiences.”

In actuality, developers rarely meet the users of the products they develop, especially in large organizations with projects destined for internal use. The disconnection between makers and users can foster unnecessary animosity. It’s not uncommon to hear developers react negatively toward users who couldn’t use or understand a certain feature; the negativity is often a result of the developer having never been in the user’s position, and therefore not understanding a user’s frustration.

The Problem With Templates

On a project where we had been given a design to implement into an established application, there was a particularly complicated part of the process that aesthetically looked very similar to another section, and so from a design perspective it made sense to use the same design for both sections. But from a development perspective each section worked very differently. The designs were then transformed into static templates, which were handed over to us developers.

Eventually, following much to-ing and fro-ing trying to implement the functionality exactly as depicted, the designs had to be changed. This caused unnecessary tension between the developers and designers. One camp saw it as the short-sightedness of the designers, while the other saw the developers complaining about the designs again.

Paul Boag explains that Digg had a similar issue: “From Daniel’s perspective, the change [to the design] was minor. But upon speaking with Joe, he discovered that this minor design change would have a huge impact on website performance, forcing Digg to upgrade its processing power and server architecture.”

The main problem was that the templates were only a static representation of the site, but they were touted as a prototype. The stakeholders signed them off on the basis that they met the visual brief, but they didn’t prove one way or the other whether it was functionally acceptable, which, as we found out, it wasn’t.

A template whose purpose is to be the base on which the system is modeled, and written without developer involvement, is next to useless. I’ve had to make changes to almost every template I’ve ever been handed to make it compatible with the back-end framework, or to make the desired functionality possible. From my perspective, the time and effort it takes to build these templates is largely wasted. When designers and developers work with each other earlier in the process, issues will get ironed out when it’s easier and cheaper to make changes.

Working from a living style guide is a more flexible way to develop than simply from a static template, because it deals more with the individual components and how they fit into the overall layout rather than single page views. The developers at Lonely Planet have seen “an organic move towards Style Guide Driven Development where developers are using it to build and iterate on components long before they reach any application.” Here are some of the benefits that I see from using living style guides, from a developer’s perspective:

• Modularized interfaces.
• It’s a living reference, kept up to date from the same source as the project.
• Reusable components that are easier to maintain and test.
• When a developer comes to implement the design they can pick and choose which components they need to create it.

Don’t Sit Back And Hope

Design decisions aren’t the sole responsibility of the design team. Decisions made during the design stages have far-reaching consequences that affect the entire project. A representative of each area, especially development and design, should be included when project-critical decisions are made.

Each project member needs to share the same experiences and understanding while building the project so that their respective parts slot together seamlessly. Don’t throw blame at another group simply because they didn’t include you in some discussion; speak up and make it known that it’s important you’re included. Quite often it’s nothing personal, so it’s your job as a developer to inform them.

Most importantly, remember that you are building software for people. Take a step back and try to visualize it from your users’ perspective. Better still, watch how your users interact with it and witness first-hand what works and what doesn’t.