Integrating user experience into cybersecurity: challenges, opportunities and actionable recommendations from a case study

The belief that humans are the weakest link in cybersecurity restricts the scope of potential solutions. Scientific literature predominantly focuses on user education and awareness (Alsharida et al., 2023). Organisations often attempt to exclude humans from systems or, when this is not feasible, rely on training, awareness programs and restrictive policies to control user behaviour (Zimmermann and Renaud, 2019). However, systems that neglect user needs and requirements risk being rejected or mishandled, undermining security. Studies as early as 1996 advocate for human-centred design solutions and adherence to human–computer interaction principles to improve usability and motivate users to engage in safe behaviours and actions (Besnard and Arief, 2004; Pollini et al., 2022). Recognising human interaction as a critical component of cybersecurity highlights the dual role users can play: strengthening defences or introducing vulnerabilities. Recent studies begin to shift this narrative, positioning humans as the first line of defence and essential partners in combating cyber threats (Zimmermann and Renaud, 2019; Pollini et al., 2022; Zimmermann et al., 2024).

To mitigate threats, cybersecurity design must prioritise user needs and requirements. Prior work shows that improving user experience helps users adopt safer behaviours by making systems easier to use (Besnard and Arief, 2004; Pollini et al., 2022). Good user experience (UX) has become a prerequisite for system adoption, as users may reject a system if they cannot efficiently achieve their goals (Bias and Mayhew, 2005; ISO 9241-210, 2019). UX, which encompasses usability, is defined as user's perceptions and responses that result from the use or anticipated use of a system, product or service (ISO 9241-210, 2019). Despite an abundance of related literature (Hinderks et al., 2022), UX integration remains a challenge to practitioners and organisations attempting it (Chamberlain et al., 2006; Salah et al., 2014; Choma et al., 2022). This issue is particularly evident in cybersecurity, where the integration of UX and human–computer interaction principles is largely absent, with very few, if any, projects explicitly addressing this to date (Pollini et al., 2022).

This article ^[1] presents findings from a two-year case study of a cybersecurity R&D project (2022–2025) supporting the design of cyber range scenarios. Rather than evaluating user compliance, motivation, or satisfaction, which fall outside the study scope, we focus on internal project dynamics during UX integration. Specifically, we analyse how UX activities influenced team coordination, decision-making and perceptions of secure design. Data were collected through systematic participant observation (journaled project events and outcomes), a UX literacy survey (Azevedo et al., 2023) and semi-structured interviews on UX integration and future adoption. The study consolidates these results into: (1) a transferable set of UX methods and procedures tailored to cybersecurity contexts; (2) a framework formalising UX integration across four project phases; and (3) 10 actionable recommendations for development and management teams.

Human-centred design (HCD) offers an approach that aligns secure systems with user capabilities and limitations, improving experience and security. HCD prioritises user satisfaction and performance through four phases: specify the context of use, define user requirements, generate design solutions and evaluate them (ISO 9241-210, 2019). Building on HCD, UX aims to meet user needs, strengthening system security and usability. UX goes beyond usability, defined as “extent to which a system, product or service can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use” (ISO 9241-11, 2018). It encompasses pragmatic and hedonic attributes (Mahlke and Thüring, 2007; Hassenzahl, 2018). Pragmatic qualities concern efficiency, usability and functionality; hedonic qualities concern emotion, aesthetics and the pleasure of use. Effective UX balances these dimensions so systems support tasks with minimal friction and also sustain user satisfaction and engagement.

The cybersecurity community often views humans as the weakest link, attributing failures to carelessness, errors, or negligence (Furnell et al., 2018). This view downplays how culture and the role of group, social and organisational systems shape behaviour and security culture (Wiley et al., 2020). Complex procedures that fail to meet user needs prompt workarounds and non-compliance (Alsharida et al., 2023). Procedures alone are insufficient, since users always find ways around them (Besnard and Arief, 2004). Framing “humans as a problem” biases solutions toward training and protocols and excludes users from systems; Zimmermann and Renaud (2019) instead advocate viewing humans as part of the solution.

Understanding users improves security behaviour. Sociodemographics, decision-making styles and context shape responses to controls (Chowdhury et al., 2018). UX and HCD principles prioritise user needs and guide intuitive, effective security measures (Gratian et al., 2018). Research since 1996 recommends human-centred design and HCI to foster safer behaviour (Besnard and Arief, 2004; Pollini et al., 2022). By incorporating these principles, security measures can become more intuitive and effective.

Incorrect security actions usually stem from a design that conflicts with user goals or workflows rather than malicious intent. Users focus on completing tasks; when controls hinder productivity, they adopt workarounds or bypass protocols without malicious aims (Pollini et al., 2022). Contributing factors include limited understanding or motivation and limited ability to make informed decisions (Cranor, 2008). Common examples include weak passwords (De Bruijn and Janssen, 2017) and credential sharing to expedite work (Chowdhury et al., 2018), often because perceived benefits of bypassing controls outweigh perceived risks (Besnard and Arief, 2004). Users also report unclear communication, time pressure, inaccessible documentation and inadequate instructions (Pollini et al., 2022). When design neglects user needs and behaviour, measures become counter-productive and create vulnerabilities with significant consequences for individuals and organisations (Corradini, 2020). A human-centred approach aligns controls with workflows and reduces usability-driven trade-offs.

Good design considers the full interaction context, not only the system. Environmental stimuli such as competing communication, ambient light or noise can divert attention from security cues (Cranor, 2008). Habituation to repeated, standardised warnings further reduces attention, so users may miss indicators in familiar software (Cranor, 2008). Attention attractors can refocus users on key features but may disrupt workflows, creating a security–usability trade-off (Bravo-Lillo et al., 2013). Human-centred design helps manage these trade-offs by aligning security tasks with user workflows and UX methods reveal gaps between perceived and actual security. For example, Stojkovski et al. (2019) use multi-layered user journeys to uncover misalignments that inform security analysis.

Despite these benefits, few cybersecurity papers engage directly with UX. Many focus on generalisable human characteristics, secure usability, or pragmatic aspects of UX such as effectiveness or efficiency. For instance, Gratian et al. (2018) and Furnell and Clarke (2012) analyse human characteristics to inform design but do not conduct UX research with specific users. By contrast, UX work gathers and applies first-hand user data to fit user needs. Although Rajarathnam and Singh (2024) claim that UX and cybersecurity are well represented, their own NVivo keyword analysis suggests otherwise: “UX” is absent; “user” appears but is likely mostly linked to topics such as authentication or access; and “experience” is also absent. Usability is reported, but usability is limited to functional and efficiency-related concerns, omitting UX's hedonic dimensions such as stimulation (Hassenzahl, 2018) or social acceptance (Mortazavi et al., 2024). Their findings therefore reinforce the lack of genuine research on user experience with secure systems. That is not to say UX is entirely absent from cybersecurity: Wash (2010) identifies user threat models via interviews and mental modelling, and Zimmermann et al. (2024) advocate human-centred cybersecurity, showing how user–system interaction affects outcomes.

Difficulties integrating UX extend beyond cybersecurity. Many organisations and stakeholders struggle to prioritise UX in software development (Gray et al., 2015). Trust matters: teams tend to trust UX practitioners before trusting UX as a field (Nielsen et al., 2023) and building that trust remains challenging (MacDonald, 2017), especially under uncertainty and individual risk aversion (Nielsen et al., 2023).

Misaligned rationales, priorities and practices create friction (Law and Lárusdóttir, 2015). Challenges include developer focus on functionality and efficiency over usability (Bak et al., 2008; Ardito et al., 2014) and weak mutual understanding with designers hinder communication (Jones and Thoma, 2019; Argumanis et al., 2020; Kashfi et al., 2017). Senior management often protects developer time, which lowers the perceived value of UX and expectations for UX quality (Nielsen et al., 2023). Insufficient prioritisation and resources result in disorganised UX management, a lack of strategic representation and inconsistent practice across projects (Nielsen et al., 2023), producing high workloads (Jurca et al., 2014) and bottlenecks (MacDonald, 2017).

Both Agile and Waterfall present integration issues. In agile, despite two decades of research on agile–UX integration (Schön et al., 2023), persistent barriers include resistance to Big Upfront work that limits early research and design (Law and Lárusdóttir, 2015), difficulty incorporating user feedback (Ferreira et al., 2023), weak prioritisation of user needs, poor designer–developer communication (Argumanis et al., 2020; Jones and Thoma, 2019), lack of shared product vision and understaffed UX (Jurca et al., 2014). Waterfall, in turn, fixes requirements early, sidelines later user data and pushes formative evaluation after development (Royce, 1987), which conflicts with the iterative nature of UX that relies on continuous testing, refinement and new insights throughout.

This case study presents how UX is integrated in an R&D cybersecurity project (2022–2025), focusing on facilitating the creation of cyber range scenarios. The expected outcome is an interactive system supporting scenario creation. The project involves three partners: a university (UNI), a centre of excellence (COE) and an industrial partner (IND). UNI's mission is to (1) implement a user-centred development process following the UX Process Reference Model (UXPRM) by Kieffer et al. (2020), (2) design a graphical user interface and (3) model and implement an approach for scenario generation, supervision and guidance. COE implements and integrates the graphical interface, while IND provides the cyber range infrastructure.

The project adopted a hybrid project management approach. WP1 (“Addressing user needs for impactful applied research”) was dedicated to UX and ran iteratively throughout the project, following HCD principles and the UXPRM structure. Insights from WP1 informed priorities, design choices and implementation decisions in all other work packages. However, several development phases—especially within COE and IND – were conducted in a sequential, Waterfall-like manner, fixing requirements early and limiting opportunities for iteration. This hybrid setup shaped UX integration: WP1 ensured continuous user-centred input, while Waterfall phases sometimes constrained the timing and scope of UX-driven changes.

The integration of UX has enabled the achievement of several milestones:

1. Increased number of UX activities. An expert review of existing cyber ranges was completed three months after project kick-off. This first successful UX activity encouraged non-UX experts to participate, resulting in a higher number of subsequent UX activities.

2. Established interdisciplinary design team. The team included this paper's 1st and 2nd authors as UX researchers from UNI, plus two researchers from UNI and two from COE specialising in cybersecurity and software engineering. The team collaborated on UX design (e.g. prototyping), evaluation (e.g. user testing) and decision-making (e.g. setting priorities and defining requirements). Non-UX experts attended at least two user testing sessions, using these “meeting points” to coordinate project management and planning.

3. Increased perceived value of UX. Non-UX experts began to view UX as a transversal asset. The deliberate progression from UX methods without users to UX methods with users strengthened integration and raised the perceived value of UX across partners.

We use the UX process reference model from Kieffer et al. (2020) to define project UX activities. The model distinguishes three primary UX processes – analysis, design and evaluation – and articulates their interrelations within a structured lifecycle. Each process has specific objectives, supported by concrete UX methods and expected outcomes. At the core of this lifecycle sits the specification of user requirements, which serves as the cornerstone of the UX process. The specification consolidates the outcomes of analysis activities (e.g. user needs, contextual insights, user feedback) and steers the design and evaluation of solutions. It plays a critical role in aligning UX efforts with project goals and ensuring continuity across phases. Figure 1 shows the UX methods applied in the project, organised by primary process, along with the UX artefacts that fed into the user requirements specification.

The model fits the project's iterative, incremental development by treating user requirements as a composite artefact that evolves as processes advance. As Figure 1 shows, UX artefacts resulting from the UX primary process directly feed into the user requirements. Specifically, prototypes allow us to document a first version of the user requirements, later refined and completed by other work products (i.e. goals, scenarios, models) as new UX processes took place (e.g. interview or user testing). The resulting specification captures context of use, UX goals, UX design, stakeholder-approved requirements, measurable benchmarks and evidence of usability and UX acceptance, and it directs subsequent development and refinement.

The analysis comprises a verbal protocol and an inspection of the existing system. Verbal protocols serve to make thoughts and cognitive processes explicit during task performance, whereas inspections serve to analyse the learnability and predict the usability or UX problems with systems (Kieffer et al., 2019). A verbal protocol was conducted using the think-aloud technique during a live-demonstration walk-through of the existing system. For the inspection, we used the expert review technique, where two experts evaluated guidelines outlined in Leavitt and Shneiderman (2006) and rated each screen of the system that users interact with to complete a specific task.

Furthermore, data for the intended system were gathered through individual and group interviews. A semi-structured interview collected information on user attitudes and habits through two 1-h sessions, each with 15 questions. Opportunistic group interviews took place as informal discussions during project reviews, designed to gather insights from a selected group of individuals on specific topics.

Using data from the analysis, we set goals and design scenarios, task models, low-fidelity and medium-fidelity prototypes. UX goals are identified and documented to establish specific qualitative and quantitative objectives driving the design. User scenarios and stories are written to illustrate how users achieve their goals with the system and describe software features from the user's perspective. Scenarios are used for user testing, while stories guide developers on what to develop. A task model defines the tasks users should complete in the system, facilitating the design of interactions between cognitive tasks, user tasks and system tasks and grouping tasks into screens. Each member of the design team creates low-fidelity prototypes (sketches) of their design ideas, which are then consolidated on a whiteboard to create a testable mock-up. The consolidated sketches are then turned into an interactive medium-fidelity prototype to capture and illustrate user interactions with the intended system (McCurdy et al., 2006).

The evaluation is strictly formative and consisted of a series of user tests. User tests are conducted individually with users to assess the usability and UX with the system with a sample population. Users complete tasks following specific scenarios to assess system usability and UX. Afterward, users provide feedback through a questionnaire containing seven modules of User Experience Questionnaire+ and the System Usability Scale. Sessions are recorded for observation and semi-structured interviews gather qualitative feedback. Participants sign consent forms prior to data collection to ensure understanding. There are no adverse side effects.

This study adopts an exploratory case study approach due to the limited literature on UX integration in cybersecurity and uncontrollable contextual factors (Baxter et al., 2008; Quintão et al., 2020). Exploratory case studies inherently exhibit qualitative research characteristics such as lack of control over settings, small sample sizes, reliance on narrative data and an absence of intent to statistically generalise findings or demonstrate cause-and-effect (Quintão et al., 2020). Collecting data at multiple occasions and using different methods, including surveys, observations, journaling and interviews, captures both subjective experiences and objective measures and increases reliability (Baxter et al., 2008; Quintão et al., 2020).

We conducted four rounds of data collection using participant observation, survey and interview. The project partners signed a memorandum of understanding, allowing the collection of data among themselves. Survey and interview participants read and signed a consent form prior to data collection. The combination of survey, interview and participant observation enables us to address the research questions through cross-analysis and triangulation of findings. Documenting UX activities at different project stages captures the process, challenges and outcomes, helping us understand how UX can be effectively integrated into cybersecurity projects to support human-centred design (RQ1). The survey's modules on perceived opportunities and barriers (OPP and BAR) for UX integration provide insights into recurring challenges, while interviews allow us to explore these issues in greater depth. Analyzing these responses uncovers specific challenges and opportunities for UX integration in cybersecurity (RQ2).

Data collection is structured into four rounds, each aligned with specific project milestones. Round 1 (R1) follows the initial annual project review with the project sponsor. Round 2 (R2) commences after the initiation of direct data collection from users through interviews. Round 3 (R3) occurs post-user testing. Round 4 (R4) follows scientific review during which the project's continuation was decided. Figure 2 shows the articulation of rounds of data collection with the UX activities.

We sample participants from each project partner (i.e. UNI, COE and IND) based on their involvement in UX activities and job roles: researchers, project leaders, product owner and software engineers. Researchers refer to the N = 4 non-UX researchers from the design team involved in UX activities (two from UNI and two from COE). Project leaders (one per project partner), product owner (one from IND) and software engineers (one from COE and two from IND) are not directly involved in UX activities. All participants are male, aged 30 to 65 years, with expertise in software engineering, cybersecurity, or both. Table 1 presents the participant distribution per round and job role for the survey and interview. Participant observation is conducted by researchers from R2 onward during design team events.

R1 involves N = 11 survey participants and N = 6 interview participants evenly distributed per project partner (two from UNI, two from COE and two from IND). In R2, we administer the survey to the N = 4 researchers. In R3, data collection includes survey and interview of the N = 4 researchers. In R4, we survey and interviewed the N = 3 project managers and N = 1 product owner.

Participant observation. We conduct participant observation on the N = 4 non-UX researchers of the design team, two from UNI and two from COE. Data collection includes systematic recording of events in a journal, their categorisation by type (e.g. meetings, workshops) and their detailed documentation with date, attendees, event objectives, descriptive account of proceedings and reflections on outcomes (including decisions, discussions, challenges and advancements). This approach serves to document project activities, offering insights into the implementation of UX methods and their impact on project dynamics. It facilitates a nuanced understanding of participants interactions, decision-making processes and the project's overall evolution.

Survey. We administer the survey proposed by Azevedo et al. (2023). The survey contains six modules and measures respondents' knowledge about UX according to six dimensions, one dimension per module: understanding of HCD (HCD), understanding of UX (UUX), attitude toward users (ATU), awareness of UX ROI (ROI), perceived opportunities (OPP) for and barriers (BAR) to UX integration. Respondents indicate their level of agreement with statements on a 5-point Likert scale to complete the survey, which takes approximately 5 min.

Interview. The interviews address two additional topics related to the survey, namely UX integration and prospects for UX. Questions regarding UX integration include: “How do UX activities integrate into or modify the current software development model?” and “How did the introduction of UX activities affect the way you do your job?”. Questions about prospects for UX explore: “Why would you consider or not consider integrating activities in other projects?” and “What information related to UX would aid your decision-making process?”. Each question aims to gather insights into project partners' perspectives on UX. We conduct and record interviews using an online video conference tool.

Descriptive statistics. Survey responses are first recoded to adjust for reverse-worded items. Descriptive statistics, including means and standard deviations are computed for each participant, UX dimension and round. Finally, participants are compared to identify convergences or divergences in scores across rounds, participant involvement in UX activities or organisation.

Thematic analysis. The interviews undergo thematic analysis in the six steps outlined in Braun and Clarke (2006) (familiarisation, initial coding, searching for themes, reviewing themes, defining and naming themes and reporting). Coding is carried out in a spreadsheet that records participant ID, participant involvement in UX activities, round of data collection, verbatim, subtheme and theme. A second researcher audited the coded corpus. Each sub-theme is counted once per participant per round, regardless of how many times the participant refers to it. Table 2 presents two examples of the thematic analysis coding.

Data triangulation. We use the computed survey scores to group participants showing similar patterns and use the scores as cues to investigate qualitative data. We use participant observation notes to cross-analyse and connect relevant coded interview data and computed scores.

Table 3 presents illustrative field notes. Field notes cover 34 events between September 2023 and July 2024. No eligible events occur before R1. Between R1 and R2, five events were logged (1 workshop, 2 interviews, 1 meeting and 1 other), between R2 and R3, 13 (6 workshops, 4 meetings, 1 interview, 1 review and 1 other) and between R3 and R4, eight (4 workshops and 4 other). Events were coded inductively into four perception labels: UX valued refers to explicit or implicit recognition of UX benefits, resistance refers to verbal or behavioural push-back against UX, disengagement refers to participants' presence without contribution and team friction refers to overt disagreement or affective strain between team members. A single event can carry up to two labels.

Across all events, UX valued appears in 15, resistance in 3 and disengagement in 1. Team friction occurred in 10 events and increased over time. By round, UX valued occurred in 3/5 events between R1 and R2, 7/13 between R2 and R3 and 4/8 between R3 and R4. Interpersonal tension peaked in R3 (6 events) and persisted in R4 (4), mostly between COE and UNI due to differing approaches, goals and missions. Explicit resistance appears once in R3 and once in R4. Figure 3 shows the distribution across rounds.

Figure 4 depicts the distribution of knowledge scores per round, UX dimension and involvement in UX activities, while Table 4 presents individual scores per round. Given the small sample, patterns are interpreted descriptively. In R1, participants involved in UX activities (P5–P8) (M = 3.59, SD = 0.70, N = 4) tend to score higher than participants not involved in UX activities (P1–P4, P9–P11) (M = 3.18, SD = 0.86, N = 7). Participants involved in UX activities showed notably higher scores in BAR (+1.11), HCD (+0.85) and ATU (+0.63), similar scores in UUX (+0.14) and ROI (+0.02), but lower scores in OPP (−0.29). In R2, participants involved in UX activities tend to score higher across all UX dimensions except HCD. Scores declined in R3, in some cases falling below R1 levels, with the exception of OPP, which remained higher in R3 than in R1 (+0.19). By contrast, participants not involved in UX activities (P1–P4) in later rounds tend to score notably lower in UUX (−0.19) and ROI (−0.37), but higher in BAR (+0.62) and OPP (+0.37).

The thematic analysis comprises two groups: (1) categories of information participants find useful for decision-making and (2) arguments for and against UX integration.

Decision-making. Thematic analysis reveals 7 themes and 21 subthemes that describe information that supports decision-making. The most prevalent theme is instrumental measures (16 occurences) and focuses on objective usability and efficiency metrics, including user feedback (P2, P6), ease of use (P2, P6, P7, P8), click efficiency (P4), ease of learning (P2), usability (P2, P4), usefulness (P2) and avoiding repetitive actions (P2). UX artefacts to support coding (10 occurences) groups deliverables that aid implementation, such as wireframes (P1, P6, P7, P8), user scenarios (P7) and workflow diagrams (P2, P5, P8). UX standards (4 occurences) cover guidance for design consistency, including guidelines or checklists (P7), style guidelines (P7) and good practices (P7). Hedonic measures (2 occurences) address emotional responses, by capturing feelings or emotions (P6) and happiness (P3). UX research validation (2 occurences) covers activities that test whether solutions meet user goals, through verifying user needs (P6) and goal achievement (P4). UX artefacts to support architecture design (2 occurences) lists early-stage deliverables such as data model and requirements (P1). Guidance for design (2 occurences) provides design-decision aids, namely criteria to compare design and methods to design (both P1). Figure 5 shows the distribution of these categories by involvement in UX activities and interview round.

UX integration. Eight themes and 24 subthemes summarise perceived benefits and downsides of integrating UX. The most prevalent, user needs (17 occurrences), addresses alignment with end-user goals: meeting user goals, needs and requirements (P1, P2, P4, P5 and P6), running user tests (P1 and P6), validating requirements before development (P4), ensuring intuitive use (P1 and P4), collecting user requirements (P4) and understanding accessibility needs (P5, P6 and P7). Design UI (6 occurrences) focuses on clear, useable interfaces, including good UI (P1, P4 and P7) and modelling the graphical UI (P1). Increased ROI (6 occurrences) highlights business advantages of UX work: interaction efficiency (P3), easier to sell (P2 and P4), avoiding delays when UX participates (P6) and easier maintenance with fewer iterations and patches (P4). Communication (5 occurrences) highlights stronger stakeholder dialogue: facilitating design discussions (P2 and P4), keeping developers closer to users (P4) and supporting UX–developer communication (P4). No UI or POC (7 occurrences) captures situations where projects present no interface or only a proof-of-concept UI, reflected in the single sub-theme no UI/proof of concept (P1, P3, P4 and P7). User population (5 occurrences) stresses tailoring interfaces for non-technical users, e.g. good UI for non-technical people (P1, P4, P7 and P8). Decreased ROI (3 occurrences) captures concerns about cost or time: development delays (P4), perceived expense (P3) and claims that UX is unnecessary or unevaluated in research contexts (P3). Finally, UX resources (3 occurrences) points to staffing and budget constraints through the sub-themes “no dedicated UX staff” and “not enough resources (budget)” (P3). Figure 6 presents the distribution of argument categories per involvement in UX activities and interview round.

Results are discussed across five themes: participants' UX knowledge, perceptions of UX, UX as a decision-making aid, benefits and downsides of UX integration and UX as common ground. Project partners refers to UNI, COE and IND staff engaged in research and development. Participants denotes the N = 11 study participants; participants involved in UX activities are the N = 4 non-UX researchers from the design team (P5—P8); participants not involved are project leads, product owners and software engineers (P1–P4 and P9–P11).

Participants involved in UX activities tend to score higher and show greater consensus than those not involved, which suggests that participation improves understanding of UX's potential. In R1, non-involved participants tend to keep a project-level focus and prioritise business requirements over user needs, which are “only considered later” (P4, R1). Involved participants tend to adopt a process view and emphasise early UX integration (e.g. “not just at the end” (P6, R1). Large gaps in BAR and OPP align with these profiles; higher HCD and ATU among involved participants reflect proximity to UX staff and users.

Scores for involved participants rise in R2 on ATU, BAR and OPP after first contact with end users, then dip in R3 where testing exposes design gaps and recover by R4. Interviews indicate that user testing recalibrates expectations: expert opinion and internal reasoning do not replace evidence from users. As one participant put it, “some parts of the application are still missing, which we only discovered during user testing” (P5 and R3). Scores for non-involved participants remain stable from R1 to R4 with small changes by dimension; during reviews, they approve progress at each stage, suggesting satisfaction despite limited direct involvement.

Across roles, participants view UX as beneficial and associate good UX with higher system quality. Two trends stand out: UX activities have an impact on participants' mindset and on project management.

A more human-centred mindset. Participants' mindsets become more human-centred in three specific ways: they shift focus from features to user needs, they rely on direct user evidence, and they validate earlier with low-fidelity prototypes. First, early expert inspection redirects attention from features to users, e.g. P4 (R1) stated being more focused on UX, compared to their previous focus on features. Second, direct involvement of users showed that team-approved designs may fail for users. P6 (R3) reported being “mind blown … [when] the user didn't understand the design,” adding that “without understanding user needs, we cannot create a [useable product]”. P5 (R3) noted that missing parts “only [appeared] when testing with users.” Third, early testing with low-fidelity prototypes also changed practice and enabled faster course correction and reduced rework. P7 (R1) argued that the sooner “you can validate with the user … the better,” which supported the decision to pause development until further tests confirmed the new direction.

Project management. Project management became more human-centred in three specific ways: HCD was formalised and UX planned as a continuous, cross-project roadmap; co-creation artefacts (e.g. consolidated wireframes) aligned roles and reduced coding iterations; and early UX integration anchored requirements and prevented misaligned features. First, the project development team implemented UX as a transversal continuous process throughout the project. The project managers planned UX as an ongoing roadmap within the lifecycle (P2, R1), even titling the work package dedicated to project management as “addressing user needs for impactful applied research”. Second, co-creation and agreed design enabled smoother implementation with fewer iterations: “we don't need to iterate a lot […] because we spend time designing and agreeing on the design” and then “I can provide the final wireframe, and developers can build the feature accordingly” (P7, R1). Third, integrating UX early ensured real user needs entered the system and avoided misfit features: “if it's not integrated early, the feature may not be developed [and] doesn't align with user needs” (P6, R3). This approach aligns with Isomursu et al. (2012), which advocates for more collaborative interactions between UX designers and software engineers.

Across rounds, participants mention roughly the same decision aids (Figure 5). Those involved in UX tend to prioritise standards and checklists, and artefacts that support coding, such as wireframes and user scenarios. Those not involved tend to prioritise project-level guidance: design criteria, methods, requirements and data modelling. All participants rely on instrumental measures for decisions. In interviews, non-involved participants focus on features to implement, while involved participants coordinate UX and development and shift emphasis as needed.

Avoiding direct user involvement in analysis, design and evaluation signals low UX maturity. Less mature organisations rely on expert reviews and focus groups. More mature organisations foreground contextual inquiry, observation and user testing, and base design on iterative cycles of prototyping, testing and refinement. Established maturity models and studies consistently associate direct user involvement with higher maturity (Earthy, 1998; Staggers and Rodney, 2012; Venturi et al., 2006; Buis et al., 2023).

Across rounds, participants report more benefits than downsides. They value UX for eliciting user requirements align the design accordingly and for validating them early through user tests. UX is seen as essential for non-technical users and UI work, with limited interest when a project has no UI or remains a proof of concept.

Participants involved in UX focus are more process-oriented, and their focus moves from interface Polish to meeting user needs. They expect fewer late iterations and smoother handovers, and note that wireframes both specify layout for developers and support communication with non-design stakeholders, consistent with Ferreira et al. (2023). They acknowledge a higher short-term workload and possible schedule stretch, yet anticipate less total rework.

Participants not involved are more project-oriented and prioritise ROI, communication and resources. They note that UX “takes time … to make a better interface” (P3, R4) and adds “additional effort” (P01, R4), which can raise costs and delay development. Hence, similar to Bak et al. (2008), resource demands are a challenge to UX integration, as managers weigh immediate effort against longer-term efficiency and economy (Bak et al., 2008). However, participants not involved also cite longer-term gains: higher interaction efficiency, easier marketing and lower maintenance due to fewer patches.

UX artefacts, especially low-fidelity prototypes, act as boundary objects that help communication among partners, particularly those not involved in UX. Consolidated sketches, whiteboards and other outputs are recorded and reused across phases to ensure continuity and knowledge sharing. A participant not involved noted, “Since we do a lot of prototypes, we often ask end users ‘is that what you wanted?”’ (P1, R1/R4), which helped early alignment and facilitated understanding. This role of prototypes as communication aids is well documented (Ferreira et al., 2023).

Workshops enable co-creation: participants reconcile technical constraints with user needs, establish a common language and resolve disagreements by anchoring decisions in user evidence and feasibility. Field notes indicate that workshops served as the primary venue for cross-role decisions on navigation and task flows and for resolving disagreements using user needs and technical feasibility as criteria. Participants involved in workshops set UX goals, recorded decisions and action items and produced shared artefacts (consolidated sketches, whiteboards and low-fidelity prototypes). These observations align with prior work: regular communication and close proximity support UX–development alignment (Jones and Thoma, 2019); explicit UX goals build shared understanding from the user's perspective (Salah et al., 2014); and prototypes materialise ideas, clarify implementation rules and establish a common language (Pillay and Wing, 2019; Ferreira et al., 2023). Such joint practice is essential to UX integration (Isomursu et al., 2012).

Finally, communication spans three pairs: UX–developer, UX–user and developer–user (mediated by shared artefacts). Field notes show that consolidated wireframes let developers implement agreed designs with minimal iteration, that the same artefacts organise dialogue with end users by capturing confirmations and revisions, and that prototypes help non-involved stakeholders track rationale and intended use. This triad is consistent with the role of low-fidelity artefacts as a common language across roles and stages.

Table 5 presents a framework derived from the case study, formalising how UX practices were integrated across four key phases of the cybersecurity project. The framework addresses the need for a lightweight, transferable model by distinguishing between empirical UX activities observed in the project and alternative practices grounded in the UX process reference model (Kieffer et al., 2020). For each phase, it states UX objectives, reports observed outcomes and summarises security impacts.

By capturing how UX activities contributed to security-related decisions – clarifying stakeholder expectations, refining authentication workflows, or reshaping training content – the framework shows the influence of UX beyond usability. It also supports replication by distinguishing between context-specific actions and generalisable practices that may apply to other security-driven development settings.

The framework contributes by: (1) synthesising how to phase, combine and leverage UX practices in cybersecurity to produce effects beyond usability; (2) identifying empirically grounded, theory-informed principles that explain how UX reframes security assumptions, aligns priorities and legitimises design decisions. The novelty lies in the strategic sequencing and formalisation that deliver security-specific outcomes, offering a reusable analytical lens for UX–security integration.

In addition to the analytical framework, a set of practical recommendations facilitates implementation. The framework shows how UX practices influence cybersecurity decisions across project stages; the recommendations translate these insights into guidance for development and management teams.

Recommendations target two stakeholder groups: the development team (researchers, designers, developers and product owners) and the management team (project manager, sponsor and steering committee (ISO 21500, 2021)). The groups are distinguished because they hold different levers and decision horizons: development focuses on design and implementation; management controls prioritisation, staffing, timelines, budgets and risk acceptance. The development team executes UX activities and deliverables; the management team steers strategy, process and resources. Each recommendation specifies actions and, when available, literature support, followed by patterns observed in the data.

Incorporate UX early in the development lifecycle. Involve UX experts from the planning stages to identify user needs early, avoid costly redesigns and guide development (Maguire, 2001; Bias and Mayhew, 2005; Kieffer et al., 2019). Define UX metrics early (e.g. UX goals, usability scores) to align work and evidence ROI (Bias and Mayhew, 2005; Venturi et al., 2006). Integrate UX iteratively so research continuously informs priorities (Maguire, 2001; Bias and Mayhew, 2005; Kieffer et al., 2019).

Observed: Early integration focused solutions on user needs, shifted mindsets towards human-centred choices and made UX goals a reference for design decisions and evaluation.

Start with UX methods without users. Start with methods without users (e.g. expert review) before moving to UX methods with users; this phased start limits disruption in teams new to user involvement and delivers quick, concrete wins (Azevedo et al., 2024). Early results help build confidence, address trust and commitment barriers (Nielsen et al., 2023).

Observed: Initial reluctance to test low-fidelity prototypes stemmed from concerns that their low realism would discredit the work; expert reviews and prototype workshops built confidence in user involvement and enabled user testing.

Foster collaborative workshops. Organise regular UX-led workshops that bring together designers, researchers and developers to align cybersecurity goals and UX requirements, maintain dialogue and build trust in a collaborative environment (Maguire, 2001; Azevedo et al., 2024; Ramelot et al., 2024).

Observed: Workshops served as the primary venue to align perspectives, surface constraints and reach consensus, reducing delays from unresolved disagreements.

Use UX artefacts to bridge the gap between disciplines. Use intuitive, shared artefacts that match existing mental models, supporting collaborative decision-making. Prototypes and user stories aid planning and communication; prototypes clarify ideas and time estimates (Garcia et al., 2017; Kuusinen and Väänänen-Vainio-Mattila, 2012; Ramelot et al., 2024). Teams can collaborate effectively even without identical interpretations of artefacts (Rukonic et al., 2024).

Observed: Collaborative prototyping and use of task or data models helped reconcile technical constraints with user needs and established common ground across roles.

Include development team in continuous user testing. Have developers observe and participate in user tests to see interactions first-hand, understand failures and successes, align priorities with real user needs (Azevedo et al., 2024) and demystify UX (Amant et al., 2024).

Observed: Direct exposure showed that designs acceptable to the team could still fail for end users; involvement increased appreciation of testing with users and the value of their own implemented features.

Clarify what UX entails. Educate stakeholders on UX concepts, methods and terminology to build a positive, accurate view of UX (Azevedo et al., 2023; Amant et al., 2024). Clarify the distinction between UX and graphical UI design to justify early UX activities (Fraser and Plewes, 2015; Azevedo et al., 2023). Present feasible method options and “discount” alternatives to counter perceived cost/time barriers (Bak et al., 2008; Rosenbaum et al., 1999). Demonstrate that users can express needs and inform analysis and evaluation (Ardito et al., 2014).

Observed: Ongoing exposure to UX fostered a more human-centred mindset, increased willingness to run user tests and sharpened the distinction between UX roles and UI design, in both the current and future projects.

Communicate about UX ROI. Explain UX ROI early – ideally before proposal finalisation – to set expectations, plan timelines and reduce resistance (Amant et al., 2024). Link UX to adoption and cost control by preventing rework and recoding; align with security by reducing user errors, encouraging protocol compliance and limiting unsafe workarounds (Gratian et al., 2018).

Observed: Consistent ROI messaging led to a dedicated UX work package (WP1) that shaped decisions across work packages; ROI scores were relatively high from R1 and remained stable and interviews stressed the importance of meeting user needs to deliver meaningful, useable software.

Use UX as a project management tool. Initiate UX reflection before submission and position it as the management framework for a human-centred, iterative lifecycle (Amant et al., 2024). Provide a phased UX process map; adopt a UX process reference model and agile-UX practices; involve UX experts in project management to align goals, staffing and schedules (Kieffer et al., 2019). Allocate time for UX and postpone coding until UX goals are met.

Observed: Treating UX as WP1 anchored subsequent work packages, reduced redesign and delivered a more cohesive product, underscoring UX's role in project success.

Build an interdisciplinary team. Establish an interdisciplinary with UX, ICT and cybersecurity experts to balance user requirements with technical feasibility (Kuusinen and Väänänen-Vainio-Mattila, 2012). Use collaboration to improve internal ROI (communication and integration across work packages) (Ramelot et al., 2024) and external ROI (quality and acceptance) (Amant et al., 2024). Encourage open, reflective dialogue to surface constraints and co-create solutions (Ananjeva et al., 2020; Azevedo et al., 2024) and to promote UX value (Ardito et al., 2014).

Observed: Cross-disciplinary work ruled out infeasible options early, aligned alternatives with user needs and constraints and reduced recoding. For example, user testing gave ICT and cybersecurity experts a clearer view of the context of use and user needs.

Advocate for UX inclusion in project governance. Embed UX in governance structures (roles, responsibilities and policies and decision rights) to align decisions with strategic goals (Müller, 2009; ISO 21500, 2021). Give UX experts standing as trusted advisers on par with project managers (Hinderks et al., 2022; Amant et al., 2024); build trust in people as a path to trust in the discipline (Nielsen et al., 2023). Define UX metrics such as usability scores and user satisfaction indices, for performance tracking, informed decision-making and alignment with project objectives (Atoum, 2023; Trendowicz et al., 2023). Integrate UX into risk management and require UX evidence (validated prototypes, usability results) at stage-gates reviews. While widely advocated in practice (UX Matters, 2010; The Bricks, 2025), these practices merit further academic study to validate and standardise these approaches within governance frameworks.

Observed: The initial proposal was rejected for lacking UX representation; the revised version, with UX in WP1 and an academic UX lead, was approved. Standardised questionnaires and regular usability tests provided quantitative evidence and UX risk management in WP1 supported a Go decision at the intermediate review.

These recommendations echo prior work on UX integration and remain directly relevant to cybersecurity. They go beyond usability to support hedonic qualities. Reducing frustration and building user confidence supports secure behaviour; users who feel ignored, stressed or overwhelmed are more likely to bypass safeguards or adopt risky workarounds. Designing for emotional experience is not optional; it is a prerequisite for secure systems. Even partial adoption can improve UX and strengthen security in complex systems. Table 6 illustrates how each recommendation contributes to reduce security risks and increase resilience.

The following example presents a use case with relevant constraints and user tasks. Consider an internal system for managing physical assets across multiple sites. Some users operate in office environments; others access the system from the field and may be wearing gloves, masks, or protective gear due to weather or hazardous conditions. The system includes authentication (e.g. login, MFA), critical security alerts (e.g. failed access attempts, location mismatches) and procedures for submitting or updating traceable asset information. Terminals may be shared and users are often under time pressure. For example, a user might need to log movement of sensitive materials from location A to B, confirm their identity to enter a restricted location and ensure the update is securely recorded. Another user, responsible for compliance, must rely on the accuracy and traceability of that information.

This exploratory single-case study uses a small, homogeneous, all-male sample drawn from project members and relies mainly on self-reports; behavioural data are limited to meeting field notes. Participant observation by project researchers focuses chiefly on interactions among those involved in UX activities, which can introduce observer and social desirability biases and echo-chamber effects. The grant-funded cybersecurity context with cyber-range scenarios narrows external validity. Findings provide process insight rather than generalisable causal relationships.

However, the project integrates UX from inception as a strategic work package and combines participant observation, surveys and interviews over four rounds across a year, which supports triangulation and improves reliability. The study documents changes in UX knowledge, perceptions and collaboration dynamics in a cybersecurity setting and offers concrete, evidence-based recommendations for development and management teams.

This case study integrates UX from the proposal stage as a dedicated work package in a cybersecurity project centred on a cyber-range interface. UX functions as a backbone and coordination mechanism: it enables consensus on features, balances technical feasibility with user needs and times activities so evidence arrives before key decisions. Progressive integration – initial expert work, then user testing – shifts mindsets toward human-centred choices and clarifies UX return on investment. Wireframes and other artefacts support communication across UX staff, developers, product owners and users. Clear differences emerge between groups. Participants involved in UX activities focus on process and user needs and increase their UX knowledge over time; participants not involved prioritise ROI, communication and resources, with knowledge remaining stable.

The study contributes a methodology and protocol to measure UX knowledge and surface barriers and opportunities to integration, a phase-based framework that formalises UX activities across the project and 10 recommendations for development and management teams linked to cybersecurity risks and benefits. Future work should replicate across multiple cases to test pattern consistency and refine guidance toward a theory of UX integration in cybersecurity.

The authors acknowledge the use of Large Language Models for language refinement. No AI tool or LLMs were used to generate or develop the content of this manuscript.