Let’s pause for a second and try to imagine, that your Scrum team is transformed into a team of home builders:
- Product Owner is now a home requestor
- Scrum master is the construction lead
- UX designer is the design architect
- Development team is a team of structural engineers & builders
Your team’s goal is to build a new home for a client, who knows exactly what he wants: a two-and-a-half floor house with many windows. He loves flowers all over his place and they need light. Also, he wants a big terrace to be able to enjoy the fresh air.
So the team has excepted the challenge and the work is now started. Suddenly, as it often happens, there are some problems coming your way— it has started to rain and the forecast predicts that it will continue this way for a week. Weather conditions cause a delay in work and some planes to be changed. After all —your team has managed to deal with the issues and time has come to showcase the results.
The first thing Product Owner sees at a demo — is a slide with the burn-down chart, taken as screenshot from JIRA, that shows red line meeting blue one at the bottom. This means all sprint points are delivered and work is completed. Sounds great, right?
But wait, there is something wrong here… The delivered result doesn’t seem to be matching the initial project goal. Styling looked different on the initial sketch, and the house is not really functioning as designed. There are less widows and the terrace doesn’t have a place for flowers. At this point somebody from the home builders team points out: “Additional windows and place for flowers were considered not critical, so we left it out because of the time constrains!… ”.
Hey, waaaait a miiiinute… Sounds familiar?
So who’s fault is that the end result is different from the planned goal? Who is to be blamed? A Developer, who has developed a wrong THING? A designer, for not clearly communicating WHAT needs to be developed? A Product Owner, for not following up with the work? Maybe it’s a QA tester, who didn’t spot the differences?
The problem with the above situation mostly hides in the broken (or totally absent) communication between designer and developer. Often, in the software product organisations, we see the same picture: a feature is being planned by the Product Management, specifications are handed off to a Designer to be put in a mock-up and later visuals are given to a Developer to do the coding. And as soon as the work have been given for development – designer is moving on to the next challenge, as her/his work is counted done. Next thing that happens – a design question comes up, and because designer is already moved on to the next feature — these questions are being answered on the go, by the Developers and Product Management themselves. The solution in this case will often be taken without thinking about consistency and accessibility matters, and most important — will be spoken from a technical (developer-minded) perspective.
My story — growing UX in a development-driven culture
For last 4+ years I have been working as a UX Designer, and later as UX Team Lead at XebiaLabs — DevOps solutions provider for enterprise customers. In 2014 I joined the company as a first in-house designer. I was challenged to infuse design thinking and user-centric approach into a highly development-driven culture. Low ratio of designers to developers, often switch from project to project, rush to support one development team after another, made me go searching for ways to efficient collaboration. It was an exciting journey that taught me couple of lessons, some of which I would like to share today.
When an organisation is trying to take a design driven approach to the software development process, here are two main points that I believe will have a big influence on the result:
- Allocation of User eXperience Team in the organisation
- User eXperience and Development work alignment
Let me share some of the tips that helped my organisation to be better aligned and setup an efficient sync between UX and Development departments.
Allocation of User eXperience Team in the organisation
When thinking about how to infuse User eXperience designer into the organisation to allow her/him to be most productive — there are two main models you can follow:
- Internal UX agency model
- Cross-functional model
1. Internal UX agency model — is when User eXperience team is placed in the middle of the all the other teams in the organisation. UX Team is having a role of a shared resource, rather than being dedicated to a specific feature / project. Usually, there is a UX Team Lead who will take care of building and maintaining UX backlog, that consists of design requests from all the projects within the organisation. UX Team Lead will do the prioritisation of the incoming design requests.
This model would work better the organisations that are less mature in UX — companies that are just starting to invest into their first in-house designers.
Plusses for this model:
- UX culture: team members are sitting close to each other, having possibility to rapidly discuss work. They have own team rituals, like stand-ups, plannings, retrospectives, etc.
- Focus on future: because designers are not sitting with developers who are busy with building up the features, they will have more time to look into the future features and do needed user research
- Design consistency: designers are sitting close together and constantly reviewing each others work. This gives them a possibility to be aware of every design change made and new component built
However, there are also minuses that are coming with this model of UX allocation:
- Features prioritisation: it can be challenging to prioritise UX work by it’s priority. UX Team Lead can easily fall into the trap of prioritising the requests of a Product Owner who is the most demanding, ignoring the others
- No connection to Dev team: as UX team sits apart from Development teams — it has influence on UX being isolated from actual development work. This can easily lead to the story with the house, that we have started this article with…
2. Cross-functional model — is another way of allocating User eXperience resources. This model is more often seen at a bigger organisations, where there is higher number of designers. UX team exists in the organisation, but each of it’s members is sitting within a dedicated to a project/feature Development team. There is no need in UX Team Lead to prioritise the work, but her/his role is more to make sure that User eXperience team is still behaving like one group, sharing best practices, designs updates, having UX rituals, etc.
Plusses for this model are:
- Fast reaction to a design request: because there is a dedicated designer within a Development team — it is much easier to have help with design issues that are coming up, instead of waiting for prioritisation on UX backlog
- UX involvement in Development: designers are integrated into the Development team, so they are always up to date with what is happening, sharing same goals
- UX and Dev’s focus is aligned: same as the above point — team is having a common challenge to solve. Sitting together to brainstorm and sketch using a prototyping tool can be a great help
Minuses for this type of allocation are:
- No UX team spirit: your designers are really connected to another team, so they will spend less time together as a UX group
- Consistency problems: because each of designers is busy with her/his own project — there is less possibility to talk about newly built interactions, design components, etc.
- Day to day focus: as designers are being involved into the “day to day” work with the developers — there is a big chance of giving less focus to future features and doing less user research
So — which of the two models to pick for the organisation? The answer is not surprising — it DEPENDS. Here are some general tips:
- Internal UX agency model will fit better organisations that are just starting to infuse User eXperience into the feature development process. This model works better, if you want your UX team to spend more time on doing user research and designing ahead, with not being too much involved into a day to day development work.
- Cross-functional model will work smoother for bigger organisations that already have some designers in place. It is worth trying to dedicate designers per project / feature, making sure that there is time and habits to meet as UX team (giving 1 day a week to work together to catch up would be a great start). This will allow development teams to have a dedicated person to work with, but also will keep UX rituals in place.
Read on for part two, where I will talk about second main point — UX and Dev work alignment.