There are a number of practical issues that can arise when a team is challenged with integrating user experience (UX) design methodologies into the software development process. Problems can arise due to a number of different factors:
- How the team is located and structured
- The diversity of the skill set available
- How the process is implemented
To begin, process issues can rear their ugly head over time depending on the location and structure of a UX team, thus having significant impact on the progress a of software development project.
Component versus feature teams
Today, software development teams can be typically made up of either a feature or a component teams.
The diverse nature of feature teams means they’re well suited to scaling in an agile environment – in theory they have the ability to perform all of the tasks necessary to ship a feature that’s of value to the end user from the product backlog. Having their own specific skill set, each team member has the ability to work in their own area alongside the rest of their team (Rubin, 2014).
In practice, feature teams work most efficiently when co-located. However, there are plenty of technologies available today that close the geographical barrier – the key to truly championing long-distance work is strong, informal communication channels and building a frequent routine around remote collaboration.
Unfortunately, an agile approach doesn’t scale too well for component teams that require a dependence on multiple disciplines – User stories would need to be broken down further, to accommodate the tasks that are required specifically to each team:
That which is a feature to a component team is a task to a feature team
Putting this into perspective, component teams now become teams that work in silos to produce functionality for other teams to incorporate, instead of focusing on tasks that supports the user’s needs. What happens if one team suffers a delay in implementing something? This can have a knock-on effect and delay the rest of the component teams from moving forward, as outlined in Figure 1 below.
If building out feature teams is the way to go in integrating UX design methodologies into software projects, how is it ensured that the correct range of skills are included in order to develop a polished product with a delightful experience for it’s target users?
Diversity of skills
When integrating a UX design process into a software project, one of the reasons why feature teams work so well as opposed to component teams is because they have a collective breadth of skills that are a necessity in developing a quality experience for the user.
This diversity makes sense – if a software team was to be solely comprised of engineers without any design support, you could only imagine the concerns an end user might have with the aesthetics and usability of their endeavours. Likewise, a team made up of purely designers would likely not have the skill set to optimise or structure the code nearly as well as most engineers.
Traditionally organisations would have built a UX team by recruiting individuals trained in a very specific area, but now there are companies that migrate away from this specialist approach both due to budgetary constraints and lack of work available (Spool, 2007).
Intercom believe that both generalists and specialists are essential in building a UX team (Connolly, n.d.), and Figure 2 below illustrates the breadth of skills available. This is something that rings true for many UX teams – While it’s important to have generalists that have a basic understanding and an ability to perform some of the more traditional UX day-to-day activities (information architecture, user research, interaction design, etc.), there will always be a need for specialists with a deeper familiarity of the domain and infinite more years of experience, that can bring with them a mastery of knowledge onto the team.
Spool (2007) deems that the eight more traditional UX skills are absolute necessary in order for a team to deliver the best possible experience for the user. However, he also discusses the importance of ‘enterprise UX skills’. These include:
- Development methods
- Design-to-development documentation
- Web analytics
- Social networks
- Return on investment (ROI)
- Business knowledge
- Domain knowledge
Speaking from experience, these skills are just as valuable as the more traditional UX skills – As a designer in an organisation with roles varying from executives right down to sales, in order to effectively be the voice of the user amongst a sea of people who don’t speak their language, the above skills are vital in ensuring a UX team can remain both productive and heard.
Finally, in ‘Building the UX Dreamteam‘, Colfelt (2007) discusses some of the skills that he believes make up a UX team. In the article, he also claims that skills are measurable and that anyone that can learn them through education and practice – this is true. Many get hired on to a UX team for their knowledge and skill sets in areas like front end development or graphic design, but can end up wearing many hats or growing into roles they’re not formally trained in, like design research.
Having gathered the right breadth of skills for a UX team, how is it made certain that they can all work together towards the same common goal? This can be achieved through following some loose practices for delivering software.
The traditional non-iterative, prescriptive, waterfall design process is slowly being shelved in favour of agile workflows like Kanban and Scrum.
As described by Ken Rubin (2013), frameworks like Scrum are not a standardised process like the waterfall model – it’s a framework that provides the flexibility for organising and managing work on a team, based on a set of values, principles, and practices.
In order to facilitate any process like Design Thinking, Kanban, or Scrum, it’s necessary that the entire team be on board, otherwise it can cause issues. Ede and Dworman (2016) discovered this on a much larger scale, in how internal company processes and executive decisions significantly impacted the design work they trying to do. In a large organisation, it takes the buy-in of an executive for monumental change to trickle down to the floor – it’s very rarely that this organisational change comes from the bottom up.
Maedche and Werder (2015) discovered that a limited upfront design effort is necessary to provide a consistent design concept from the beginning of a project. This establishment of a user-focused product strategy, and separation of product discovery from product creation also promotes stakeholders from all disciplines to be continuously involved with design early on before any delivery begins, providing investment, ownership, and valuable feedback contributing towards it’s overall vision. Without design upfront, projects are essentially started blind, without mitigating poor design judgements, usability problems, and inaccurate work estimates (Salah, Paige, & Cairns, 2014).
Goal synchronisation and alignment between design and engineering is also vital in order to maintain velocity. A shared understanding of the design vision prevents animosity and improves coordination (Salah et al., 2014). From experience, liaisons in attendance during other disciplines’ stand-ups allows for clarification of design language and intent, and visibility into work. The concept of design and development working in parallel during delivery is also discussed, where a design team effectively works one sprint ahead of the development team in order to realise the development team’s future activities (Maedche & Werder, 2015). For this to succeed, synchronicity needs to exists across both teams, while also ensuring that the team is well-equipped with the resources and skills to maintain this parallelism, otherwise a situation may arise where one team lags behind the other and product momentum is reduced.
Tight sprint deadlines also increases the workload for the design team and UX practitioners – Meetings and frequent context switching reduces productivity in individual designers hoping to accomplish evaluation tasks, which sometimes end up defaulting to peer-reviewed heuristic evaluations. It appears there’s been some success in accounting time for these tasks by dedicating iteration cycles for working on this alone (Salah, Paige, & Cairns, 2014). From experience, the most problematic usability issues need to be understood and resolved early on during product envisioning, before it requires a large development effort to resolve.
The production of concrete artefacts and documentation should also be kept to a minimum during product discovery (Maedche & Werder, 2015) – Since nothing is set in stone, everything should be considered throwaway until the design team is on the right trajectory, moving gradually from low to high fidelity as product assumptions have been validated by the team’s stakeholders – where this can cause some issues to arise is on geographically dispersed design teams, where important decisions need to documented and communicated clearly in order to prevent remote team members from falling behind. There also needs to be a balance as to what is documented – while aggressively documenting is considered waste during envisioning, there are certain artefacts (personas, sketches, wireframes, etc.) that should be documented in order to illustrate the design team’s progression (Salah et al., 2014).
Bringing together design, engineering, and offering management efficiently is no simple task – this blog post aimed to outline the practical issues that can arise from integrating UX design methodologies into the software development process. As outlined, it takes a balance of planning, team structuring, and strong communication at frequent touch points in order to keep it running smoothly.
Colfelt, A. (2007, November 28). Building the UX Dreamteam. Retrieved October 7, 2016, from http://boxesandarrows.com/building-the-ux-dreamteam/
Connolly, E. (n.d.). Unicorns don’t exist. Generalists do. Retrieved October 7, 2016, from https://blog.intercom.com/unicorns-dont-exist-generalists-do/
Ede, M., & Dworman, G. (2016). Why Designers Might Want to Redesign Company Processes to Get to Better UX Design – A Case Study. Proceedings of the 2016 CHI Conference Extended Abstracts on Human Factors in Computing Systems – CHI EA ‘16, 840-848.
Maedche, A., & Werder, K. (2015). Exploring Principles of User-Centered Agile Software Development: A Literature Review. Information and Software Technology (61), 163-181.
Rubin, K. (2014, April 9). Distinguishing Between Feature & Component Teams. Retrieved October 6, 2016, from http://www.innolution.com/blog/distinguishing-between-feature-component-teams
Rubin, K. (2013, September 24). Scrum Framework. Retrieved October 7, 2016, from http://agileatlas.org/articles/item/scrum-framework
Salah, D., Paige, R. F., & Cairns, P. (2014). A Systematic Literature Review for Agile Development Processes and User Centred Design Integration. Proceedings of the 18th International Conference on Evaluation and Assessment in Software Engineering – EASE ‘14.
Spool, J. M. (2007, December 10). Assessing Your Team’s UX Skills. Retrieved October 6, 2016, from https://articles.uie.com/assessing_ux_teams/