InfoQ recently spoke to Michael Dubakov & Andrey Mihailenko of Targetprocess about the upcoming release of the product, and their own experiences integrating user experience into their agile development process. The first part of the interview can be found here.
This news item covers the way the Targetprocess development has integrated UX design with their agile development process used to build the product.
InfoQ: Please can you tell us more about how you apply UX in the development process you use to build the Targetprocess product.
Michael: Our UX journey started about four years ago. Initially we paid very little attention to user experience as a part of our development — we relied on the skills of our developers to define the user interface for the product. In 2009 I attended the Agile 2009 conference in Chicago where Jared Spool gave a keynote about User Experience (http://agile2009.agilealliance.org/keynotes/). This was an epiphany for me, so after the conference I decided to bring UX into our development process.
It was a learning curve for us — it took about two years for us to get to a point where we had an understanding of what UX really entails, how to really focus on people and users, and to come up with an approach which worked for our company.
Now we have a dedicated design team with three UX designers. The designers work ahead of the development teams, focusing on the features of the product. Features are implemented in two phases — an initial UX phase followed by the development phase.
In the first phase we assemble a team who will work on the feature, this is a cross-functional team led by the Feature Owner consisting of designers, developers, product specialists — anyone in the company can apply to be involved in this phase of a feature. Typically the team is 6-8 people working on the design phase.
This team takes the existing requirements, requests and ideas and works together to explore what is needed and how it could be achieved. They spend somewhere between two and three months working on the features, producing sketches and design options, using design studio techniques and building prototypes.
The team produces two or three possible solutions which we evaluate and validate with customers and internal stakeholders, ultimately selecting a final design for the feature which goes into the development phase.
The Feature Owner role is important — they become part of the development team and provide guidance and direction through the development phase.
InfoQ: Are the members of the development team involved in this design activity?
Michael: Some developers definitely want to be involved in the design phase and will do so, but not all developers are actually interested in being involved in the design activities. We encourage the developers to be involved in the design work, but do not make it mandatory. Some developers have a very technical focus and do not want to be involved in the design activities.
Within the development teams we give people lots of freedom about how they work and the approach they take, we do not mandate any specific set of practices but let the teams self-organise. Some use Kanban, some use Iterations, etc. There are some organisation-level constraints, but as much as possible we leave the decisions about how to do work to the teams.
This two-phase approach was the result of some lessons we learned.
Initially we didn’t separate the design activity from the development and we had cross-functional teams with UX embedded in the team. We found this didn’t work well for us.
To have a really great user experience you need to spend time getting to know the audience needs and behaviour, and the pace of development activities doesn’t allow for that. We encourage our developers to be involved with the design phase and this definitely helps in the ultimate delivery but not everyone wants to be engaged at that level and we don’t force them.
We have found that it takes time to truly understand our customer’s needs and come up with a design approach which will really work well for them. When we had UX as part of the development activity teams were not taking the time to truly understand the problem and the user needs, they were more focused on delivering the feature than on understanding the UX needs.
We have used this approach for two years now and have found that splitting the work into two phases has definitely resulted in better outcomes for our customers and better user experience in our product.
InfoQ: After a feature has moved into the development phase from the design phase, what happens if a new idea comes up or a change is needed to something that has been designed?
Michael: The Feature Owner role is an important one in the team. Teams are cross-functional with developers, designers, testers and other skills as needed, and the Feature Owner provides direction to the team regarding what the feature must do. Feature Owner is a role, not a job title — anyone who participated in the design phase could be a Feature Owner for a team.
We find that there are lots of small changes which are made during the development phase as we learn through the process of building and reviewing. We find that there are not many big changes needed, but lots of small changes do happen as part of the development activity.
Andrey: The results of the UX design phase has been verified with customers — working prototypes produced which our customers have looked at and found to be viable solutions for the problems they face.
InfoQ: At the end of the UX phase you mentioned you could have multiple solutions — how do you chose which one to put into the development phase?
Michael: Where there are multiple options in the design phase we will iterate and validate the possible alternatives with our customers, so that at the end of the design phase is a single solution which has been validated with our customers. We undertake usability tests and get feedback from our customers to choose the best option.
In the development phase we take a prioritised “Minimum Viable Feature” approach — delivering frequently and validating that what is delivered does in fact meet the customer needs.
This feedback does change the order in which we will implement elements of the solution and we update the backlog based on what we learn. Constant feedback loops which allow us to ensure we are building the right aspects into the feature.
InfoQ: How is the design information conveyed to the development team — what artefacts are used and how is the knowledge conveyed?
Michael: This is probably the biggest challenge we face with the process.
In some cases the whole development team has participated in the design process so there is little need for additional briefing and knowledge transfer.
Typically out of an 8 person design team two or three will move into the development phase, so there is transfer of knowledge into the design phase, not just artefacts. The Feature Owner is a key part of the knowledge transfer. The Feature Owner is a vital role and they need to have a deep understanding of what the feature is for and what the customer needs are.
The artefacts which are transferred to the development team include the working prototypes, design ideas and the various solution options, use cases, graphic design and the feature descriptions.
The team and the Feature Owner then get together in a workshop and they produce the user stories.
This is an area where we find there is a need for improvement and is one of the areas we are currently focusing on.
InfoQ: What are some of the challenges you have found or important caveats you would like to share with other organisations who are looking at incorporating UX into their development process:
Michael: Don’t be impatient! It takes time for technical people to understand the value of UX. You need to be prepared to educate and foster a culture that is user experienced focused — explaining why it has value, what the benefits are and how it can be incorporated into the development approach. This took us about two years.
Each Feature has a separate UX team, which has both good and bad aspects. The Good — many people can participate to see the value of UX on the product and gain an understanding of the customers’ needs. The bad thing is that many of those people will be inexperienced and it will be a learning curve for them, which slows down the process. You don’t want to exclude people so you need to allow them the time to learn as they are doing the UX work.
Prioritisation in development can be a challenge. You need to truly identify the Minimum Viable Product and deliver that quickly to enable real feedback from customers as quickly as possible.
Andrey: Remember that User Experience doesn’t end with the product — it needs to be consistent across every interaction between the company and its customers — that includes documentation, guides, call centres, the website — any touch point with the customer needs to be designed with the user and the way they experience the organisation in mind.