Exploring organisational competences in Human Factors and UX project work: managing careers, project tactics and organisational strategy

Abstract Organisational competence in Human Factors and UX (user experience) has not been looked at before despite its relevance to project success. We define organisational competence as the collective competence of the individuals, bringing together their complementary abilities to deliver an outcome that is typically more than the sum of its parts. Twenty-two UX and Human Factors practitioners were interviewed about their project work in two contrasting domains: web design and safety-critical systems to explore organisational competences. Through doing a FRAM analysis, 29 functions and 6 main areas of competences were identified: the central project process; the process of learning about the problem; maintaining and developing client relations; staff development; evolving practices; and the management of documentation for audit and quality control. These dynamic and situated competences form a web of interactions. Managing competences is essential for project success. Implications for managing careers, project tactics and organisational strategy are discussed. Practitioner Summary: Organisational competences impact how routine and non-routine project work is performed, but these have received little attention in the literature. Six key areas of competences in Human Factors and UX project work were identified from practitioner interviews. Managing combinations of adaptive competences is important for developing careers, project tactics and organisational strategies.


Introduction
At the heart of ergonomics is a systems thinking perspective that includes a systems focus, a concern for context and recognition of the emergent properties of systems (Wilson 2014). As a community, we are used to applying this perspective to others' systems of work but rarely use the same perspective on our own work. By understanding ergonomics and human factors (HFE) and usability and user experience (UX) practice, organisations are more able to resolve gaps and deficiencies, and to enhance areas of advantage. This paper identifies the situated and dynamic interactions between organisational competences necessary to perform HFE and UX (HFE/UX) project work effectively.
The terms 'competence' and 'competency' are generally used interchangeably but the latter has a more specific meaning . A competency is defined as: 'a performance capability needed by workers in a specified occupational area. Competencies may be cognitive, attitudinal, and/or psychomotor capabilities. A competency does not imply perfection: it implies performance at a stated level (criterion)' . (Hermann and Kenyon 1987, l). Competence is more often used to describe a person's general ability, and is used here to capture situated, dynamic and holistic approaches to this area. In addition, meta-competences are differentiated as higher order abilities to learn, adapt, anticipate and create (Brown and McCartney 1995).
We define organisational competence as the collective competence of the individuals involved in a project, bringing together their complementary abilities, to perform a function or a set of functions that is typically more than the sum of its parts. Indeed, a functional analysis is important for identifying what has to be done in a job (Eraut 1998), and competences determine how well those functions are conducted. Taking a contemporary approach, FRAM (Functional Resonance Analysis Method) (Hollnagel 2012) was used to identify critical system functions, explore how these functions interact, and reflect on their individual and collective performance variability. The goal of this study to competencies include that they are abstract, narrow and oversimplified, too focused on the individual and independent of context (Le Deist and Winterton 2005). In contrast, competences can be considered differently: 'constructivist and interpretative approaches derived from phenomenology view competence as a function of the context in which it is applied, where "worker and work form one entity through lived experience of work"' (Sandberg 2000, 50).
Few studies have explored competencies of HFE practitioners from a research perspective. Work on understanding HFE practitioners includes exploring their confidence in possessing the IEA competencies (Williams and Haslam 2006) and their knowledge, skills and abilities (Dayton 1993;Williams and Haslam 2011). These latter studies highlight the wider repertoire of activities involved in HFE project work: for example, applying core HFE knowledge, communication and negotiation, project management, learning and adaptation. Some skills typically come from formal schooling and others from practical experience.
More recent work in UX has led to a more fluid and situated conception of competences (Gray 2014;Gray, Toombs, and Gross 2015). Gray (2014) analysed the evolution of competences as UX students became embedded in the workplace. Here, the diversity of practice (e.g. in tool use, design processes, client exposure, type of work) would influence the construction of their competences. Hence, new practitioners co-constructed their identity within their work environment. Building on this and focusing on UX adoption in companies that have a limited or no UX culture, Gray, Toombs, and Gross (2015) proposed a conception of the 'flow' of competence between individual practitioners and organisations, i.e. how an individual can affect a group, and how a group can affect the individual. This can impact competence building in both directions.
Having lists of competencies for certification purposes resonates with HFE approaches, while exploring competences as practitioners' grounded activities resonates more with the dynamic and fluid approach in UX. Most of the HFE/UX research on competencies and competences is individualistic. Ashworth and Saxton (1990) criticise perspectives on competences that are excessively individualist, and point out that competences should instead reflect the capabilities of teams and groups. Organisational competence is not new, e.g. models to analyse organisational competence and capability examine things like resources, assets, processes and performance outcomes (Lewis 2003;Vesalainen and Hakala 2014). As far as the authors are aware, no research has looked at HFE/UX competences at the organisational level. Different HFE/UX organisational competences influence how they respond to routine and non-routine project work. was not to construct or prescribe a simple linear causal chain of how to conduct a good HFE/UX project. Instead, the goal was to describe a set of conditions (potential competences in this case) that could play out in complex, situated and sometimes unanticipated ways that influence whether the HFE/UX project work stalls or flourishes (Furniss, Curzon, and Blandford 2016). Essentially, the organisation's competences impact how it responds to different scenarios. Managing combinations of competences can impact individual careers, project tactics and organisational strategy.

Background
The management of competencies in the HFE community has been dominated by international and national standards for accrediting educational courses and certifying professionals. For example, the International Ergonomics Association propose evaluating applicants against a list of competencies 'to ensure that they are competent to practise as an ergonomist and can demonstrate an appropriate standard of professional performance' (IEA 2001a). They detail a comprehensive hierarchical list of the core competencies required to perform the role of a professional ergonomist, which is divided into units, elements and performance criteria (IEA 2001b). In 2015, the Institute of Ergonomics and Human Factors received a Royal Charter to award the protected status of 'Chartered Ergonomist and Human Factors Specialist (C.ErgHF)' which has intensified the importance of these competencies in the UK.
In contrast, the UX community do not have a definitive set of competencies (Gray 2014;Gray, Toombs, and Gross 2015). This might be in part to do with the diverse mix of skills and roles that make up the community, making it challenging to identify an agreed set of competencies. Also UX is relatively new compared to HFE, and does not have the historical antecedents with health and safety. Here, safety-critical industries necessitate competencies to prevent loss of life and ensure quality and safety standards. Dul et al. (2012) draw attention to the need to strengthen the application of high quality HFE, and refer to the role of accreditation and certification bodies, which base their work around competencies, to develop the discipline and profession.
Traditional notions and hierarchies of competencies have a practical purpose; however, it 'is open to complaints that it is atomistic, individualistic, and unable to cover all types of relevant behaviour or mental activity' . The charge here is that it does not do justice to situated and dynamic notions of human activity Eraut 1998;Le Deist and Winterton 2005). Criticisms of rational approaches

Research focus
The research focus is on the ability of a HFE/UX system to competently respond to different projects. This system is loosely defined as the elements that interact to complete HFE/UX project work. For example, the internal system involves a project plan, resources, HFE/UX practitioners, tools, methods and reporting practices; and the external system involves a client, their resources and the issue they are trying to address. However, the analysis presented below focuses on functions, i.e. what a system does rather than the parts it is composed of. Addressing clients' needs through the planning and delivery of HFE/ UX project work will be influenced by how the individual functions are performed and how they interact. By focusing on competences as the ability of a system to perform a function or a set of functions well, this research offers a novel perspective on the organisational competences involved in how a HFE/UX system responds to different projects.

Research question
What role do organisational competences play in the conduct and outcome of HFE/UX project work?

Data collection
Semi-structured interviews were conducted with each participant; each lasted about an hour (N = 13, Mean = 64 min, SD = 14 min). The interviews covered broad aspects of the participant's work. The interview topics are presented in Table 1. Each interview followed a different trajectory because interviews were conducted more as conversations than as question and answer sessions, so the specific detail of the questions and probing, and the route through these topics, changed. Furthermore, the specific questions and discussion in each interview built on learning and insights from earlier interviews, as data gathering and analysis were iterative. Each interviewee gave their consent to have the interview audio recorded. Interviews were transcribed verbatim.

Study participants
Interviews were conducted with UX practitioners involved in the design and evaluation of interactive systems like websites, kiosks and mobile phone apps; and HFE practitioners involved in the design and evaluation of safety-critical systems, e.g. in transport, energy production and health care. In total 22 HFE/UX practitioners were interviewed -see Tables 2 and 3, respectively. Nine UX practitioners had an average of 7.6 years (SD = 7.5 years) of industry experience. Thirteen HFE practitioners had an average of 11 years (SD = 9.7 years) of HFE industry experience; this excludes HFE4 who reported experiences of a human factors project but did not identify as a HFE professional. UX practitioners participated before HFE practitioners. This was purposeful in that an aim was to have different and contrasting domains to broaden the empirical base and challenge emergent results. It was convenient in that the authors had more links to UX practitioners, so that community was easier to engage with first.
Within each domain, less experienced practitioners were interviewed first to build up to participants with more experience. This was convenient because less experienced members were easier to recruit. Also, an aim was to maximise the value of time with more experienced practitioners, i.e. a lot was already learnt by the time senior people in the community were interviewed. These heuristics were broken if it was convenient for a practitioner to meet. Practitioners were not compensated for the time spent during the interview.

Analysis
Functional Resonance Analysis Method (FRAM) (Hollnagel 2012) was used to analyse interview data (Furniss, Curzon, and Blandford 2016). This built on qualitative data analysis that was conducted as the interviews progressed . FRAM provides a way to perform a detailed analysis of how different functions interact in a complex sociotechnical system. FRAM was originally designed for analysing risk and accidents but it can be used outside the safety domain for examining how systems flourish and stall (Furniss,   in-house practitioner for ecommerce site in the gambling sector with extensive experience at a full-service agency. more often than not they now outsourced usability work which they oversaw rather than do it themselves 50 UX7 E 12 manager and practitioner at a full-service agency that had experience of a wide variety of usability methods and engaged with information architecture issues 70 UX8 F 16 manager and practitioner at an independent usability consultancy with extensive experience in nurturing colleagues, negotiating on the client-side and performing a full range of usability design and evaluation services 54 UX9 g 22 manager and practitioner at an independent usability consultancy with extensive experience in international projects 63 main input and output links rather than the other aspects. • The validation exercise had some upstream influence on the analysis, i.e. we needed the functions and the six areas or networks to be intelligible to people unfamiliar with FRAM or the analysis. This changed the use of the method from one that was purely about analysis to one that was also about communication.

Validation
Following the FRAM analysis, practitioners were invited to review the resulting model by responding to a summary of the functions and subsystems via email. A summary of the FRAM analysis that includes the practitioners' responses to the validation exercise can be found in Appendix D of Furniss (2008). Feedback was received from 10 of the 22 participants in the study and from 8 practitioners who were not involved in the original interviews. Feedback showed broad support for the results. More specific feedback reflected variability in practitioner work; e.g. some did not judge auditing to be a significant part of their work whereas others did, and some said they were not supervised by senior staff whereas others were. Some thought the overall model was too complex, whereas others thought there was not enough detail. Despite these differences, overall, practitioners agreed that the description was accurate.

Results: six areas of competences in HFE/UX project work
The FRAM analysis identified 29 functions and 6 functional networks, which can be found in Appendices 1-7. The functions are listed in rough chronological order across a project life cycle. They are numbered to provide a consistent reference for them across lists and network diagrams. However, not all relationships are simple linear ones and functions may not always appear with numerically adjacent functions in the networks, so this numbering system is arbitrary in places. The following section provides an overview of the integrated areas of competences, summarises the results about each area and lists the key functions identified in each area. The descriptive results below are drawn directly from the data in the interviews.

Overview of the six integrated areas of competences
Six integrated areas of competences were identified that play a role in the emergent performance of HFE/UX project work: Curzon, and Blandford 2016). The detailed steps that we went through to apply FRAM are documented in Furniss, Curzon and Blandford (2016). The contribution of that paper is methodological, i.e. the application of FRAM outside a safety context, to see how sociotechnical systems can flourish and stall. Whereas the analysis of that paper focused on how HFE/UX methods are applied within a system of HFE/UX practice, the analysis of this paper focuses on the system of HFE/UX practice itself. FRAM helped us explore how functions (i.e. something a system does) involved in HFE/UX project work interacted, and how competently these were performed to influence project processes and outcomes. Organisational competence was identified as a key concept for explaining how well this system was able to respond to different projects. Building on our qualitative analysis, coding, reviewing transcripts, brainstorming, memos, sketching, network diagrams, PostIt notes and the FRAM Model Visualiser (Hollnagel and Hill 2015) were used to develop a list of functions and how they were related to each other. This resulted in six interrelated areas of competence described below. Key methodological points to note for the application of FRAM in this context, which are expanded upon in Furniss, Curzon and Blandford (2016), include the following: • The performance variability of functions and sets of functions focuses less on how events can compromise safety margins and spiral out of control, and more on how they impact effectiveness and how a system might flourish or stall. • Performance variability of each function was considered alongside 11 context-dependent common performance conditions (CPCs). However, the key conditions were only highlighted because the analyst anticipated poor benefits for the costs of grading all 11 CPCs for each of the 29 functions. • Performance variability between each function was considered by linking the six aspects of each function, guided by the empirical data, with one another. The six aspects are: input, output, precondition, time, resources and control (see Appendix 8 for graphical representation). These were first detailed for each individual function through a template form. This process led to the recognition of new functions, e.g. the control function alluded to the supervisory mechanisms of senior HFE/UX practitioners. We used the FRAM Model Visualiser (Hollnagel and Hill 2015) to represent these links graphically. At first, this was unintelligible due to the density of links. This meant that rather than aiming for a comprehensive FRAM model with all the links, we needed a simplified model that was intelligible and aided analysis. This meant that some resultant models focused on the • develop work packages to satisfy the client's need while being creative, efficient and effective in their use of resources (see Appendix 1: Function 3); • negotiate a project so that it fits within resource constraints, addresses the client's need and suits that particular project context (see Appendix 1: Function 4); • conduct project work that fulfils the project plan (see Appendix 1: Function 13); • analyse data appropriately (see Appendix 1: Function 18); • write a report on the project work (see Appendix 1: Function 21); • communicate results to the client (see Appendix 1: Function 22); and to • facilitate the client's consideration of the results and how to act on them (see Appendix 1: Functions 25 and 26).
The details of these interrelated functions begin to build a complex picture of what is involved in HFE/UX project work, and the sorts of competences needed to successfully navigate this space. For example, fulfilling the aim of the project drives its purpose and methodology; however, 'the aim' can be ambiguous and complex. As an illustration of this, one practitioner reported that sometimes the biggest task is to work with clients to figure out why they have come to them and how they can help. Another reported addressing the project requirements as presented by middle management at a company, who were very happy with his work, but subsequently the director 'hated it' because it conflicted with business objectives. This illustrates some of the complexities of working with organisations where different factions have different understandings, conflicting goals and different responsibility and power. Also, the real aim is not always the prima facie technical work the practitioner is employed to do: one experienced practitioner reported realising that the technical work he was doing was secondary to his role as an agent for organisational change.
HFE/UX practitioners can be restricted by client budgets and willingness to invest in HFE/UX. For example, practitioners who would like to do 'gold standard' projects that involve them from start to finish are often restricted by the resources clients will spend and the pragmatics of the situation. They therefore have to be creative, efficient and effective in their use of resources: there's realities for times, budget and […] users, and sometimes those things play off against themselves and when you design a research project you've [got to think of the options], if we do this that lowers the cost; the effect might be a certain lack of robustness in this particular area […], or if you're having trouble getting users of this variety we could use this parallel group of users and change the methodology in such and such a way. UX8 (1) Conducting the central project process is a stepwise view of project work; (2) Analytic insight and project understanding revolves around insights and understanding about the current project; (3) Enhancing persuasion, rapport and reputation involves non-technical and social aspects of project work and delivering results; (4) Managing staff development and supervision involves developing expertise, knowledge and experience in the longer term and quality management in the project; (5) Selecting tools, methods and reporting practices concerns the development of different types of practice; and (6) Managing documentation involves archiving and using project documentation for reference and auditing purposes.
These functions form an integrated web rather than a hierarchy. Background functions in one network are foreground functions in other networks: e.g. the functions in the central project process have elements of all the other functional networks influencing and being influenced by it. Also, key functions can have reverberations around the whole system: e.g. developing staff (see Appendix 1: Function 11) will impact on how well they conduct project processes; the insight they develop; how effective they are in building rapport and convincing the client; how they support and interact with other staff; the tools, methods and reporting practices they can competently use and their documentation practices. Other significant cross network links include: conducting project work affecting insight and understanding from that work; project understanding influencing how persuasive the practitioner can be; auditing and supervising work affecting the reputation of the practitioner; and the evolution of tools, methods and reporting practices impacting how practitioners choose to conduct their projects. Here organisational competences are not listed as detached entities but are more conceived as a web of functions that are coupled to each other in multiple ways.

Conducting the central project process
The central project process is quite linear, with many goals and activities following on from one another. The more competently each function is performed, sometimes starting with helping the client to recognise and articulate their need, the more chance there is of project success. Other key competences in this area include to (see Appendix 2 for functional network diagram): • develop an understanding of the client's need (see Appendix 1: Function 2); Some methods afford more direct engagement with the client, which bridges over to the themes of persuasion and rapport in the next section. Taking a more longitudinal view of project work, there may be cycles of understanding and discovery as work packages build iteratively on one another and methods are used consecutively within and between projects. This makes the history of a project or relationship important, which can be overlooked if one is too focused on individual projects.

Enhancing persuasion, rapport and reputation
Persuasion, rapport and reputation provide the focus for the third group of competences. In the central project process, the practitioner has to persuade the client when negotiating an appropriate project and resources, in using appropriate methods, and in communicating the results (and implications) back to the client. At each of these points there is an opportunity to build rapport, which could impact persuading the client. The client evaluates this work, and sometimes it is externally audited, which can affect the practitioner's reputation. The main competences in this area were being able to (see Appendix 4 for functional network diagram): • negotiate and convince the client effectively (see Appendix 1: Function 15); • build, manage and communicate one's reputation effectively (see Appendix 1: Function 27); and to • develop rapport with people quickly and effectively (see Appendix 1: Functions 28).
Whereas rapport is about the relationship between people (including being friendly, helpful and supportive), reputation is a measure of past success (including being perceptive, knowledgeable and competent). The reputation of the practitioner can affect their ability to persuade the client and be an asset for organisational performance, e.g. being an authority in a particular domain: [This person] is very very good with financial clients, […] he is just very knowledgeable about that industry, so he has come over and led some projects for us. UX9 A reputation could be attributed to both practitioners and methods, as both develop stature over repeated successes. This builds a solid portfolio of work that could help gain further work in the future. Practitioners also need to protect their reputation and so might be averse to risks like trying untested methods.
As noted above, HFE/UX practitioners are constrained by budgets. Short-term budget losses could be played off in the hope of winning more work in the longer term, which demonstrates business acumen: let's do a gold standard job on this, let's use this new tool and it will really impress the client, which is good for us To illustrate the cascading interactions between functions in the central project process after any particular methodology has been applied, it affects the project work, analysis, report writing and communication to the client further downstream: in terms of time, resources, the type of data collected and analysis done, what insights are developed, and how findings are reported.

Developing analytic insight and project understanding
While the central project process focuses on fairly linear steps of the project, there are surrounding competences that feed into understanding project and domain issues. The main competences in developing analytic insight and project understanding form an interdependent triad to (see Appendix 3 for functional network diagram): • build an understanding of the project and domain issues (see Appendix 1: Functions 19 and 20); • conduct project work that fulfils the project plan and use methods effectively (see Appendix 1: Function 13); and to • analyse data appropriately (see Appendix 1: Functions 18).
Each of these competences pulls the other up in a bootstrapping mechanism, e.g. understanding of the project and domain issues is a pre-requisite for selecting and conducting appropriate methods for data gathering and analysis, and analysing the data will lead to a better understanding of the project and domain issues.
Methods for data gathering and analysis are a means to an end: namely, delivering insight and understanding (Bansler and Bødker 1993). Methods must be chosen to provide leverage on the issues a client faces (Blandford et al. 2008) within the constraints of the project. For example, workload methods should be chosen for workload problems, and analytic rather than empirical methods may be selected if the project is fast and cheap.
However, understanding issues generally starts long before methods are selected and any data are analysed. For example, understanding the client need shapes what methods are proposed. In other words, the practitioner needs to anticipate issues and develop some understanding of the project to devise appropriate units of work. However, methods and work packages might be constrained by the goals and interests of the client.
Further downstream in the project process, conducting the work has two main effects. The first is on the practitioner's understanding of specific project issues and more broadly the methods and domain. The second is on the client's or developer's understanding. Communicating new insights and understanding commonly takes the form of a written report, often accompanied by a presentation. I've done a lot of work on the way we report, and I've come up with a report structure that meets the needs of the different audiences for that report whilst making us money. [The report template is streamlined to suit my working practices, it has different sections for different audiences like a summary and screen shots for people wanting the high level messages and a detailed section for people that need to implement changes at the back, and it looks pretty so clients can use as the presentation themselves within their own organisation.] That's how I can write reports so quickly but can achieve a high quality of results because as much of it as possible is standardized process of writing it is as fast as possible but also it meets the needs of those different user groups as well, and it goes down very well. UX5 Experiencing the complexities and nuances of practice leads to staff development in the longer term. The more the staff develop, the more competently and confidently they perform routine and non-routine project work. For example, participants referred to the patterns of thinking they had built up over time: Once you've been a consultant for two years you may have worked on three or four retail sites, three or four services sites, and if you keep on websites you will encounter the same problems, like what does the contact page look like, so you are repeating applying the same knowledge to a version of the same sort of thing … UX3 a lot of your thinking is pre-done, you've automated that thinking in some sense because you've seen these types of patterns before. UX5 From a project management perspective, expert practitioners are able to perceive variability, opportunities and threats, and know how to respond appropriately. Where novices 'see' noise in the context, in evaluating the situation and their options, experts 'see' greater clarity in the past, the present and what they anticipate will happen in the future. For example, a novice might be confused by the bewildering array of methods available to them, but a more experienced practitioner might immediately recognise the core work packages needed and optional activities depending on the budget and circumstances of the project (i.e. relevant patterns of project work are readily available to them).
In some organisations, senior practitioners supervise more junior practitioners and play a role in guiding the work and quality management for the project, but also in mentoring and guiding the development of the practitioner. Projects may be selected strategically for developing the competences of practitioners and the organisation in the longer term, rather than optimising for an individual project's outcomes in the short term. This could include giving a practitioner a development opportunity in an area they are not used to, or involving an organisation trying something novel to break into a new market. in the long term. But we may think 'no we haven't got the budget' , but this would be really good in terms of human factors, this will prove our argument, it will strengthen the case for our recommendations, […] we've deliberately gone in on the project under budget in an attempt to win the client for future work. HFE10 Different methods can be exploited for their non-technical characteristics. For example, methods that encourage observation or participation can build rapport; or if a situation calls for a lot of persuasion, practitioners may choose a method that gives direct access to user views, e.g. through workshops. Videos, quotations and observations of users can also be persuasive if used appropriately. The competent practitioner will know these points of leverage and use them to their advantage. This helps facilitate the smooth running of the project.
In terms of persuasion, experienced practitioners were aware that different audiences are motivated by different values, and that these should be engaged with to get a good response; e.g.: it's knowing which people to talk to, because I could sit and talk to a mechanical engineer and I could say, what about this, it's a real risk if this person makes this mistake, [but] it's not his job, he doesn't care.
[…] he wants to know about that risk because he is going to have to spend x amount of time and money investing in a new design solution. HFE10. This is more than just communicating clearly: engaging with values includes getting people to react to what you are saying because it is something they are responsible for or care about. Nørgaard and Hornbaek (2009) discuss this in terms of conveying an understanding of the problem and convincing developers to respond to it.

Managing staff development and supervision
Managing the people in the process is a critical area of competence because staff design, negotiate, conduct and communicate across all areas of the project. How competently they respond to project work will depend on their experience and expertise in the domain, the methods, and managing different projects and clients, which will shape how they approach and understand projects. The key competences in this area relate to developing staff (see Appendix 1: Function 11) and overseeing project work (Appendix 1: Function 12) (see Appendix 5 for functional network diagram).
Staff will be more competent in applying, and more likely to select, methods they have expertise in. Using a method will further develop their expertise in that method: it will enhance how they see its application, their adaptation of it for the context, the speed and proficiency of its application, and their communication of the method and its results to the client. Staff may reflect on their own practices, beyond methods, so they can be developed and improved. and provides stability and resistance against risk. However, there is a balance to be struck between a stable predictable system, and one that is dynamic and adaptable. For example, practitioners also conveyed how they seek to diversify their business and project work, learn new working practices from new staff, develop tools and reporting practices, and adopt new tools and methods.
we saw this one really cool information given by an [X] guy about trying to standardize usability measures, and they had this really interesting idea and then she went back and she tries it, now if she tries it and it works well then she'll tell her colleagues and they'll tell their colleagues, and it percolates up that way very often. UX2 Learning more broadly is demonstrated when practitioners face some non-routine and new form of variability they need to adapt to, which can involve exposure to new working practices and domains. The following quote illustrates a practitioner's recognition that they have to develop new practices to synchronise with architects who frequently suggest new design requirements: […] in the last two years we've done quite a lot of work with architects, […] they […] churn out so many designs a day […] we're slowly building up the relationship of how to work with architects, what's the best way, and how we can get them to understand what we do, and how we can understand what they do, working together and how we can produce something of benefit, of value, that's a good example of where you get requirements creep up at any time. HFE8.
Methods are selected for their suitability to address particular problems, and for their non-technical affordances such as building rapport and persuading clients. Choice

Selecting tools, methods and reporting practices
Practitioners choose a configuration of tools, methods and reporting practices suitable for the project. These options evolve over time, as does the practitioner's ability to create appropriate configurations for different situations. Often HFE/UX practitioners and organisations will specialise to some degree, e.g. through a repertoire of knowledge, techniques, methods, service offerings and domain. This not only shapes their response to different projects, but will also shape the sorts of projects they will respond to (see Figure 1 for two contrasting ecosystems that HFE practitioners can inhabit).
The main competences in this area relate to developing methods, tools and reporting practices (see Appendix 1: Functions 7, 9 and 16) and selecting them (see Appendix 1: Functions 8, 10 and 17). These link to core elements of the central project process like negotiating the project, performing the project and writing the report (see Appendix 6 for functional network diagram).
There is a cycle between doing, developing and supervising that reinforces practice, which leads to inertia in trying new tools, methods and procedures but stabilises the system. For example, junior members will typically be advised on what to do and how to do it. This prescription will be based on experience of supervising staff. As junior members develop, they become more accustomed to working in the prescribed manner, and are given more responsibility. As they gain seniority they, in turn, advise more junior members on what to do. The cycle of supervision, doing and developing which reinforces practice both creates inertia to new tools, methods and practices,

Summary of the interview with HFE1
Here design solutions were driven through iterations with input from people with knowledge of the products and working practices, rather than the specific identification of safety issues through evaluative methods. Much of the communication is captured in design drawings and so documentation is in pictures and notes rather than wordy reports. Even though he works in-house he still has to sell his ideas and services, and face the same issues of not being involved or being involved too late that out-house people face. The designsolution focus forces them to engage with the real trade-offs. He applies patterns through analogical reasoning to aid the design process, i.e. he is familiar with reoccurring issues that inform designs.

Summary of the interview with HFE2
This interview contrasted with solution focussed consultancies in that it was quite formal, independent and research driven. Rather than taking a design orientation the work appeared to be very evaluative, a lot of it taking the form of controlled experiments where safety could be independently evaluated. Reports were written in a similar way to research reports that you might find in academia. Written communication seemed to dominate client contact so an audit trail was maintained and misunderstandings reduced. The rigor of their research and independent status characterise the company's offering. Often they do not know what happens to their results and subsequent designs as they are detached from the process. Expert panels and discussion groups were recognised as useful methods for tapping into domain expertise. solutions and design proposals can be used to advantage when faced with similar scenarios. This resource can be valuable for organisational memory (Perry, Fruchter, and Rosenberg 1999) as past work is used to make current projects more efficient and effective, this can directly impact organisational competence: We  Not all organisations value auditing process and some who are focused on outcomes find the administration involved in keeping detailed records a hindrance. However, some contexts and clients necessitate the ability to audit for quality control. Depending on the circumstances of the project, there may be more or less need to produce documentation, and sometimes a mixed approach is necessary. This means not only responding competently to a project but making aspects of that competence evident where it is required.
I think what we're going to try and do is bear in mind is that the [Health and Safety Executive] will be reading it, so they need to see the methods we used, and they need to know what we've been looking at. But [at] the end of it will be the recommendations and that's the only bit that the […] company will care about, they don't care how many interviews we did, who we spoke to or what we asked. They just want to know how is it going to be resolved, how much is it going to cost them and that sort of thing. So it depends who is going to be seeing it. S3 Documentation influences upstream and downstream processes in project work. For example, upstream to project work commencing, practitioners in a formative context where a design team would like fast input into their processes might plan to produce limited documentation; in contrast, practitioners who expect to be audited might plan to document the details of rigorous methods. Furthermore, practitioners may work for a company that has great resources on using and reporting using method A but little help in using method B, which impacts their choice. Downstream the kinds of data gathered will shape reporting; e.g. graphs, statistics, video edits and quotations. This also impacts what is archived for reference and auditing. Some practitioners reported creating different documents for different audiences from the same project work, e.g. something quick and informative for managers, detailed for technicians and more process driven for people who may audit the work.

Discussion
Through the functional analysis of HFE/UX work, six areas of organisational competences were identified that account is constrained by the knowledge and abilities of the practitioner, the resources available such as time and access to users, whether they have appropriate tool support and how those tools integrate with reporting practices. These and other factors contribute to practitioners' 'local rationality' (Dekker 2002) that determines why a particular approach was chosen; e.g. learning an approach at school could influence whether it is chosen.
Appropriate tools should be employed to facilitate HFE/UX work. This can differentiate offerings by adding something novel (i.e. extending abilities -like having a high spec driving simulator or specialist software to design a control room), or speed up work and improve its quality, thereby reducing its cost and improving the output for the client (i.e. enhancing abilities -like having specialist software to perform workload calculations). Tools can facilitate method use, save time by processing data, help communication by representing data and facilitate persuasiveness, e.g. by making video clips of users more accessible. Where tool support is missing, poor or cumbersome, alternative methods may be selected; where tool support is exceptional it can attract work.
Here the joint human-tool system impacts organisational competence.
Reporting processes should be timely, persuasive, clearly communicate crucial aspects, and make it clear how the client can exploit the results. Results should be tailored to the audience, or the audience should be tailored to the results: i.e. communicate to people who are in a position of influence who care most about the consequences of issues in a way they will understand. Reporting can include extensive documentation for auditing purposes. Methods can impact the speed, detail and format of reporting.
Practitioners can also be resourceful and reflective in developing their own tools, methods and practices to suit demands in different contexts. Adaptability of the system can be maintained by tweaking and developing methods, practices and procedures. In terms of managing variety, establishing standard methods, practices and procedures can increase system stability.

Managing documentation and auditing
The sixth area concerns documentation for reference and auditing purposes. The main competence in this area was developing a paper trail of project work (see Appendix 1: Function 14), which is linked to many different activities in the project life cycle (see Appendix 7 for functional network diagram).
The documentation of rationale, methods, results and other project work can be reused for future projects. For example, presentation slides can be reused in pitches, project reports can be used as templates, and project or softer elements of the system that influence emergent performance in the conduct of work and its outcomes has been highlighted. This includes things like rapport, persuasion and reputation that are important in understanding HFE/UX project work as a social exchange rather than just a technical piece of work (Appendix 1: Functions 15, 27 and 28).
• Interactions: Multiple organisational interactions have been recognised, which include accounting for supervisory mechanisms like the client holding influence and power by controlling the budget, timescales, direction of the project and any potential actions that follow the work (Appendix 1: Functions 1 and 4); how senior staff manage and mentor more junior staff (Appendix 1: Function 12); and how auditing and quality controls shape some contexts (Appendix 1: Function 29). • Systems focus: This work highlights the need for a systems approach by describing the role of systemic products that also impact the system like organisational memory, where reports, templates, processes and presentations are produced in project work, and which are then reused in future work (Appendix 1: Function 14).

Managing careers, project tactics and organisational competences
Junior practitioners need to have a good match with the company they want to work for; e.g. experience of usability testing and website design would be ideal for some companies while knowledge of physical ergonomics and workplace assessments might be more suitable for others. Junior practitioners should be proactive and selective about gaining the knowledge and experiences that will increase the chances of securing the type of position they want. They should ask themselves what would make them more competitive and employable in that ecosystem of projects, practices, tools and methods. Similarly, in terms of continuous professional development, more experienced practitioners could reflect on what experiences and contacts would benefit them in terms of the variety of work they need for the future roles and project work they want. Practitioners co-create their HFE/UX identities by being influenced and influencing the organisations they work in, which corroborates previous findings (Gray 2014;Gray, Toombs, and Gross 2015). The description of HFE/UX project work presented here puts adaptable practitioners in a central role because they are responsible for managing and responding to variability. Adaptability is an important meta-competence (Brown for much of the variability and emergent performance of HFE/UX project work. Overall, this paper highlights issues that are not commonly discussed in the HFE/UX practice literature, i.e. the factors involved in delivering high quality work to address a client's need while balancing this with the time and resources they wish to spend. The intention of this paper has not been to detail 29 functions and 6 areas for people to use directly, but rather to highlight the complexity of factors and competences that are involved in HFE/UX project work and to raise the level of reflection and debate in this area. Students should have better conceptual apparatus for thinking about how they resonate with the organisational competencies for the companies they wish to apply for. Practitioners might use the areas and competences for thinking about continuing professional development needs, e.g. in learning new tools and methods, in how to sharpen project insight, or make reporting processes more efficient. Senior practitioners may reflect on the complement of competences offered by their staff as a team, and how to mature, deepen or diversify their organisational competence in different areas, e.g. what organisational competences form a unique selling point (USP) and what competences need to be bought in or learnt to break into a new market?
This section draws out systemic features of organisational competences and implications for managing careers, project tactics and organisational strategy, and describe limitations and future work.

Systemic features of organisational competences
Managing organisational competence is complex and goes beyond individualistic notions of competencies, e.g. selecting individuals with the right competencies. The functional analysis alludes to system-orientated notions of practice recognised by Wilson (2014): • Emergence: Going beyond understanding snap shots of different projects, historical influences on emergent behaviour in the system have been identified, such as managers reiterating and reinforcing their own established practices (Appendix 1: Functions 11 and 12) and shaping the evolution of methods, tools and practices (Appendix 1: Functions 7, 9 and 16). • Context: Going beyond factors close to the action, at the 'sharp end' of project work, the important role of latent factors in the system has been recognised, such as the methods a HFE/UX practitioner learnt at school (Appendix 1: Function 7) and whether HFE/ UX practitioners expect a regulator to audit the work (Appendix 1: Function 29). • Holism: Going beyond the technical aspects of HFE/ UX project work the important role of non-technical Strategic adaptations at the organisational level made by practitioners were evident in the wider context of HFE/ UX project work. For example, as noted above, HFE10 reported proposing a project under budget so that they could win the work and build a relationship with the client. Another strategy for increasing the requisite variety of a HFE/UX service includes hiring new staff who bring new knowledge and ways of doing things, thereby diversifying the organisation's offering. These organisational strategies have received little attention in the literature despite their influence on performing project work and the longer term health of organisations. By understanding HFE/UX practice, the community are more able to resolve gaps and deficiencies, and to enhance areas of advantage. The large number of competences identified all have potential variability, they interact in a system and they provide an opportunity to reflect on the strengths and weaknesses of organisational competences and, importantly, how these competences suit the styles and demands of different HFE/ UX ecosystems.

Using FRAM outside systems safety
Part of the uniqueness of this study is using FRAM outside systems safety. FRAM's initial notion of performance variability was focused on how functions interacted to compromise safety (Hollnagel 2004), so it had to be adapted to focus more positively on how functions resonate to make systems work well (Furniss, Blandford, and Curzon 2007;Furniss, Curzon, and Blandford 2016). FRAM has since been proposed as a method to study normal performance variability (Hollnagel 2012), but studies implementing FRAM for system effectiveness and how systems flourish are rare (Furniss, Curzon, and Blandford 2016).
The application of FRAM went beyond what a thematic analysis provided: the authors had done an inductive analysis as part of the wider project which had not resulted in these functions or six subsystems -extant theory and methods can provide leverage for deepening analyses . FRAM provided a focus on functions, how these functions interacted, and different ways they interacted. Applying all steps of FRAM in detail, including the 11 CPCs and detailing all 6 aspects is time-consuming, but these do not all have to be followed to deliver insight. FRAM is a means to an end, and the end is not a comprehensive FRAM model but an analysis that delivers insight.

Limitations
A sample of 22 participants could be considered small but it is reflective of a deep qualitative analysis based on in-depth interviews (e.g. a survey would deliver broader, shallower data). The analysis has proceeded in bottom-up and McCartney 1995), which applies to the tactical adaptations necessary for individual projects, but also to the strategic adaptations related to building competence for their organisation and their own careers in the longer term. Practitioners' expertise is a key resource as this influences the ability of the system to respond to expected and unexpected variability. Overall, HFE/UX practitioners need to adapt to the situation, including the adoption and adaptation of methods, matching the projects that confront them with the responses they are able to offer. It is the humans in the system that adds the requisite variety to be able to respond to disturbances in the environment. Ashby's (1956) requisite variety states that the controlling system must be as variable as the system it controls, i.e. HFE/UX practitioners need the flexibility and experience to handle what is thrown at them. The wider the variety of experience they have, the more likely they are to have come across a given situation before, which will lead to them choosing a satisfactory course of action in the future.
Some highlights of practitioners learning about project tactics include making sure you are talking to the right people, adjusting what you are saying and how to whom, and recruiting a particular person to a project team if they have specialist skills and a reputation in that area. Sharing these tactics could make HFE/UX organisations and the broader community more resilient. Knowledge sharing about everyday practice, and about successes and failures, increases the requisite variety for those who have not had those experiences. Storytelling can be an important practice as Weick (1987, 113) suggests: 'The basic idea is that a system that values stories, storytellers, and storytelling will be more reliable than a system that derogates these substitutes for trial and error' . From a more seasoned practitioner's perspective, the community needs to find ways to capture their adaptable behaviour. Spencer (2000) is a good example of this, applied to one method (Cognitive Walkthrough): he describes the social constraints that challenge the normal use of the method (i.e. time pressure, lengthy design discussions and design defensiveness); his adaptations and rationale; and their impact. Beyond methods, practitioners can share case studies (e.g. Wiklund 1994) and reflective pieces (e.g. Shorrock and Williams 2016) to facilitate wider learning and encourage reflection within the community. Resilience strategies can be identified and described for this community as it has been done for others (e.g. Larcos et al. 2016).
In the authors' experience, practitioners are already very knowledgeable about the variability of project work they are exposed to and what it takes to make it successful. The processes presented here give practitioners new ways to communicate what they already know and spark debate about what does and does not fit their experience, as well as where gaps lie. the interactions between these areas and how they mesh together. Practitioners should reflect on developing the complex range of competences and meta-competences necessary for their career, as well as how this complements organisational competence. How organisational competence is managed, adapted and diversified will impact whether HFE/UX projects flourish or stall. and top-down stages that employed relevant theory to reach this point (Furniss, Blandford, and Curzon 2011). The constructivist style of analysis conducted accepts that the analyst creates an account of the results that combines methodological and theoretical moves that fit the data.
Four of the UX practitioners were relatively inexperienced which could be seen to limit the ecological validity of the results for more experienced practitioners. However, experienced practitioners internal and external to the study validated the account. Also, having this diversity of experience broadens the applicability of the findings.
The data presented here are based on interviews that could suffer from participants not saying what they actually do; e.g. they may want to show themselves and their company in a positive light. To reduce this effect, all participants agreed that they would remain anonymous so that they would neither suffer nor benefit from the views they shared.
This work has combined perspectives from UX practitioners working on commercial products and HFE practitioners with experience in safety-critical projects. These diverse groups are good for theoretical sampling; i.e. it increases the breadth of views in the data. The landscape of practitioners and their roles is complex, and practitioners who work in this broad area self-identify with different terms, e.g. HCI, usability, user experience, ergonomics, human factors and with different subspecialties, from information architecture to manual handling. The terms usability, human factors and HFE/UX have been used broadly. Future studies might attend to specific subgroups and specialties, to engage with their different ecosystems of knowledge, skills, methods and the types of work they do.

Conclusion
This is the first study to look at HFE/UX organisational competences. This work moves away from individualistic notions of competencies to highlight how competences have systemic properties, are contextualised, and are integrated together in a web of links. Systemic properties include an appreciation of the history of relationships and project work that can impact performance, and how organisational memory can enhance project work. Furthermore, from a systems perspective, even things like specialist tools and methods (rather than people per se) can influence organisational competence. There is wide variability in HFE/UX project work that takes place in different ecosystems of tools, methods, styles and reporting practices. Managers should work to ensure the staff (with tools, methods and processes), jointly provide the organisational competency suited to the ecosystem they inhabit. This is through developing and maintaining individual areas of competences, and recognising the complexities of Through engagement with HFE/UX services and having project options to consider, the client will come to learn more about HFE/UX processes. They should be informed enough to make decisions at the project negotiation stage. Also, some clients will not care about HFE/UX processes but will be focused on whether their aims are met in their terms 6.
Allocate resources resource allocation plays a large role in project negotiation. it is rare that resources are abundant and projects have to be competitive in terms of costs and benefits. There will be cheaper and more expensive options with their own pros and cons to consider. The practitioner can present tiered options, with pros and cons, and the risks to the project if they are reduced or not carried out. These changes will affect what can be or will not be accomplished 7.
Develop methods methods are developed in academia and in industry, and some are borrowed from other domains e.g. marketing. methods are refined for use in practice. For them to proliferate they need to be sufficiently promoted, useful and suitable for use. The communication of novel methods can come from different sources; e.g. colleagues, conferences, meetings, blogs, journals, articles and courses. The effectiveness of this knowledge transfer is circumstantial. The method itself should not be the focus, it is a means of fulfilling the client's need. method selection is discussed in Function 8 8.
select method once the client need is appropriately understood the right method or methods might be apparent to the experienced practitioner. The selection will be based on different dependencies including: the problem, what the practitioner is used to, the client's preference, organisational practice, time, budget, access to users and prototypes, project stage, communication and persuasion requirements, auditing requirements and tool support. some methods require great expertise. People will have a tendency to stick to what they know 9.
Develop tools Tools are developed in academia and in industry; they are refined in practice. For them to proliferate they need to be sufficiently promoted, useful and suitable for use. The communication of tools can come from different sources; e.g. colleagues, conferences, meetings, blogs, journals, articles and courses. The effectiveness of this knowledge transfer is circumstantial. The tool itself should not be the focus, it is a means of fulfilling the client's need. As products and technologies evolve so will tools, i.e. they will have new requirements to fulfil and new potentials to fulfil those requirements. Tool selection is discussed in Function 10 10.
select tool Tool selection will be based on different dependencies including: the problem, what the practitioner is used to, the client's preference, organisational practice, time, budget and access to tools. Tools can enhance and extend abilities. Useful tools are assimilated into a practitioner's repertoire/toolkit. Practitioners will develop efficient and effective ways of working. some tools may be cumbersome but necessary; however, alternative routes to a solution may be selected if trade-offs are appropriate e.g. video editing may be avoided if it is cumbersome to do and it isn't felt it would greatly benefit the project. some tools require great expertise. People will have a tendency to stick to what they know 11.
Develop staff Practitioners are a critical resource in HFE/UX work who need to be nurtured and developed -they will have a direct impact on what can be achieved from the project. As practitioners mature in their careers they will have a wider repertoire of abilities and responsibilities. nurturing opportunities will vary between contexts, and practitioners can push their own development agenda rather than being passive to it. some practitioners will specialise in a domain or method, others will be more generalist. Practitioners have different preferences, qualities and abilities 12.
oversee project senior practitioners are in a position to monitor and manage staff, projects and clients. For example, through experience they will know methods, solutions and potential project pitfalls to monitor work effectively. new staff may bring in alternative approaches that senior practitioners can learn from, making learning and management a two-way process. A good HFE/UX practitioner may not be a good manager, and managers may not always be HFE/UX practitioners 13.
Perform project work The quality of the project work will be influenced by the skills and experience of the practitioner performing the work, knowledge of their manager and the collective knowledge of the organisation. clients can learn directly about issues observing or taking part in the project work. closer client involvement has to be traded off with slowing the process down and potentially introducing bias 14.
Develop a paper trail some contexts value an audit trail more than others; from contexts where clients require it for quality control to where this practice may hinder the ebb and flow of design. Past project reports, information and presentations can be used as a resource for future work 15.
Persuade client Persuading and negotiating are key skills in client interaction 16.
Develop reporting practices reporting practices are developed in practice to enhance the transfer of information in different forms: making it more intelligible, faster, persuasive and fit for purpose. Different audiences of the same report may have different needs and expectations of it; for example: directors need to be sold the overall message, developers will want the detailed recommendations and the regulators will want convincing that appropriate methodology has been followed. Different reports may also be written for each audience 17.
select reporting practice The selection of the reporting practice will be based on different dependencies including: what the practitioner is used to, the client's preference, organisational practice, time, budget, the sort of insights and data, project stage, communication and persuasion requirements, auditing requirements and tool support (Continued) No. Name of function Description 18.
Analyse data Analysis will vary depending on the method used and the data that have been gathered. it may be qualitative, quantitative, in-depth or light 19.
Practitioner develops an understanding of the project issues Practitioner understanding develops throughout the project. Understanding of the project issues is heavily reliant on the expertise, motivation and insights of the practitioner. Project work is not just about applying the right method; sometimes it is more important to engage with the people and details of the context with an open mind. in the worst cases focusing on a method might mask what the real issues are, which could lead to inappropriate conclusions and recommendations 20.
Practitioner develops understanding of the domain Practitioners may develop expertise in a particular domain knowing jargon, issues, contacts, culture, practices and preferences 21.
Write report Written reports seem a standard part of HFE/UX work. Function 22 shows these can be supplemented with a presentation, question and answer session, design type workshop, video footage, etc. However, contributions can happen outside of this, e.g. through the observation of project work and close working relationships 22.
communicate to client communicating results to clients is a critical part of the project. communication can be informal and frequent in close working relationships or can be formal and infrequent in detached independent evaluations. Just a written report may be given or it may be supplemented with a presentation, question and answer session, design type workshop, video footage, etc. 23. client engages with results if possible it is important to feed back the results to the right person who cares about the issues, and describe the results in such a way that it resonates with the client's values. The contact person on the client side may not be the right person. The right person may be the most senior person, or maybe the most senior person who will engage 24.
client develops an understanding of the results results from a project should be clear and persuasive, going as far as spelling out how the client should exploit the results. in some cases, the client may not wish to understand the results but may just want to act on the recommendations so the issue can be solved 25.
client considers results clients can be complex entities with their own internal politics: with different people, agendas, remits and values. This can affect their consideration of the results. some clients may have employed HFE/UX services to provide support for their own internal agendas 26.
client acts on results The practitioner is often in an advisory role in the client relationship, where the client holds the power. sometimes practitioners are unaware of client action or inaction; and sometimes they have closer working relationships. in situations where advice is critical practitioners may protect themselves by making sure the advice and decisions are recorded 27.
Build reputation reputation can be a valuable commodity of the practitioner and/or the HFE/UX organisation. Past performance is believed to indicate future performance. reputation can facilitate project work and recommendations 28.
Build rapport Practitioners can develop rapport intentionally by being/acting friendly, courteous and engaging with people on a personal level. Different methods can allow more or less opportunity to build rapport e.g. observing user testing or taking part in a workshop can increase contact. rapport can facilitate winning project work and receptiveness to recommendations 29.
Audit project work The importance of auditing differs between contexts. Where it is important extensive method sections are included in reports to satisfy regulators and to maintain auditing procedures, even though clients are not interested in them. HFE/UX practitioners can also be involved in auditing other's work. Formal auditing can be foreign in more informal settings

Appendix 1. (Continued)
These sorts of links build up a more complex picture of how functions may influence each other. Functions can have a single link to another function's aspect, or they can have multiple links to other functions thereby being influenced and influence many other functions in the network. For example, developing a paper trail is dependent on many other functions in the network, and developing staff influences many other functions in the network because staff are so closely involved in doing the work.
'background functions' (http://functionalresonance.com/ a-fram-glossary.html (accessed 14 July 2017)) and appear greyed out in the network diagrams. The FRAM Model Visualiser (FMV) assisted the analysis involved in this work. Hollnagel and Hill (2015