Integrating UX design methodologies into software projects

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.

Figure 1. Component teams at scale (Rubin, 2014).

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.

Figure 2. Diversity of skills in UX design.

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:

  1. Development methods
  2. Design-to-development documentation
  3. Web analytics
  4. Ethnography
  5. Social networks
  6. Marketing
  7. Technology
  8. Return on investment (ROI)
  9. Business knowledge
  10. 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.

Planning design

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.

Figure 3. Scrum activities and artifacts (Rubin, 2013).

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

Connolly, E. (n.d.). Unicorns don’t exist. Generalists do. Retrieved October 7, 2016, from

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

Rubin, K. (2013, September 24). Scrum Framework. Retrieved October 7, 2016, from

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


6 thoughts on “Integrating UX design methodologies into software projects

  1. Good article, coming from a development background I find working with a user experience team member very beneficial, Just referring back to design working one sprint ahead of the development team on a project, I felt that communication is the biggest issue here speaking from experience – this was also echoed in – Silva el al (2011) User-Centered Design and Agile Methods: A Systematic Review. 2011 AGILE Conference.

    Liked by 1 person

    1. I agree, communication is a huge factor! I’ve seen design reviews for the same piece conducted again and again due to developer misinterpretation of the UX team’s intent. This is not just their fault though – this can be due to a design team not fully considering all of the different use cases a given scenario can have, with the more detailed questions only arising once it moves into production.


  2. What is also interesting is that it doesn’t seem possible to just replicate an instance of successful integration of UX in software projects in different organisations as each case is unique. The arrangements of integration needs to be customised to suit the teams, the product and the company.

    Liked by 1 person

    1. I’ve definitely seen this – Even down to smaller modifications like sprint duration and number of team members can make a difference depending on dynamics and location.


  3. It makes sense to have both generalists and specialists however i think for some small and medium organisations budgets don’t stretch that far. And the majority of the time the generalist will get be picked over the specialist. In theory this might make sense, one person who can cover all bases (loosely) but i think organisation’s need to look at what exactly the designer will be doing. If it’s primarily a research role it might worth considering a specialist in this field, if it’s someone who will mostly be drafting up quick prototypes and wireframes in a software development company (where the focus is on quick iterations and shipping) then someone who specialises in this might be more suited. I think it’s also important to set expectation for the designer during the hiring process. I’ve often seen people been told during an interview that they will be involved in research, ideation, wire framing and testing but once they start working are only doing one of the four, which lead to job dissatisfaction and them leaving within a couple of months.

    Liked by 1 person

    1. I agree – Like Spool (2007) mentioned, there are companies that migrate away from this specialist approach both due to budgetary constraints and lack of work available. This is why I think courses in creative computing and digital media are quite popular at the moment as it produces creative problem solvers and good all-rounders with enough foundational skills in design and technology to get started in a modern software organisation, so there certainly isn’t a lack of jobs in the marketplace for these graduates.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s