# NEC Digital Studio Playbook Made for Life Hello, and welcome to the NEC Digital Studio playbook. A playbook is a manual that describes a company or team’s approach and methods. So this is the one-stop shop for learning about what we do and how we do it. ## Who this playbook is for This playbook is for you, whoever you are. It is written by and for NEC Digital Studio colleagues. But we have made our playbook public because transparency and collaboration are really important to us. So if you’re a potential client or partner organisation, or someone thinking of applying for a job, you’re welcome to take a look around. Remember, if you’re looking for information on specific products then the [NEC Digital Studio website](https://necsws.com/digitalstudio/) is the best place to look. ## Updating the playbook As we evolve, our playbook evolves with us. It will grow with us as we take on new challenges and expand into new areas. What’s written here is how we work today, and as our ways of working develop we’ll update the guidance. Keeping the playbook up to date is the responsibility of all of us at NEC Digital Studio. If you have an idea for new content, or want to make a suggestion for how to improve our current ways of working, [talk to the strategy team](mailto:NECDigitalStudio@necsws.com) and help us bring it to life in these pages.
""
{% content-ref url="/pages/G44tLwgFVQJuhFl3P1i2" %} [Our accessibility statement](/capabilities/accessibility/our-accessibility-statement) {% endcontent-ref %} {% embed url="" %} {% embed url="" %} # The structure of a digital project At NEC Digital Studio, we deliver tailored projects in line with the [Government Service Manual](https://www.gov.uk/service-manual). Our projects typically move through 4 key stages: discovery, alpha, beta and live.
""

The diagram depicts the circular nature of a discovery (exploring the problem), alpha (understanding what works), beta (making it real) and live (keeping it going) in agile projects.

Our services offer clients the opportunity to use the full range of our capabilities to create something bespoke. We’re experts in researching user needs, designing a solution, building a product or service and running it in live. We can deliver complete end-to-end projects, or we can pick up specific stages across our range of disciplines to adapt to our clients’ needs. Because every client is different, so is every project. We’ll walk through a typical agile project delivered in line with the Government Service Manual. But in reality, we need to be flexible to meet our client’s needs. The playbook is here to offer guidance, but project delivery is not a prescriptive process. ### Discovery Before we can build a new product or service, we need to understand the problem we’re trying to solve. A discovery focuses on just that; what is the problem, and what are the opportunities to solve it? The priority during discovery is to understand the users and their requirements, the constraints upon people and technology and the opportunities for solutions. It helps clients decided what to do, as well as what not to do. Whatever we learn in the discovery should inform the alpha, if findings recommend the development of a product or service. {% content-ref url="/pages/ylmaP3NXiuoWBsmQm8BY" %} [Discovery](/projects/the-structure-of-a-digital-project/discovery) {% endcontent-ref %} ### Alpha The alpha is experimentation. The team creates and tests different solutions to the problem they identified in the discovery. Our time is spent building prototypes and testing them on different users. It should also be expansive, a time for trying new and potentially unconventional ideas in case they might be *the* solution. {% content-ref url="/pages/oMO9oRps1vSQihi9uLFs" %} [Alpha](/projects/the-structure-of-a-digital-project/alpha) {% endcontent-ref %} ### Beta Once we’ve identified the best idea, we start building it for real. We constantly test with small groups of users to get feedback on design and development and make changes. We think about how the solution could be scaled up and start running in the real world. An optional private beta (a small-scale test of the live service) may be run before the solution is ready for a public beta where it’s launched to all relevant users of the service. {% content-ref url="/pages/aHtAu90v903YjiLJ1dmE" %} [Beta](/projects/the-structure-of-a-digital-project/beta) {% endcontent-ref %} ### Live After the service is launched, the job is not done. We focus on iterating, continuing to drive improvements to functionality, accessibility and sustainability. When new or unmet needs come to light, they trigger further discoveries and development as we explore how to make the service better. Live is not just about iterating the product, it’s also about the support we provide to its users. Our dedicated support teams handle enquiries, system maintenance and incident management. They monitor the products and services we are responsible for 24 hours a day, aiming to resolve issues before they affect users. {% content-ref url="/pages/wwXSbWwdN1hIReVj6W1x" %} [Live](/projects/the-structure-of-a-digital-project/live) {% endcontent-ref %}
""

Design

""

Build

## Delivering in agile Traditional project management uses a waterfall method, where research is conducted to gather requirements, then a product is designed and built before being tested and released. It follows a sequential journey. Agile is overlapping activity. There’s still a sequential journey, but there’s a strong focus on continually adapting our approach as our client’s needs evolve. We often rely on the [scrum framework](/solutions/our-saas-solutions#bringing-products-to-life-with-scrum) to deliver our projects in an agile way. We start small in the discovery and alpha phases, expanding the prototypes as we learn more about the users’ needs. Usually in the beta phase, an idea becomes an MVP (minimum viable product) before growing into a more sizeable service with further features. It’s only once the data and feedback show the service is successful that it can go live. > “Agile methods encourage teams to build quickly, test what they’ve built and iterate their work based on regular feedback and other useful data.” \~ Government Service Manual It’s a less linear process than waterfall. Many steps are repeated time and time again as we adapt to feedback and align our priorities. But it makes sure we're delivering something that works, and is exactly what the users need. ## Adapting with the client At the heart of our processes is flexibility and iteration. There’s no one-size-fits-all approach. We adapt how we deliver to whatever our clients need, to best align with their programmes and ways of working. Whether we’re working with government, private sector or third-sector clients, we design the delivery, the tools and the methodologies around their needs.
""
# Discovery ## What's a discovery? Before we start to build a new product or service, we need to understand the problem we’re trying to solve. Then we can then address how to solve it. But narrowing down a solution is something we do in the alpha phase. In the discovery phase, we focus on the users and their needs. We also need to think about our client’s requirements. And finally, we need to think about considersations and constraints relating to the service, policy and technology.
""

The diagram explains the structure of a typical discovery. The process starts by making the project operational before planning the user research and recruiting participants. Then we concurrently conduct the user research to understand the user needs, understand the business requirements and understand the technical requirements. We create and iterate journey maps before finally producing a discovery report.

A discovery is typically made up of 3 to 6 sprints lasting 2 weeks each. Sprints follow a standard structure. We plan out our work, prioritise what we want to cover in the next fortnight, do the work, share our learnings, and reflect on what we’ve achieved and what we did to get there. This iterative structure repeats throughout every phase of delivery. It means our work is always focused where it’s needed most, and we’re constantly revising our plans based on the latest learnings. Our projects are delivered in line with the Government Service Manual. {% embed url="" %} ## What value does a discovery deliver to a client? A discovery clarifies a problem, measures its impact and advises if and how to address it. Clients come to us for a discovery because they trust in our ability to understand, define and refine a problem. And because we’re experts in people and systems. We approach user research with compassion and curiosity. We need to understand the users’ context and experiences so we can help to deliver better services for them. Likewise, we approach systems and technology with capability and understanding. We work with a variety of technologies, and are experts in mapping the existing systems and strategically planning for the future. As a result of our work, our clients understand their challenges better. They get a broad view of the context the problem exists in. And crucially they gain insight into the people who use their services and the staff whose job it is to provide those services. We recommend whether it is useful to proceed to alpha, and if so, what sort of solutions would be worth exploring. Our recommendations empower clients to make the right choices about whether and how to proceed into alpha and beta. A well-done discovery lays the foundations for a better product or service. ## What sort of team usually delivers a discovery?
Graphic depicting the team who works on a discovery with research happening with users and architects, BAs and designers collaborating on requirements
The team for a discovery will vary depending on the specific needs of a client. But these are the colleagues you could expect to work with: * researchers and designers, including [ReOps](/team/nec-digital-studio-team#research-operations) (research operations), [user researchers](/team/nec-digital-studio-team#user-researcher), [content designers](/team/nec-digital-studio-team#content-designer) and [service designers](/team/nec-digital-studio-team#service-designer) * [business analysts](/team/nec-digital-studio-team#business-analyst) who provide detail and insight into business requirements, processes and service data * [solutions architects ](/team/nec-digital-studio-team#solution-architect)who supports the discovery to explore the current technical landscape and make recommendations to inform potential future solutions. Project leads are senior practitioners within the team who provide a strategic overview. They’re also the main point of contact for the client. The project lead is usually supported by a [delivery manager](/team/nec-digital-studio-team#delivery-manager) who ensures the project is running well, to time and with the right resources. The client is the final, and most important, member of the project team. They are external to NEC Digital Studio and come to the project as a Subject Matter Expert (SME) to help our teams understand their organisation. They help make key decisions on the project, and later will be involved in prioritising work in our backlog. ### Capability key {% content-ref url="/pages/4DhhWbWPtdtMdDV249TY" %} [Research](/capabilities/user-centred-design/research) {% endcontent-ref %} {% content-ref url="/pages/hHqMJTCWEveOFrVmc8jO" %} [Design](/capabilities/user-centred-design/design) {% endcontent-ref %} {% content-ref url="/pages/aRGYsbpTdRYDdYzme0S8" %} [Technology](/capabilities/technology) {% endcontent-ref %} ## What do you need to start a discovery? Before the first sprint begins, the whole team gathers for a kick off. This gives them a chance to: * clarify project goals and timescales * align on how we’ll be working together * set clear roles and responsibilities * share our aspirations as well as concerns about risks * meet new team members and refamiliarise ourselves with existing colleagues Before the discovery properly kicks off, we review any existing documentation or research shared by the client. This helps us understand the service’s current context, as well as any existing thinking on future opportunities and requirements. Once that understanding is cemented, we can start to define the context and problem. A problem statement is agreed between our teams and the client. This makes sure we’re all on the same page, and that we’re addressing what the client really needs. For example, a client may feel they need an app to encourage more people to use their services. But in reality, the problem they need to solve is a lack of trust between them and the community. So our problem statement to address in the discovery would be: > *There is a history of mistrust between the service provider and its users. This is resulting in a low uptake of services that are designed to help the community.* An app might be the solution to that, but it might not. It’s our job to get to the bottom of what’s causing that lack of trust and how we might best address it. Starting a project with a narrow objective could mean you miss finding the best solution.
""
## What do we usually do in discovery? Now we know our focus, it’s time to dive in. Our [ReOps team](/capabilities/user-centred-design/research#reops-makes-a-world-of-difference) starts the vital job of recruiting the right participants. This includes users of the service, staff delivering the service and subject matter experts (SMEs) in the area we’re researching. Once the right people have been found, offered an incentive likea voucher (where appropriate) and scheduled, the research can begin. The research and design team, along with a business analyst, look to understand 3 main things: 1. **Business requirements and outcomes** – What does the client want to achieve? We explore how their business operates and any constraints associated with that. 2. **User needs and experiences** – What are the current needs and pain points of various users, from members of the public to employees of the organisation delivering the service? We document user needs taking accessibility into consideration. Once the research is conducted, we map out the user stories (what the user needs from the service) and user journeys (the steps a user takes through a service). 3. **System and wider services** – What things beyond the service have an impact on its delivery? This could include government policy or technical innovation. It is usually discovered through SMEs and desk research to make sure we’re on top of what’s happening in the service’s industry or community. While this research is underway, our development and technology team will be tackling the technical requirements and possibilities including: 1. **System diagrams** - Map out existing connections between different platforms 2. **Technology** – Scrutinise the current tech stack (infrastructure and applications that deliver the service) understanding opportunities and constraints 3. **Data** - Explore the quantity, quality, structure and security of the data Next, we bring everything together. We analyse and synthesise the research and technical considerations to come to a shared understanding. This means aligning systems, contexts, constraints and possibilities with user needs and business requirements. This holistic understanding allows us to identify and recommend the best opportunities to explore in alpha phase. ## What outputs would you expect from a discovery? The discovery phase’s main deliverable is a report that recommends whether a project should move into the alpha phase, and if so, outlines everything a team would need. We answer key questions including: * What is the problem that needs to be addressed? * Can it be solved by a service or product? * What do we know so far about the opportunities for or parameters of such a service? * What are the likely costs and benefits of solving this problem? * What technical constraints and opportunities should be taken into consideration? This is supported by specific information and artefacts such as: * User needs and stories * Service maps showing the current state * Business requirements * Potential alpha scope * Transcripts and documentation of all interviews * Technical review We may need to pass a [service assessment](/projects/service-assessments) before we can progress to an alpha. # Alpha ### What's an alpha? After we have identified the problem in a discovery, we turn our attention to a potential solution. The alpha is all about experimentation. We are expansive and broad in our approach, trying out different ideas to see what might work. We have a solid basis of understanding of the user needs, business and technical requirements, and we continue to build on that as we enter the ideation phase. Hypotheses are turned into prototypes (mock-ups of ideas) which we then test with users. Insights from testing help to refine our ideas and narrow down the scope.
""

The diagram explains the structure of a typical alpha. The process starts with reviewing the discovery report, maps and user stories. We ensure an understanding of technical requirements and then plan the user and business research. Next, we recruit participants for user research. This is then followed by an ideation phase, the creation of prototypes and testing them with users. User journeys and system maps are then refined before finally creating an alpha report.

We tend to work in 2-week sprints, planning, iterating and reflecting. Like a discovery, an alpha typically lasts 3 to 6 sprints. Our projects are delivered in line with the Government Service Manual. {% embed url="" %} ## What value does an alpha deliver to clients? An alpha delivers validated solutions that take the risks out of projects and inform effective future investment. Our clients know we deliver evidence-based ideas. We take a balanced view of user-centred and operational needs to help them make informed decisions for the new product or service. Part of our role is to advocate for the best solution. We work with clients to understand where they align and differ internally and help build a case for change, driving a stronger sense of ownership of the proposed solution. Thanks to the iterative process, we’re constantly amending our work to respond to our most recent findings. We test and course-correct as we go. This gives our clients confidence that what we deliver actually works, addressing genuine user and business needs. We often pursue multiple ideas at once. This gives us the best chance of finding the right idea. We bring clients on the journey with us, so they can show their stakeholders the value of the work we’re doing. This makes internal buy-in much easier. Alphas produce a clear scope to take into beta. That includes prioritised backlog and the technical plans to support the development. ## What sort of team delivers an alpha?
Multidisciplinary team working on planning and prototyping and user research
The team will vary slightly depending on the needs of the project, but typically we’d work in a team like this: * The delivery manager oversees the entire project. They’re responsible for keeping everyone else on track and liaising with the client. * The user researcher, business analyst, service designer and solutions architect will focus on the user needs and user journey mapping, as well as business and technical requirements. The designers create prototypes, then the user researchers and service designers test them with users so we can iterate designs along the way. * The client also plays a critical role. As in a discovery, they are a subject matter expert for the business and sector we’re operating in and keep us on the right path. In the alpha, they start prioritising the backlog with the team, ready for development to start in beta. ### Capability key {% content-ref url="/pages/4DhhWbWPtdtMdDV249TY" %} [Research](/capabilities/user-centred-design/research) {% endcontent-ref %} {% content-ref url="/pages/hHqMJTCWEveOFrVmc8jO" %} [Design](/capabilities/user-centred-design/design) {% endcontent-ref %} {% content-ref url="/pages/aRGYsbpTdRYDdYzme0S8" %} [Technology](/capabilities/technology) {% endcontent-ref %} ## What do you need to start an alpha? Like a discovery, before any work is done the team must first meet for a kick off. Client stakeholders and full project team meet to: * clarify project goals * set expectations for what will be addressed in the alpha * discuss aspirations, risks and opportunities * align processes that underpin the project and how we’ll work together Next, we take a deep dive into the discovery report. Even if we ran the discovery ourselves, there might be some colleagues who weren’t on that phase, who we need to get up to speed. If we didn’t run the discovery, this is a really important time to review the work that was done before our involvement. We check it was done to a high enough standard to allow us to successfully run an alpha and then we dive into the detail. This means we’re all on the same page about the problem we’re trying to solve, the context it exists in, the requirements of the users and the opportunities that have been discovered to help address the problem. Operationalising a project is a big step. We map out a timeline of activities and schedule [agile ceremonies](/solutions/our-saas-solutions#bringing-products-to-life-with-scrum) (like stand-ups and show-and-tells) to ensure collaboration between our teams and the client. We also set up: * a teams channel for communication * a SharePoint site for documentation * a project management tool like Jira to track our backlog and development * a prototyping tool like Figma, Axure or HTML to build digital prototypes in * a RAID log to track risks, assumptions, issues and dependencies * a design change log to track any decisions we’ve made with the client Then we’re ready to get into an alpha.
""
## What do we usually do in alpha? Following the discovery’s more general research into needs and opportunities, we probably want to conduct specific research to inform the design of prototypes. And depending on the quality of the discovery that was done before we started the alpha, we may need further research into the business and user needs. Either way, we’ll need to prepare for our ideation and testing phases which means we need to: 1. **Plan our research.** We plan the conversations we’d like to have and the types of users who would have the best insight. That lets our ReOps team hit the ground running with participant recruitment. 2. **Prepare the research materials.** Materials include everything from tools to help stimulate conversation to important documentation we have to complete for GDPR. For example, that might be discussion guides or consent forms. 3. **Prioritise user stories.** The designers, user researchers and business analysts work with the client to map out user stories and user journeys to prioritise them. To do this, we look at the various needs that have been identified and plot them out in a map that shows the order in which those needs occur. Part of that process is identifying the riskiest and most complex journeys so we can test them. 4. **Understand technical requirements.** Part of exploring the options to address our problem statement is considering their feasibility. That’s where the solutions architect comes in. Their job is to work with us to make sure that the plans we’re considering are efficient and make good sense technically. Once we’ve got some potential solutions to the problem, we need to test them with users. To do this, we create a low-fidelity prototype. It's a simple sketch of an early-stage design concept. Our research and design teams use them to quickly test ideas and identify potential issues, learning from and moving on from versions that don’t resonate with users. We take these prototypes to users to test their usability, accessibility and how well they fit into the wider system that users experience. With each round of new insights, we iterate the designs and refine them to better address the problem we’re trying to solve. As we progress through an alpha, we create more functional and interactive prototypes that get closer to representing the final solution. ## What outputs would you expect from an alpha? By the end of an alpha, we’ve narrowed down our ideas to a single solution that we can bring to life in beta. We know which solutions suits our client, their users and the technical and financial constraints of the project best. But what details do we need to support that? The alpha report is a comprehensive report that outlines all the learnings and proposed solutions. It’s the best tool to help the team prepare for beta. It includes: * **Product direction** – the best solution to answer the problem and the proposed scope of a future beta * **‘To-be’ user stories, storyboards and prototypes** – documenting what we understand the users’ needs to be in the proposed service and the expected experience of going through the proposed solution, as well as any artefacts that might be directly reused in a future beta * **Diagrams and service blueprints -** outlining how elements of the service fit together and deliver the proposed experience * **Prioritised roadmap and backlog** – user stories have been prioritised so when the beta starts there are clear steps to delivering the solution * **Documented technical requirements** – the technical architect has worked alongside the design teams to make sure any proposed solutions have been vetted and are feasible * **Insights from research and recommendations from testing** – knowledge of where users have experienced problems and whereto focus future testing * **Transition plan** - how to decommission the existing service, if there is one, and launch the new one when it’s ready * **Sign off from the client** – crucial evidence that the job has been done to a satisfactory standard and the client is ready to progress to the next delivery phase We close down an alpha with a final show-and-tell with the client. Normally we have a larger number of stakeholders from the client join us than for the regular show-and-tells at the end of each sprint. We cover the alpha findings and get sign off that the client is happy with the work we’ve done and the direction for a beta. For government projects, we may need to pass a [service assessment](/projects/service-assessments) before we can progress to a beta. Then we’re ready to start building. # Beta ## What's a beta? Now we’re ready to take our best idea and start building it and using it for real. The beta phase breaks down into: * creating a service * testing it with a small group of users * running it publicly for further feedback and improvement. A beta is where we see our full digital project delivery team working together. We have researchers, designers, business analysts, architects, software developers and testers all collaborating to deliver for the client. We generally work in sprints, 2 week-long planned and prioritised chunks of work. But the format is slightly different to a discovery or alpha. In a beta, there are a number of different tracks running in parallel: design, analysis, development and testing. And usually, our analysis and design teams are at least one sprint ahead of development.
""

The diagram explains the typical structure of a beta. The process starts with with prioritising features and planning upcoming sprints. Then each feature goes through a cycle of designing and prototyping the user interface, setting up the technical architecture, creating the business logic, testing the designs and prototypes with users, handing over assets to developerswho develop the solution which is then quality assurance tested. The solution then goes through user acceptance and usability testing before it is ready for a private beta launch to a small number of users and finally a public beta launch.

The research and design teams create prototypes and test them with users, while the technical teams set up the architecture and infrastructure to support them. The designs are handed over for development and testing while the design team moves to designing the next feature. The beta process can vary in time, depending on the client’s requirements and project deadlines. We continue to work until we have a product that’s ready to launch. We consider how the solution will scale and be supported when live. This might mean creating a plan to replace the existing service, or it might be paving the way for a new service to launch successfully. Both need change management and service support capabilities, so it’s all hands on deck to bring the service to life. Our projects are delivered in line with the Government Service Manual. {% embed url="" %} ## What value does a beta deliver to clients? While an alpha is all about experimentation, a beta is about building and testing the actual solution. Because people begin to use the actual service, the beta phase confirms that it works well in context. It allows further iterations to be made, based on real-world use. We create a Minimum Viable Product (MVP). This is a basic version of the product, that can be tested to prove the value of the service. It can, but doesn’t need to, be launched to the public. Often the beta that is launched goes beyond MVP functionality. Its value is to test the service with real users for real feedback. This is done initially through a private beta, available to a limited audience, where any issues discovered pose less risk than when the service is launched at scale. It’s also an opportunity to engage with early adopters and build advocacy for the service. When confidence is high enough, a public beta is launched. This exposure to the full audience brings in additional insight around potential improvements the service. In some projects, the client chooses to go straight to full launch. Moving through the beta phase validates our assumptions while testing performance against scalability. We minimise risk and maximise potential by constantly seeking to learn from and iterate the service. ## What team delivers a beta? The design track team members will be familiar to us, having gone through a discovery and alpha already. The user researchers, content designers and interaction designers all work with the business analysts (BAs) to keep the design track progressing. We also have an accessibility specialist to make sure the products we’re delivering are accessible for all users.
Cartoon depicting a multidisciplinary team working in a beta
The development track introduces a new team: * Software developers - write the code * Quality assurance (QA) testers - make sure the system behaves in exactly the way it’s meant to * Devops - responsible for supporting the environments where the code lives * Technical architects - pick up the work of the solution architect, who did a high-level review of the requirements for the solution in alpha. The technical architect has the responsibility of mapping in detail exactly what technology will be used, how it will be used, and what it needs to connect to. They produce high and low level designs that the infrastructure and network engineers require to build the hosting environment for the application. All of this is overseen by a delivery manager and scrum master. * Delivery manager - runs the project, directs resources, reports on progress, manages risks, keeps the project objectives clear and is the main point of contact for the client. * Scrum master - keeps the development team organised and progressing the deliverables that have been agreed. They’re also responsible for guiding the team through the [scrum process](/solutions/our-saas-solutions#bringing-products-to-life-with-scrum), ensuring ceremonies take place, artefacts are produced and resolving any blockers. Depending on the size of the project, the delivery manager and scrum master roles may be performed by the same person. The client plays a vital role throughout beta. They define the project’s goals and objectives, provide subject matter expertise, help to prioritise the backlog and assist in sprint planning. Having the client so closely involved ensures that product decisions best reflect the organisation’s goals. ### Capability key {% content-ref url="/pages/m61pEpuhAx94DV0AtqTs" %} [User-centred design](/capabilities/user-centred-design) {% endcontent-ref %} {% content-ref url="/pages/aRGYsbpTdRYDdYzme0S8" %} [Technology](/capabilities/technology) {% endcontent-ref %} {% content-ref url="/pages/0zx1KjlpRvsu1GsN8Ik4" %} [Development](/capabilities/development) {% endcontent-ref %} {% content-ref url="/pages/wWwGNSl9OtduKoLr8M7Q" %} [Delivery management](/capabilities/delivery-management) {% endcontent-ref %} ## What do you need to start a beta? As with all delivery phases, we start with a kick off session to establish ways of working. We confirm roles and responsibilities, how people like to work and the ways in which we’ll need to flex our project delivery style to meet the needs of the client. Then in sprint zero, we have 2 key objectives: sign off on project readiness and start planning and prioritising the work. To sign-off on project readiness, we have to review the quality of the alpha completed earlier. This is particularly important when another supplier has done the discovery and alpha work before us. The business analysts, designers and the solutions architect check that we have everything needed to start the betaas planned without changes to the scope or budget. If any changes need to be made, they should be done before any beta phase design or coding has started. Once approved, we define a plan for how to deliver the project within time and budget. For each feature of development, we estimate the effort that will be required and make a decision on its overall approach. For example, if we should code the functionality, licence existing services, or use Open Source components. All of the work we will be designing and coding ourselves is put into a sprint plan according to time, budget and logical technical order. With a high-level plan complete, we’re ready to enter sprint one.
""
## Building the service ### Design track Each design sprint starts with a detailed sprint plan which prioritises the features we’ll address based on what’s necessary for the MVP, the time and budget available and any external pressures. We also clarify the technical approach to make sure we’re using the most efficient and appropriate technical solutions possible. With each feature we build, we create low fidelity prototypes (the minimum functionality and visual elements needed to share a concept). They are sense-checked with the development team to confirm they follow the technical designs covered in project planning, and with the client to make sure we’re delivering what they need and expect. After we’ve signed off the low fidelity designs, the designers can start creating high fidelity prototypes. These include the full functionality in a high fidelity user interface. The user researchers then carry out usability testing on the prototypes with end users to make sure the system works easily and in a logical way. All findings feed back into the designs as we continually iterate and refine. At the same time, the business analyst works with the software developers to create detailed process maps showing the required business logic for any given feature. They map out what the system should do so the developers can break the work down into components. They also make technical decisions on data and its formats and characteristics in the system. As part of the handover to development, both the technical and user-centred design requirements are documented. Specific outputs from the design track are pulled together to support the user stories that form the product backlog including: * designs (in Figma) * design documentation (in Confluence) * data characteristics * business logic and rules * process maps ### Development track Similarly, the first thing the development team does in each sprint is sprint planning. They agree how many prioritised tickets can be addressed in that sprint, and the scrum master facilitates how the work will be managed. The software developers work on the prioritised stories, writing code to bring the ideas to life. The QA team check the stories meet the acceptance criteria ensuring the overall quality of the development. And the business analysts check that we’re still meeting the original business and user need we set out to address. As the testers identify bugs, triage sessions will take place to review and determine a priority. Depending on the priority, work can either be assigned back to the developer for immediate action or placed in the backlog to be picked up at a later date. In each sprint, our teams showcase what they have designed and developed to both internal and external stakeholders. The show-and-tells are a great opportunity to share what’s been achieved, sense-check it with the client and get buy-in for the project as a whole. It also gives us the opportunity to address any challenges that might arise. The [integration of our design and development teams](/projects/how-research-design-and-development-collaborate) is crucial to the successful outcome of a project. ### User testing track In addition to QA testing, we also run both User Acceptance Testing (UAT) and usability testing. UAT is the client’s opportunity to check the software does what it was designed to do in real-world situations before the service is launched. We work with the client and specified users to check the application's functionality and that it fits into the client’s wider business processes. Usability testing makes sure the product is intuitive and easy to use. There’s no point having a perfectly functioning system if no one knows what button to push when. Most of this will have already been ironed out in the design track, but it’s always good to check the end product works well for the user too. Testing the coded work also allows users to experience and assess the whole service, rather than just being exposed to bits at a time as part of the earlier design testing. After it’s passed all the tests, the code is ready to be pushed into a live environment.
ALT=""
## Running the service Once the service is built, it’s ready to be tested as a whole by real users. There are 3 major milestones that are usually met by the end of a beta; a private beta, a public beta launch and agreement that the service is ready for the live phase. We might be commissioned to do both, or the client might prefer to move straight to launch. * **Private beta.** Once the system is fully coded, it can be launched to a live environment. But you don’t have to make it live for everyone. A private beta is the opportunity to launch the new service to a smaller subset of the user base, to test and iterate it before the big launch. As clients and their users identify any problems and potential improvements in the service, these are prioritised and addressed by designers and developers. * **Public launch.** We’re finally ready to make the service live. That problem we started off exploring back in a discovery has a solution that is ready to be launched to the public. This is a full-scale launch, with all relevant users onboarded and training and user guides provided to the client. * **Ready to move to live.** The project team sign off that the service is working well enough in beta that it can move into the live delivery phase. Everything required to do this is documented in the beta report. ## How to move from a public service in beta to the live delivery phase When the service is running in beta, we provide additional support to users. Public beta is where any real-life issues might come out in the wash, and we’re on hand to fix them. If it’s a bug, then it’s shipped back to development. If it’s an enhancement, it goes through prioritisation and approval processes with the client before being sent to our design track. Depending on what’s been agreed with the client, we will run the public beta for a set period of time with support from both the project team and live team. We are on hand while the client’s live team settles in before they take over the running of the service in [the live phase](/projects/the-structure-of-a-digital-project/live). However, it might be that we’re commissioned to run the service in live. Or there might be another organisation trusted to run the service. Either way, the most important thing for moving into a live stage is clear and accurate documentation. This will be collated in the beta report which includes: * **Cloud architecture** – details of infrastructure and services * **Deployment and rollback procedures** – the deployment strategy, including how updates are rolled out and rolled back in the event of failures * **System requirement specifications** – including functional and non-functional requirements as well as configurations * **Operational support documentation** – details on monitoring, logging calls and system alerts * **Service Level Agreements (SLAs)** - specifying metrics such as uptime, latency and support response times We also provide technical training to support the systems we’ve built. And finally, there will be a prioritised backlog of work that can be addressed in the live environment. In some instances for government projects, we may need to pass a [service assessment](/projects/service-assessments) reviewing everything above before we can officially progress to the live delivery phase. # Live ## What is the live delivery phase? When we say we support products and services in ‘live’, we mean that we are supporting the running and improvement of a service for our clients and their users. It is the constant evolution of a living, breathing service that is live in the real world. It’s the final step in the [Government Service Manual](https://www.gov.uk/service-manual), following a discovery, alpha and beta. We support the platforms and infrastructure that enable our clients to run services in a business-as-usual capacity. Our work revolves around the delivery of a roadmap, a reflection of user requirements, technology advancements and political or societal change. Working with the client, we prioritise the roadmap and schedule work in line with the budget. Each new feature will be researched, designed, developed and tested before being launched in the live service.

The diagram explains the structure of a typical live cycle. We create a raodmap and then prioritise features, tasks and plan the release dates. To fulfill these commitments, we conduct user research for the chosen feature, design the feature, develop the feature and run quality assurance and usability testing. Once it is ready, we launch the feature to the live product.

{% embed url="" %} ## What value does it deliver to the client? Clients rely on companies like us to support their live products and services because it makes their lives easier. We take on the responsibility of keeping the system running smoothly, providing user support and future-proofing the roadmap. We fix problems and proactively make the product better. Our clients value having a hands-off approach, knowing they have no day-to-day responsibilities and can trust the delivery of the service. And we offer more than the product itself. It’s not just bug fixes and product enhancement. It’s about integrating ourselves into our client’s work to understand their wider organisation and impact of our products. In doing so, we fuel innovation and provide better support. ## What sort of team supports a live service? Whether we’re supporting a client’s live service or delivering our own Software as a Service [(SaaS) solutions](/solutions/our-saas-solutions), the team is very similar to the earlier phases of project delivery. Our [research](/capabilities/user-centred-design/research) and[ design](/capabilities/user-centred-design) teams inform and shape the designs that our [development](/capabilities/development) teams bring to life. Every new piece of functionality is like a self-contained discovery, alpha and beta where ideas are researched, tested and built in an iterative and agile manner. For our SaaS solutions, the [product manager](/team/nec-digital-studio-team#product-manager) works with the clients to understand what they need and get feedback on the product. They decide the strategic direction of the product based on customer feedback, sector insights and improvement through innovation. The [product owner](/team/nec-digital-studio-team#product-owner) is the gatekeeper of development, translating the needs of the roadmap into requirements for the development team to build. They work with the product manager to agree what should be included in the roadmap and prioritise the work that needs to be done first. They weigh up profitability and business impact to decide on the best solution.
### Capability key {% content-ref url="/pages/4DhhWbWPtdtMdDV249TY" %} [Research](/capabilities/user-centred-design/research) {% endcontent-ref %} {% content-ref url="/pages/m61pEpuhAx94DV0AtqTs" %} [User-centred design](/capabilities/user-centred-design) {% endcontent-ref %} {% content-ref url="/pages/0zx1KjlpRvsu1GsN8Ik4" %} [Development](/capabilities/development) {% endcontent-ref %} ## What happens during live? ### Delivering a roadmap Each live product and service has a roadmap. It sets out the intention for that product and the timescales for getting there. It’s based on a pipeline of work that needs to be done. All future development will be planned and prioritised based on the existing pipeline. Development work may include: * **Bug fixes.** As with all technology, there will always be bugs. Sometimes the client spots something that doesn’t work quite as intended, and other times we spot it. The code then needs to be updated, which has to be planned and accounted for. * **Technical debt.** As soon as code is committed, it starts to age. This process is a fundamental part of the software development lifecycle. Over time, this legacy can start to become burdensome and affect application performance and the overhead of support. It’s important to keep on top of the technical debt, re-factoring and refining code to ensure optimal performance and sustainability. * **Enhancements.** This focuses on the functionality we can add to make the product better. We might have identified an opportunity to automate a process, or a customer may have suggested a tool to help them do things more efficiently. We build changes into the core product to meet that need. * **Innovation.** Making a product better isn’t only about small incremental improvement. We take advantage of our [innovation laboratories](https://www.neclab.eu/) around the world to identify technologies to solve problems we couldn’t previously solve and offer our clients a new and better way of doing things. Examples of this would be the significant advances in generative artificial intelligence and biometrics, fields in which NEC is a global leader. These have allowed us to change some of the fundamentals of our products in ways that radically improve their value to our clients. Our development teams deliver all of the above, with solution architects, data scientists and designers feeding into enhancements and innovation. The development teams rely on the product owner and product manager to prioritise the work and put it in a logical order. It’s the scrum master’s job to make sure the team knows exactly what to deliver and by when. We use Jira, an agile work management tool, to track the changes, status and owner of all development.
A cartoon view of a Jira table, depicting different development examples classified by release, title, type of development, RAG status, owner and due date.

A Jira roadmap

### How we work We adapt our ways of working to fit how the work was commissioned. Clients may ask us to work within the [scrum framework](/solutions/our-saas-solutions#bringing-products-to-life-with-scrum). Scrum is time bound, set in sprints with specific ceremonies that are typically repeated in 2-week cycles. The development that happens in that time is also time-bound and focuses on iterating with every cycle to learn from the last. Sprints are planned, with care being taken to add the right amount of work into the sprint, taking into consideration the estimated effort for each item and the resources available within the sprint team, We employ standard agile ceremonies to keep stakeholders informed and receive feedback, including: * **Daily standups** with the team, and often the client too, to review the previous day and ensure each team member knows what they need to do and that they have the resources and support required to achieve it * **Show and tells** at the end of a sprint to present what has been achieved and listen to client and colleague feedback * **Sprint retrospectives** for the internal team to review what went well, what didn't go so well and what to do differently in the next sprint Some of our clients prefer us to work in kanban rather than scrum. Kanban is not timebound in the same way as scrum, it is simply a list of things to do that are picked off one-by-one by the development team. Kanban translates from Japanese to mean “signboard” and can be pictured as such, with cards for each element needing to be developed. For our own SaaS solutions, our teams follow the scrum framework, working in specific sprints and following standard agile ceremonies. The scrum master, product manager and product owner work together to prioritise the roadmap and support the development team to bring our roadmap to life and make sure we meet our service level agreements. Regardless of *how* we implement the work, *what* we deliver is constant improvements. Our ambition is to deliver systems that are smarter, safer, seamless and more sustainable. ### Supporting our clients We have service-level agreements (SLAs) with our clients. These are typically contractual agreements regarding the quality and availability of a service. We have dedicated support teams monitoring performance, and intervening if they need to. Our front-line support, where we receive and log calls, goes through the NEC SWS helpdesk into our service management system. It’s then categorised and handed over to the NEC Digital Studio teams for second-line support for detailed triage, technical assistance and advice and guidance. In some instances, it will then be referred to third-line support for the development and infrastructure team to review. Some clients prefer to run their own front-line support to triage calls before they are assigned to us. In those cases, we integrate with their systems and processes to ensure we offer seamless support for end users. ### Training the users To help clients get the most from our products, we offer ongoing training as part of the live phase. Fully trained staff use the services better and more efficiently. They also tend to be more invested in its usage and better able to contribute to its improvement. We can provide train-the-trainer training (where we upskill someone to pass that knowledge on within an organisation) as well as end-user training to larger groups. Our training can be run face-to-face or virtually, depending on the client’s need. The training also includes supporting documentation, like training guides, how to guides or videos. And it’s always run by professional dedicated trainers who are experts in delivering these sessions, so our clients receive the professional support they need, in the way they need it. And if clients aren’t sure what support they need? We run training needs analysis with them to explore what they want to achieve and how best to get there. We’ll talk to stakeholders, run surveys and pull together a proposed training plan so our clients have confidence in what they’re buying.
""
## Retiring a service All things end, eventually. Contracts are not renewed and products are retired to make way for something better, or because the need for them has diminished. Where we support a service on behalf of a client, and they own the intellectual property, they may choose to use a different supplier. Where this is the case, we follow the agreed off-boarding process to handover to the new supplier, upskilling their team as required. When closing down a service, we work with clients to: * **consider user needs** – how will their needs be met after the service is retired? * **tell users** – how to communicate the change and help people through the journey? * **make a plan to redirect traffic** – when the service is retired, are users being redirected to a replacement service? And if not, what support can we provide? * **protect information** – what is the plan to secure the information that has been stored and processed during the running of the service? {% embed url="" %} # How research, design and development collaborate There are many benefits to close collaboration between research, design and development. Working together allows us to take the risks our of projects and lets us spend budget where we can make the most impact in the time available. Our researchers and designers help the team understand exactly who we’re designing for and why. We plan and review the design, architecture, and development together. So what we create is effective for users, as well as being technologically feasible and efficient. For our clients, collaboration means we deliver better value for money. The delivery manager has a clear view of the expected team workload and can prioritise the areas where we’ll deliver the biggest impact. This helps to improve our working relationships too. And finally, it’s good for us. It’s good for morale. We all feel more involved in the decisions we’re making as an organisation. We understand them better and that equips us to deliver better work.
""
## What does collaboration look like? ### Planning our approach When opportunities for a service are being explored, we need to understand the user needs, business requirements and technical landscape. In addition, we take into account other factors such as the political landscape around the service, retirement of any existing service, approach to accessibility, and possibilities for roll-out - including training. We work together to consider these factors as we plan projects and propose solutions. Before we dive into the designs and development, first we assess the technical constraints, possibilities and approach for the full service before going into the detail on each individual feature. The solutions and technical architect will gather with the lead researcher, designer and developer to ask the following questions: 1. Is this functionality best created through: 1. bespoke code (where we start from scratch) 2. reusing existing code we’ve developed on a different product of ours 3. licencing existing services 4. using OpenSource components for specific functionality? 2. If we are writing bespoke code, how feasible is the challenge within the time available? We need to know if this is something we can and should be building. And if we are building it, what technology do we need to support it? 3. What's the best way to approach the user or business need? The software developers might have a suggestion for how those needs could be met in a simpler or easier way. While this planning is going ahead, the solutions architect takes a strategic look at the infrastructure that supports these elements and how it fits into the bigger picture. This way, we don’t develop something we can’t support further down the line. With the approach confirmed, we can move into design. ### Feedback on designs When the design team have finished the low fidelity prototypes (the minimum functionality and visual elements needed to share a concept), we sense-check those designs with the wider teams. The researchers and designers host a meeting with the architects and development to share the prototypes and collaborate on their progress. They talk through what they have designed, and how it addresses the business requirements and user needs. The architects and developers review what it would take us to deliver these plans. This gives the designers the opportunity to address challenges, revisit the design and make realistic plans for the next sprint. As we progress through the different phases, this moves from a high-level overview of the full service into more detailed features. Once we’ve reached an agreement, the designers create high-fidelity prototypes for the user researchers to test. The business analysts interrogate the plans to make sure they meet the client’s needs. The prototypes will go through various iterations as feedback is built back into the designs. This is a good opportunity to share the prototype with the client. If they're happy with a feature, they can sign it off. If the feature isn't quite meeting the user needs, the client may choose to deprioritise it and put it in the backlog to be revisited at a later date. ### Feedback on development With the current design phase signed off, it’s time to hand over to development. In a prioritisation session, we review the designs and break down the project into deliverables. That work is divided into sprints, and the development can begin. We run show-and-tells at the end of every sprint to show the progress we’ve made. This presentation is to the internal team working on it as well as the client. It’s a great touchpoint for a progress update from development and for the researchers and designers to review how the plans are being brought to life. The client reviews the feedback from the most recent sprint, including usability testing and quality assurance testing, and prioritises future requirements according to what will make the most impact in their organisation. Based on that rating, the requirements move into internal project planning to progress through the design and development sprints accordingly. Once a deliverable is completed, we’re ready for the next one. ### Periodic touch points It’s not just the regular meetings in our sprints that are important. As well as regular weekly ceremonies and status reports, we also have monthly check-ins for the project as a whole. We assess if we’re running to schedule and budget, and adjust the plan if we need to. If we spot areas where we can save time or money, we raise them here. For example, that might be a less feature-rich design in a low priority area. This is a good opportunity to step back from the project and assess how we’re doing, where we can improve and how to make those improvements.
""
# Service assessments When working on services for central government clients, it’s likely each delivery phase will need to pass a service assessment to progress to the next stage. It measures a service against the 14 points of the [GOV.UK Service Standard](https://www.gov.uk/service-manual/service-standard). The peer-reviewed assessment takes roughly 4 hours and will be run by a panel of experienced specialists, from user researchers and designers to technical leads and performance analysts. They will assess: * why you’re solving the problem you’re solving * who your users are and what they’re trying to do * the work you’ve done to understand the user’s wider journey * what you have built (where applicable) * the user journey through your solution (where applicable), including assumptions * how you have met the requirements of the Government Service Standard After the assessment, the panel will award you with a green, amber or red result. * **Green** means you have passed and can continue to the next delivery phase * **Amber** means that standard has not been met but issues are not critical. The service can continue to the next phase while these issues are resolved * **Red** means that there are critical issues, and your project must remain in the current delivery phase to resolve the issues ## Tips from our team When preparing for a service assessment, you should refer to[ the Government guidance](https://www.gov.uk/service-manual/service-assessments/how-service-assessments-work). But here are some top tips from our team: 1. Document your processes and the rationale behind your actions 2. Record key decisions made throughout the project to support evidence gathering at the end 3. Justify the team you’re using and the value they’re adding to each delivery phase 4. Think about the best way to tell the story and show the work you’ve undertaken during this delivery phase 5. Be prepared for questioning. Your team needs to be able to respond confidently to any questions asked on the day 6. Book the assessments in advance. They can take 6 to 8 weeks to schedule in, so don’t let it hold up the process by booking too late 7. Make sure you have strong representation from your multidisciplinary team at the assessment. This allows the panel to hear directly from experts across various disciplines and ensures that a diverse range of questions can be addressed effectively 8. Before the day, feel free to reach out to the lead assessors in the government department you’re working for. They’re very receptive to questions and can give you guidance and support about the assessment 9. Each government department can do things slightly differently. Try and find literature on the assessments and how they’re run. 10. And lastly, try and relax. The service assessment panel are there to support you and are willing you to succeed
""
# User-centred design Research and design explore the complexities of a problem, create a solution, and help to deliver it. At the core of our approach is user-centred thinking. That means putting the user’s needs at the centre of the design process. Everything we do makes a product or service easier to use and deliver which means better results for the people using it and the organisations delivering it. There is no one way to design products or services. And that’s partly because our clients and projects vary enormously. Our work varies from designing products for the probation service to redesigning volunteering for the Scouts. We’ve transformed eye care delivery in the NHS and redesigned how the V\&A welcome their visitors. At the heart of it all is our robust and ethical research, which helps us understand the people and organisations we're designing for. To deliver great results, we work using an iterative process. We explore different opportunities, develop compelling stories for change, and work with clients and users to test and refine ideas to deliver the right results. Our work in user-centred thinking is a combination of research and design. {% content-ref url="/pages/4DhhWbWPtdtMdDV249TY" %} [Research](/capabilities/user-centred-design/research) {% endcontent-ref %} {% content-ref url="/pages/hHqMJTCWEveOFrVmc8jO" %} [Design](/capabilities/user-centred-design/design) {% endcontent-ref %}
""
# Research User research is the systematic collection and communication of evidence to make sure we design the right products and services in the right way. We use it to advocate for users, so their voices are included in design and business decisions. This reduces risks and avoids revisions further down the line. There is a process, skill and nuance to delivering reliable, actionable and informed insights. We look at everything from why the user needs the service to what blockers they might be facing to access it. Our job isn’t just to present the evidence. We work closely with product teams and designers to support, inform, strategise, and continually represent the users.
""
Learn more about our research operations team and how they underpin our research practice: {% content-ref url="/pages/KWJV83kg184fvb8C6uFZ" %} [Research operations](/capabilities/user-centred-design/research/research-operations) {% endcontent-ref %} ## Our approach ### Ethical and holistic research It’s critical that user research is practised ethically. And that means being inclusive and accessible by default. We make sure a broad spectrum of users is heard and understood so that our products and services work well for everyone. As we conduct research, we build in strong safeguarding and wellbeing precautions to protect the participants and our team members. We take a holistic approach to research. Informed by our service design heritage, our user researchers consider wider systems and end-to-end journeys. It’s not just a snapshot, it’s the bigger picture. This equips our teams to take a well-informed strategic approach to the challenge at hand. ### Rigorous processes Our research takes 3 main approaches: qualitative, quantitative and mixed method. * **Qualitative research** uses interviews, workshops and typically smaller scale data collection to understand users, their context and their experience. Qualitative research often questions why people do things, to uncover deeper meaning and underlying needs. In general, it’s more explorative and less structured than other kinds of research. * **Participatory research** methods include observations, shadowing, self-completed work like video diaries and co-design processes like workshops. They can be done in person, online, individually or in groups. This allows us to engage a more diverse set of users to get a greater depth and context of understanding. It is underpinned by the belief that those affected by something have the right be involved in the design of it. * **Quantitative research** uses surveys and large-scale data collection to measure and validate people’s experience, attitudes or behaviours. * **Mixed method research** allows us to understand the breadth and depth of a topic by combining qualitative and quantitative methods. We differentiate ourselves through our strong focus on the rigorous analysis and synthesis of qualitative data. In fact, we’re the only design agency offering training in qualitative analysis for user researchers. We’ve honed a robust process for interpreting data by finding patterns and looking for underlying meaning.
""
### Informed collaboration Our [design school](https://necsws.com/digitalstudio/design-school/) allows us to work better as a team. We all regularly attend our own courses to share and embed learning across the organisation. This gives our researchers a broader understanding of other user-centred design practices at NEC Digital Studio. In return, colleagues from across the business attend training on user research. This approach enables us all to integrate into each other’s work more effectively and efficiently, boosting the value that we deliver to clients. Our learning ethos extends to clients as well. In addition to understanding our findings and recommendations, many clients value the chance to build their understanding of how great research is delivered. So we involve clients in our research processes. This collaboration not only gives them a richer understanding of findings, but builds their own capabilities around research. The tools and materials from our training programs are available or us to draw on, to help upskill clients on user research methodology. ## See our work in practice
Exploring a new digital school-age childcare service in ScotlandThe Scottish Governmenthttps://necsws.com/digitalstudio/case-studies/exploring-a-new-digital-school-age-childcare-service-in-scotland//files/4auTWCOXKgcyQTNbrrAA
Exploring interventions to improve homelessness prevention serviceLondon Borough of Newham https://necsws.com/digitalstudio/case-studies/homelessness-prevention-services//files/I8JTOKrebL6ApHidxHXU
Understanding barriers to childcare in rural ScotlandThe Scottish Governmenthttps://necsws.com/digitalstudio/case-studies/understanding-barriers-to-childcare-in-rural-scotland//files/EVlWdDhsHN2qMbNBTVOi
# Research operations Our research operations (ReOps) team provides the tools and processes needed to support researchers in delivering and scaling their impact across our organisation. Research operations specialists aren’t common in the sector, and we know they make a world of difference to what we deliver. The ReOps team focus on the people, mechanisms, and strategies that set user research in motion. Their work at NEC Digital Studio matures our practice in the following areas: * **Ethical standards.** ReOps provide structure, guidance, and support to achieve the highest ethical standards, for the protection of both participants and our researchers. * **Data compliance.** The team also provide guidance and support about data management, ensuring we’re compliant with data regulations and protect participants data. * **Participant management.** ReOps are specialists in identifying, locating and inviting people who can best represent the ‘user’ in the topic we’re researching, and doing this in an inclusive way. * **Tools and logistics.** The team ensure we have the right tools in place to conduct research activities whilst managing logistics, to promote team efficiency.
""
# Design Our focus is the design of products or services for governments, health care organisations, police forces, charities and more. So the projects we design range from helping to diagnose respiratory disease to guiding users through the probation service. Whether offline or online, we strive to create services that address genuine user and organisational challenges. So we take a broad look at what users need, the systemic issues around a service and where the best opportunities are to deliver change. At NEC Digital Studio, we have experts across 3 different design disciplines: {% content-ref url="/pages/ZmydbmeM88fsjwiotfy0" %} [Service design](/capabilities/user-centred-design/design/service-design) {% endcontent-ref %} {% content-ref url="/pages/8U4a1TbxsiJkqQPIEbR4" %} [Interaction design](/capabilities/user-centred-design/design/interaction-design) {% endcontent-ref %} {% content-ref url="/pages/6rsOi1w6RIJDrhDwfqcr" %} [Content design](/capabilities/user-centred-design/design/content-design) {% endcontent-ref %}
""
## Our approach ### Mindset, not process Our mindset is always user first. We involve them early and we rely on robust research to understand their needs. Our approach, however, can differ from project to project. We might use different tools to make things clear to different clients, like a prototype, a diagram, a storyboard, or a journey map. They help to drive effective conversations and tell compelling stories. But because no 2 projects will ever be the same, we adapt to find the right approach for each client and their users. ### Collaborative design Design should always be collaborative. We work in partnership with our clients and their users to find practical solutions that work well for everyone. Our best work is achieved through building strong relationships. So we talk, and more importantly, we listen. We’re the glue between an organisation and its users. Having clients intimately involved in our work has many benefits. It removes risk because they are invested in the process and outcomes from the start. It also means the services we create stand a better chance at being implemented and adopted. Another benefit is the knowledge transfer to clients. We share our expertise, ways of working and resources. And in turn, they build capacity in their teams to develop services with the user at their core. The purpose of designing with the users is to empower their voices throughout the process. We involve the users as early as possible to shape the product or service into something they can and will use. ### Critical friends We tell our clients what they need, not what they want to hear. We challenge when we believe a better choice could be made. And our clients value us because we take them where they need to go. > “The team were a delight to work with and added real value and a positive challenge to our own ideas and experiences.” \~ Katie Miller, Volunteering Transformation Manager, The Scouts Working with users and organisations, we often uncover misaligned needs. Our job is to translate those needs in a way that can be understood by everyone and provide the wider context. Equipped with better information, we help clients to come to agreement on the best and most informed solutions. ### Outcomes, not outputs When designers talk of design, they often mention blueprints, journey maps, and personas. Sure, these artefacts can be important, but the real value is the conversations and decisions they facilitate. It’s about clarity and consensus, not just maps. ### Design for good Huge numbers of people are excluded from day-to-day services, which makes social inequalities worse. Our inclusive design mindset means we always aim to work with communities who aren’t being reached. We work with organisations that strive to make life better for people, communities and the planet. We don’t practice deceptive design, where the prompts and triggers push you towards something you don’t want to do. Our design empowers organisations to be more effective, inclusive and sustainable. It’s not good enough to simply create software and services with good intentions. As the designers of systems, we make sure they are created in a way that prevents accidental or deliberate harm. It’s our job to imagine the potential for misuse. ### Trauma-informed design A lot of our projects involve people who are exposed to traumatic or turbulent life events. We proceed with intention and care to deliver projects, products and services that recognise this. This approach is core to the way we work and communicate with people throughout the research and design process. We carefully consider how people may be affected by our research, and the products and services we design. We use this approach to protect the health and wellbeing of our teams, our research participants and our users. We have 5 trauma-informed practice principles to help minimise harm. We: * practice safety and privacy (for people and data) for our staff as well as the people we engage with and design for * are clear, transparent and honest * continue to grow our awareness and accountability * show care, understanding and patience * give control and choice to participants in research and users of our designs ### Stay curious Designing is about relentlessly trying to find a better way. We challenge ourselves to go beyond the easy route to find what’s right. When we design, we push beyond what we’re told and delve below the surface level. We always look for opportunities to evolve best practice, whether that's enhancing existing methods or innovating new ones. We can’t push for something new if we’re afraid of being wrong. So it’s crucial that we create a safe space to test and develop ideas. Ultimately, it’s our desire to explore a project and see it through properly that shapes how we turn up to work every day. # Service design Services are the means by which organisations deliver value to people. Whether we’re booking a GP appointment, paying our rent, claiming benefits, applying for housing or doing our shopping, services underpin everything we do in society. It often takes multiple organisations to deliver a single service. These organisations are not always well-aligned. Users (both inside and outside of an organisations) can often have complex needs which may impact their chances of finding, accessing, using or delivering services successfully. When services don’t work well for someone, at best it’s frustrating, at worst it can cause harm. Behind every service is a range of (often competing) factors, such as policies, legal considerations, processes, technologies, data, and cultures. Service designers help organisations to understand all these factors together and develop ways for services to be improved, providing better experiences and outcomes for those using and providing services.
""
Services don’t exist in isolation, they are part of complex systems. Service designers think deep and look wide to transform the systems that shape our world. We do this by providing design leadership, helping organisations to redesign themselves around the services they’re trying to provide to their users. This means designing services from the outside in, adopting a mindset which takes the lead from users' needs, and balances them with organisational needs to arrive at solutions that are both useful and sustainable. Ultimately, service design is all about people. Designing services happens best when we get together in-person. So we champion participatory and inclusive approaches to the design of our services – from the boardroom to the waiting room. Involvement from this wide range of perspectives gives us the full understanding of issues and opportunities necessary for design. Using a broad selection of tools and collaborative approaches, we help organisations explore the future of their services and products - defining what success is, creating attainable strategies, and planning how to get there.
""
Imagine designing a service for a remote medical examination. Service designers are interested in creating a flawless end-to-end experience for everyone involved; from patients, to carers, GPs, administrative staff, and hospital consultants – everyone is important in a service. To design an amazing experience, service designers need to understand the legislative barriers, as well as the cultural, technical, and inclusion factors (to name a few) that are crucial to designing good services. This means going beyond digital to consider the holistic ways in which people interact with services. For remote medical examinations, this may mean the design of diagnosis kits that can be posted to patients, scripts for medical and administrative staff, new policies to set the vision for the service, new roles to conduct tests and interpret results and trends, and developing success metrics to ensure the new service is effective. A good service should improve human connections, both in its delivery and its outcomes. Poor services can dissolve trust in users. Good services build trust and enhance relationships with users. Our team of designers are experts in helping organisations navigate their most complex challenges, balancing their goals with the needs of their users. ## See our work in practice
Improving access to respiratory testing and aiding diagnosisAstraZenecahttps://necsws.com/digitalstudio/case-studies/improving-access-to-respiratory-testing-and-aiding-diagnosis//files/LaopYfu7BH68xxffJqRu
Systems redesign in eye care servicesNHS England https://necsws.com/digitalstudio/case-studies/systems-re-design-in-eye-care-services//files/VuWX3fssdIEUroMLKcWf
# Interaction design Interaction design is the creation and improvement of the relationship between users and products. At NEC Digital Studio this means digital products like websites and apps. We explore how users engage with a page or screen and its components (like buttons and forms). This connects real people and the products they use. It’s not just about the visual appearance of the user interface. It’s about being efficient and functional. Even, at times, enjoyable. We consider aesthetics, motion, typography, space and even sound. All of these add up to the experience a user will have when using the product. Throughout our iterative design process, we aim to eliminate risk. This means creating prototypes (simulations of the end-product) and testing these with users to understand if it meets their needs. If it doesn't, we'll revise our designs and test them again. We also work closely with the developers of digital products. They assess the feasibility of the design concepts throughout the design process, and make sure the final product meets the standards we agreed. We ask ourselves what a user would expect, and where they would look to find it. Good interaction design should be intuitive and seamless. When someone uses an app or website they should never have to stop and think about the design of the platform, or how to do something. Reducing friction in interaction design involves simplifying the navigation, minimising load times, maintaining a consistent design and ensuring accessibility. There can also be value in designing positive friction to make sure a user carefully considers the potential consequences of completing a step in a process. For example, this might prevent users sending an email without including an attachment.
""
When you order a book online you can expect it to turn up on your doorstep the next day. The whole process, from ordering to delivery is the service. But *how* you buy the book, that’s where interaction design comes into play. The interaction designer seamlessly structures how you search for the book you want, how you save books you might want to buy in the future, and even the forms you use to provide your shipping address and payment details. When these things are easy, you have a better experience and are a more satisfied customer who is more likely to come back. ## See our work in practice
Helping early career teachers to receive retention payments Department for Educationhttps://necsws.com/digitalstudio/case-studies/helping-early-career-teachers-to-receive-retention-payments//files/UdTZqxLerkdbp5EG317G
# Content design Content design is a way of thinking about the content in a product or service that puts the reader or user’s needs first. It is more than just writing and editing. We use the tools of user-centred design to understand the user’s needs before creating any content at all. We organise and label content, to help people find what they need in the place they expect it to be. We write clear and simple instructions for the steps in a service. Or provide advice and supporting information to help people with a specific problem. We don’t just work with words. We choose pictures, script videos, or create diagrams if those are the best ways to convey information for our users. We’re strategic thinkers, who explore how best to share information. So don’t be surprised if we ask lots of questions. We make content that is: * **Findable** – Is it where the user expects it to be? Can they find it when they search for it? * **Useful** – Does it serve a purpose? * **Actionable** – Does a user understand what to do next? * **Clear** – Can it be misunderstood? * **Accessible** – Can everyone use it, no matter what their background, knowledge, and what assistive technologies they use?
""
For example, when designing a website to sells book online, the content designer would start by structuring the architecture of the site to make sure information was where the users would expect it to be. And then we’d look at categorising books. We might even specify the use of icons to categorise genres or audiences and make the search easier for the buyer. We’d also make sure the instructions are clear on the website and write book descriptions, so people better understand what they’re considering buying. We’d look at words on buttons and help text in forms to best guide the purchaser. Everything works to make the buying process easier. # Technology Large-scale services in society allow people to do things like order food or donate blood. But in the world of technology, services can also be discreet pieces of functionality, like a print service that connects to your printer or a or a messenger service that connects you with other users. When we talk about technical design, we refer to the planning of technologies and infrastructure to support a large-scale service delivery. In a way, designing a service is like building a house. Architects plan the design of the house before the builders start creating it to make sure the house will be safe and the foundations secure before any bricks are laid. Similarly, our solutions and technical architects plan the technology and infrastructure we need in place to support the designs before developers start creating a product. The architects review high-level requirements during discovery and help formulate potential solutions during the alpha phase. The chosen approach will be refined and detailed during the beta to create the proposed design. We focus on making the systems secure, extendable, scalable and available. And as part of that, we may capture business processes in Business Process Model and Notation (BPMN) or Universal Modelling Language (UML) and specify the necessary architecture components, like what services are required and how they communicate with each other. We also ensure they're easily extendable once live to support future enhancements and changing business conditions.
""
## Our approach ### Security Security is built into everything we do. Following the [National Cyber Security Centre](https://www.ncsc.gov.uk/) guidance, our products are secure by design. So what we’re creating, and who we’re creating it for, will dictate how secure it has to be. We might be designing a public website with predominantly open information. Or we might be designing a private police programme with sensitive data, including personally identifiable information like medical records or sentence plans. We’re experienced at working with extremely sensitive data. We assess how private the information is and then plan the security around it. We consider what bad actors might want to access the data and how to prevent that from happening. Our security approach is based around the universal principle of least privilege access. So someone can only access the data if this is required by their needs, role or function. The technical architect creates all relevant diagrams and documentation to show how and when data would be accessed in an application based on the requirements to help define the technical security controls. The diagrams inform what can happen to the data at every stage, by whom, and when. We answer questions like is it read-only or can it be edited. No matter the level of data access, we always create an audit trail to track it. The architects design authentication processes to confirm a user is who they claim to be and that they’re authorised to access the platform. All of these elements give our clients the confidence that we can protect their data. ### Scalability For a modern system architecture, services need to be able to scale. We design platforms based on the expected number of concurrent users and their usage frequency. Our Service Level Agreements (SLAs) are commitments to our clients regarding response times (how quickly the application reacts). For example, if we’re expecting 100 users on a Tuesday evening but 5,000 users try to access the system, it could negatively impact performance. So we need to be able to increase availability as needed and in real-time. We build cloud-native, highly available applications. For some applications with a fixed number of users, our designs are tailored to support those numbers in a cost-effective manner. But for public facing applications that have a varying number of users, we design it to work with dynamic demand. This means that when more users are active on our platforms, we can quickly scale up the capacity to maintain the expected performance levels. And then during quiet periods, we can scale it back down again, reducing costs. The technical architect designs the system to support this, planning how and what compute resources (like virtual machines or serverless resource) and storage is required for the platform. ### High availability Availability goes hand in hand with scalability. It’s about always being available and accessible. We design our systems to work, even in the face of failures as our services are fault tolerant. Availability is preparing for things to go wrong so the user can never tell. The technical architect designs the infrastructure to span multiple service instances to protect the application. And we build in disaster recovery plans from the outset so we can adapt to any challenges that come our way. #### Business continuity and disaster recovery Even with the most secure and reliable solutions, things can still go wrong. Sometimes, environmental or external issues occur that are out of anyone's control. That’s why we plan ahead for those situations. We always back up key data, whether it’s related to people or systems. It allows us to restore lost or corrupted data within minutes of the last entry. This way, no one loses a day’s worth of work. We’ve plan and test a wide range of disaster scenarios, from a single service failure to a complete hosting platform outage, and adjust our designs to restart or even rebuild from scratch if needed. {% content-ref url="/pages/u66w3uJGYhUIX9TvJ01X" %} [Technical architecture](/capabilities/technology/technical-architecture) {% endcontent-ref %} {% content-ref url="/pages/qoo5vTguFsWmmeyn5sed" %} [Data architecture](/capabilities/technology/data-architecture) {% endcontent-ref %} {% content-ref url="/pages/KgqHSlWP4mtjj3jMWBpr" %} [Infrastructure](/capabilities/technology/infrastructure) {% endcontent-ref %} {% content-ref url="/pages/CfKaUTrLvixfTWXSwDwb" %} [Technical governance](/capabilities/technology/technical-governance) {% endcontent-ref %} # Technical architecture For large-scale applications, we use modern architectures based on services, which are small, independent units of functionality with a single responsibility. Take your online banking app, for example. It can be broken down into different services like logging in, making payments or applying for a loan. When each of these services runs separately, they can scale up when needed. There might be a lot of people logging in around lunch time putting pressure on that services. When each of these services are distributed across multiple servers, they can scale up as required. Crucially, if one server fails, others can take over. Even if there was a catastrophic failure where a collection of services were to go down, the entire application would remain unaffected. That’s because it’s been designed without a single point of failure. We call this building horizontally to protect the application. So a technical architect’s job is to figure out exactly what services are needed. We look at the responsibility for each unit of functionality and map out the connections to other services. The developers are then in the best position to build those services, knowing what they need to perform and how they communicate with each other.
""
# Data architecture Data architecture is all about how you collect, store, manage, transform and use data. We consider how the data is gathered from various sources as well as the data residency, or where the physical servers holding the data are located. For a lot of our clients, it needs to be stored in the UK. We meet data standards for encryption every time we move or store data. In line with GDPR regulations, we have audit trails of when data has been changed, who made that change and when it was made. That means if there’s ever an issue, we can refer back to audit information. Data has to be accessible to only the right people at the right time. This is called the principle of least privilege, where you only have access to the data you absolutely need and no more. Even CEOs have data restricted from them if it’s not relevant to their role. Together the team defines: * How the data is collected? * Is a data migration required? * What format does the data need to be in? * Does the data need transforming? * How will data be handled in each service? * How will the data be distributed and shared? * How will the data be consumed and secured? * What permissions need to be allocated? * What audit logs will there be for that data? Using the principles and criteria listed above, the data team can design and implement secure data architecture.
""
# Infrastructure Infrastructure can be thought of as the plumbing of our systems. It’s how everything connects and works. All hardware is infrastructure. This includes laptops, servers, routers, cables. But not all infrastructure is hardware. In today's technical landscape, infrastructure also encompasses virtual hardware (the virtualisation of computer systems) and you can even deploy an entire infrastructure made of servers and routers by writing a few lines of code (also referred to as [Infrastructure as Code](/capabilities/development/infrastructure-and-deployment#automating-infrastructure)). Our infrastructure teams used to manage servers in our datacentres. Today, our physical servers are hosted by public cloud providers like AWS (Amazon Web Services) and Microsoft Azure. These companies handle the physical hardware, on top of which they’ve built a wide range of infrastructure services (like firewalls, load balancers or virtual servers) that we can easily consume. This allows our [DevOps](/team/nec-digital-studio-team#devops-engineer) teams to focus on developing feature-rich, performant and reilient solutions on virtual infrastructure hosted in the public cloud. Designing infrastructure now focuses on specifying the architecture through software configuration, rather than manually connecting network cables and installing operating systems. We plan aspects like the: * Overall architecture * Required public and private connectivity * Resilience enabling high availability * Data flows (linked to [Data architecture](/capabilities/technology/data-architecture)) * Number and type of containers (self-contained units of software with all necessary components) and virtual machines * Firewalls and other security protections * Load balancers and scalaing mechanisms. Our DevOps team creates all configurations to provision and deploy this infrastructure to the cloud. We evaluate all cloud hosting options to ensure we choose the best solution for our clients.
""
# Technical governance Technical governance refers to the frameworks and processes that guide the development, implementation, and management of technology within our organisation. It involves the coordination and regulation of technology-related activities to ensure we align with established principles, standards, and objectives. These include safety, independence, transparency, innovation, consistency, accuracy, expertise, efficiency and more. We’ve crafted a comprehensive Security Governance Framework and set of standards to protect our IT assets from threats and ensure the safety of our data and applications. This framework is the backbone of our strict policies, which we regularly update to stay ahead of potential risks.
""
For example, we have robust authentication and access control policies to manage user identities and multi-factor authentication (MFA). Our authorisation policies use role-based access controls (RBAC) to define what users and administrators can do. We also have data protection policies that include encryption for data at rest and in transit, as well as data classification and marking. Our network security policies cover firewalls and systems for detecting and preventing intrusions. In [DevOps](/team/nec-digital-studio-team#devops-engineer), we emphasise security from the start with policies like [shift left security](/capabilities/development/quality-and-assurance#find-early-fix-early), which integrates security checks into our development pipelines. We continuously manage vulnerabilities in both our cloud infrastructure and[ CI/CD pipelines](/capabilities/development/infrastructure-and-deployment#automating-deployment), and we have rigorous patch management policies in place. When it comes to incidents, we have a detailed incident response plan with clear escalation paths and regular tests to ensure we’re prepared. We prioritise training and education, providing security training and acceptable use policies to our team. And finally, our [business continuity and disaster recovery](/capabilities/technology#business-continuity-and-disaster-recovery) (BCDR) policies ensure we have backup standards and disaster recovery plans to keep our operations running smoothly, no matter what happens. # Development Software development is creation. We take a design, and we turn it into reality. At NEC Digital Studio, we develop products that transform services used by everyone, every day. Software is a set of instructions that tells a computer what to do. Those instructions are written in code, a language that can be read and understood by a machine. The machine can then follow these rules and create a journey for a user through the system. The more complex the systems requirements are, the more complicated this process becomes. Our team is made up of business analysts, architects, data modellers, software developers, DevOps specialists, testers, QA experts and more. They each bring different skills to help build out the code and create meaning in the technology.
""
## Our approach ### Research and design at the forefront of development We’re a user-centred studio. That means we put research and design at the core of everything we deliver. From how we approach our products to the shared tools we work with, we make sure every step between design and build is connected. You can read more about our [research](/capabilities/user-centred-design/research) and [design](/capabilities/user-centred-design) teams. Or read more about [how we work together on projects](/projects/how-research-design-and-development-collaborate). ### Agile development and scrum We often hear terms like 'agile' and 'scrum' in relation to developing software. But what is it, and what does it mean? [Agile](/projects/the-structure-of-a-digital-project#delivering-in-agile) is a way of managing a project that focuses more on how people work together as a group than on the processes. In reality, that means we focus on delivering working, fit for purpose software rather than spending hours producing reams of documentation that isn't that useful. Part of that collaboration is working closely with clients as well as internal teams. It ensures they are enaged in the process and always results in better services to their users. There are many different types of agile development frameworks, but our chosen method is [scrum](/solutions/our-saas-solutions#bringing-products-to-life-with-scrum). It provides a structure to the way we manage our development teams and make sure that we do key things at the right time. ### Behind the technology Our research and design focus means we’re excellent at front-end development, or what the user sees when they use the platform. But we’re also experts in back-end development. These are the components that add together to create the application business logic, functionality and data structures. Having specialist [front and back-end developers](/team/nec-digital-studio-team#software-developer) and [data engineers](/team/nec-digital-studio-team#data-engineer) means we can deliver full stack solutions with an expert approach. Think of when you log into a social media account. The front end is what makes it look good and how the ‘interface’ appears when you put in your password. The back end is where your password is validated against the database to check it’s correct. And then the business logic directs you to the homepage once you’ve logged in. Some development teams specialise in front end or back end, but we do the whole package. And we do it well. #### All things APIs One of the ways we’re future-proofing our development is taking an API-first approach. Most companies design their user interface (UI) with the user in mind, but some forget that the user isn’t always a person. In the back end, it’s APIs (the connection between 2 different applications) that need to be thought of. We’re working towards completely public and accessible APIs, where any of our partner organisations can connect to our systems. Of course, that means reinforcing back-end security to protect them too. But it opens up a world of new data and technology as we connect to systems across the world.
""
### Standardise across projects We have communities of practice set up to make sure our approach is consistent from one project and product to the next. Whether we’re workingon our own products and services or delivering work on behalf of clients, we should be delivering consistent work following best practice. That means our teams can move from one project to the next with the confidence they can hit the ground running. The sprints look the same and the processes within them are the same too. It’s also a huge time saving. We build something right the first time, and then we can reuse it again and again. We’re working on 2 different reusable elements for products; services and components. #### Services Reusable services are fully formed units of functionality. Take an authentication service. Most applications we build require some kind of log in, many with multi-factor authentication and single sign on. We’re building an authentication service that incorporates the best of our existing capabilities. Then we can roll it out across our products. It takes a little longer to create the first time, but then it’s one service with one codebase. That makes it more secure. And any time we build in new functionality to the service, all products using it will benefit. So it's more feature rich too. We’ve got plans to explore other services as well. We’ll look at smaller services like form builders and scheduling tools all the way up to enormous services like case management and document management solutions. Right now, our focus is reusing them across NEC Digital Studio. And that will take time. But there is a future where we offer our reusable services across wider NEC Software Solutions products too. #### Components Reusable front-end components are smaller building blocks. They might be buttons or tables, error messages or headers. The code for these components, formatted in a particular style, is documented in a library. So our [software developers](/team/nec-digital-studio-team#software-developer) can quickly pick up code for a component that’s got accessibility and style prebaked in. It makes our lives easier, improves the consistency of our work across projects, provides better value to clients and delivers a better end result. Think of it like building a kitchen. Once the design sketches are ready, there are 2 options for making it come to life. The builders can install premade cabinets that are designed, built and tested for exactly that purpose. Or they can buy the materials to make bespoke cupboards for this specific kitchen. There’s a time and a place for both. But when the first option is cheaper, more efficient and meets incredibly high standards, there is no need to bespoke every element. Where possible, we should always look to build once and reuse. It maintains consistency and quality, and means our team can hit the ground running when they step into a project. Of course, there are also projects where we develop software for our clients to own so the development sits separately from our resuable services and components. In many instances, government clients are making new code open source too, so we fit our approach to each client we work with. {% content-ref url="/pages/vImH9hCvJwDQZaJXx636" %} [Quality and assurance](/capabilities/development/quality-and-assurance) {% endcontent-ref %} {% content-ref url="/pages/fDY2cbZUX27M3EMHN9JT" %} [Infrastructure and deployment](/capabilities/development/infrastructure-and-deployment) {% endcontent-ref %} {% content-ref url="/pages/Ysgyd9XXBjqMeURLPdmx" %} [Monitoring](/capabilities/development/monitoring) {% endcontent-ref %} # Quality and assurance Part of the package that comes with our software development is the peace of mind we offer our clients that their systems work well. And that comes down to our rigorous testing practices. We build testing into every stage of development. 1. **Unit, component and integration tests.** As the [software developers](/team/nec-digital-studio-team#software-developer) write the code, they build in automatic tests to help us identify any issues quickly. Unit tests confirm that a change has not caused an unexpected behavioural impact, and component tests allow us to verify the behaviour of an individual component while integration tests verify the interactions between components. 2. **End-to-end automation testing.** Next up, our [Quality Assurance (QA) team](/team/nec-digital-studio-team#quality-assurance-analyst) will manually test the application. As they test each section manually, they write automation scripts to repeat that process automatically. So the more the QA team test, the more they train the systems to run tests automatically until they have mapped testing across the entire platform. This end-to-end testing speeds up any future tests as they can be run without manual intervention. 3. **Performance testing.** We have service level agreements (SLAs) with our clients for the required performance and availability of our applications. The QA team run load tests where we increase the number of users to check the response time. And similarly with data, we load additional records to see how it impacts the performance. This helps us identify potential performance issues in the application to resolve them. 4. **Regression testing.** Before any changes are made, the QA team run regression testing on the full application. This makes sure we don’t reintroduce any previously resolved issues and the application is working as required. 5. **Penetration testing.** Not all testing is done by us. We hire accredited cyber-security specialists to run pen tests at least annually. They set out to find security weaknesses and try to break into our systems so we can build the best defences. We use tools to automate the testing of code which is a huge time saver. It could take days, if not weeks, to manually test all the code we’re working on. But with automation, we can run those tests in just a few hours. This means we have the capacity to test more regularly, mistakes are spotted sooner, and errors are fixed faster.
""
## Find early, fix early When issues aren’t spotted until later down the line, there’s a risk of the fault being embedded too deeply in the code. Then teams become reliant on workarounds and fixes that are costly and time consuming. So we introduced a ‘shifting left’ policy for coding quality. This is the practice of detecting vulnerabilities and coding errors as early as possible. We’ve implemented tools like Snyk (to test platform security) and Sonarqube (to test coding practices). They work like a spell-checker for code by validating it as it’s being written. Just like spell-checker, there are sometimes errors. It might read something incorrectly or in the wrong context and make a suggestion, like when an American spelling is suggested to improve British English writing. But most of the time it spots errors early before the code has been fully written. These tools spot 70-80% of errors in the initial draft, which means they can be fixed at the source. Developers don’t waste time having to search through lines of code to find the issue. It’s addressed in the moment. The code is then manually checked by a senior developer to confirm it’s easy to read and meets our standards. Of course, the code still goes to the QA team for rigorous testing, but we find significantly fewer vulnerabilities to fix. This can save hours, if not days, of time. ## One step ahead We work to standards of engineering excellence which means we have a quality and security first mindset. One example of this is our site reliability engineering, which means we keep our applications online and working at all times. Development isn’t just about the creation of software, it’s about keeping it live. We look out for indications of an issue, like performance slowing down, before errors are spotted. And we’re putting automatic alarms in place to warn our engineers when an application is not operating as required. # Infrastructure and deployment The [DevOps team](/team/nec-digital-studio-team#devops-engineer) enables us to rapidly deliver high quality applications and services. They focus on the automation and integration of processes in the software development lifecycle. ## Automating infrastructure One of the things the DevOps team are responsible for is the environments the code runs in. They spin up servers and configure tools for developers to work with. At NEC Digital Studio, we do this as Infrastructure as Code (IaC), a set of instructions that a computer follows. It sets out the exact parameters for the code which means it can be run thousands of times and will always produce the same results. So we can scale things up quickly and consistently. Computer infrastructure used to be done by clicking through buttons on a user interface. There was huge room for manual error, and it was difficult to track down any mistakes. Now it’s written as code in plain text lines of writing that can be peer reviewed much more easily. And once approved, we have a history of that code saved and ready to deploy. IaC is vital to disaster recovery as you can rapidly recreate environments. If something were to go wrong and we lost one of our live environments, instead of spending weeks manually recreating it, we could run the code and spin up the environment again in under an hour.
""
## Automating deployment Our DevOps team puts pipelines in place to seamlessly roll out code to the development, test and production environments. Our continuous integration and continuous deployment (CI/CD) pipeline is the automation of the process to deploy code. Once we write the scripts, it’s highly repeatable. And much simpler too. By automating the process, we remove the dependency on the DevOps team to run the scripts. It’s a massive time saver, allowing us to deploy code quickly and consistently across environments. ## Blue-green deployment model For the majority of our applications, we apply something called a blue-green deployment model where we use two sets of servers to keep the application running while making changes. The existing servers with all the live traffic are blue. When we’re ready, we deploy the new code or software in brand new green servers which are fully security patched and updated. Then we migrate a small subset of users to the new green servers and test the functionality of the system. If everything works as it should, we can spin up and transfer all users across to the new green servers. And if this is successful, we can delete the old blue servers. This protects the application, as any progress made while attempting to penetrate a system will be lost when the server is destroyed. It also means we deploy new functionality without any down time for the users. We even make these migrations during the working hours, so we have teams of experts on hand to support the process. # Monitoring We need to know how our applications are performing at all times. Even at a microsecond level, we track how our platforms are responding. The [DevOps team](/team/nec-digital-studio-team#devops-engineer) look for bottlenecks, where the system is trying to do too much at once, so we can proactively fix them. If we spot an increase in users, we can spin up a new server to take the load before anyone would notice an impact on the application. The application support and devops teams are constantly monitoring, checking alerts and then taking early action to fix potential issues. We’re focused on delivering full availability, so our users never have to log a call. For more information on how we support live products, [check out the live section of project delivery](/projects/the-structure-of-a-digital-project/live). # Delivery management We support clients through every stage of the delivery lifecycle, helping to ensure projects run smoothly and efficiently. Whether it’s planning, execution, or overcoming unexpected challenges, our focus is on providing practical support to help turn client goals into tangible outcomes. And with extensive experience, we understand what it takes to create successful products and services. Delivery management is a vital function, accountable for the successful delivery of complex, high risk products and services. We’re responsible for the coordination of resources and activities, managing risks and issues, and ensuring deliverables are available on time, to budget and that they meet the clients’ expected quality levels. A lot of the work that goes into delivery management is hidden from view, but it is essential to keep projects running smoothly. We negotiate and set budgets in complex environments, have a thorough understanding of the project lifecycle and maintain delivery momentum throughout. We have experience across the full project and delivery management spectrum, from agile to lean and waterfall, and everything in between. Importantly, our delivery approach flexes to the needs of the client and the specific project we’re working on. This flexibility is key for successful delivery and allows us to adapt our approaches to ensure we can work with clients and other stakeholders in a collaborative way. At NEC Digital Studio, delivery management is split into two functions: project delivery and delivery operations.
""
## Project delivery We provide project and delivery management roles, from project managers to programme managers and directors across the full range of delivery methodologies. The project delivery function engages clients on a strategic level, managing the desired outputs and outcomes of the project in line with the agreed budget and timescales. Delivery Managers work collaboratively with clients to establish high levels of trust and satisfaction. We’re usually the main point of contact for clients and ensure communication lines between subject matter experts and our delivery teams are always open and effective. We are also the connection between the technical and non-technical teams, managing the boundaries of responsibility and ensuring efficient collaboration and production of deliverables. We manage stakeholder expectations and moderate discussions about risk and complexity, gaining mutually agreeable approaches and actions. Delivery management bridges the gaps between different areas of expertise in a project to find a clear path towards a united goal. Another hugely important element of delivery management is the discipline applied when following the agreed processes. This ensures clarity, transparency and predictability in our work and the services we provide. Delivery management keeps us accountable, honest and on track. ## Delivery operations Also known as the project management office, or PMO, delivery operations are the administrative support for the project delivery teams. Delivery operations are responsible for a huge number of vital activities that ensure a project is successful including: * **Resource management and assignment.** We balance resources with competing priorities across the business. That means knowing what skills are required for each project and which colleagues are available with those skills. Robust resource planning allows us to provide accurate estimates to clients and ensures we have the right people to deliver the work. * **Project governance.** We have processes and controls in place to ensure projects are well-managed and meet their objectives. This includes risk management, contract management and commercial change management as well as the communication of the achievement of key milestones and more general updates to stakeholders on progress. We can also establish and support project/programme boards to provide effective oversight and decision-making for delivery in line with client requirements. * **Financial management.** We track the financials to make sure costs are in line with expectations. We invoice the client at the right time for the relevant work and continually monitor and report on the financial health of each project. * **Onboarding and offboarding.** Whenever anyone starts a project, we set them up to hit the ground running. That means sharing project information, getting the right access to files and setting up colleagues with relevant technology and tools. Similarly, when anyone leaves a project or when a project comes to an end, we ensure the processes and outcomes have been documented so we can learn for future work and celebrate our successes. A lot of our learning feeds into our delivery framework, to build capabilities and grow expertise across our teams.
""
## Our approach ### Working to a delivery framework The NEC Digital Studio project delivery framework provides our teams with a blueprint to work from when delivering projects. It identifies key activities at every stage throughout the project lifecycle, from how to start a project right through to how to close it down. Each section has specific templates and advice to guide the teams through the process and ensure we’re consistently delivering to a high quality. It’s a source of inspiration for ideas as well as ensuring we stick to project governance. It’s also a tool for encouraging and driving continuous improvement. We’ve built in regular retrospectives and feedback loops to learn where our project teams encountered challenges, so lessons can be learnt and processes can be improved. Read more about the details of [how we run digital projects](/projects/the-structure-of-a-digital-project). Most importantly it’s a framework, not a mandate. It gives our teams a platform to build successful projects on, but without restricting their ability to adapt to the needs around them. ### Flexible delivery Different clients have different requirements or ways of working, and, in some cases, pre-defined governance that must be followed. Our delivery approach is built on firm principles, but we’re adept at adapting to accommodate these differences. We define and agree our approach at the beginning of every project with key stakeholders, to ensure we’re working in line with their expectations. We’re skilled in coaching our teams and clients to inspect and adapt their processes and grow from there. We’re not interested in prescribing exactly how something must be done, and most of our clients don’t want to hear that. We can offer guidance on best practice within established frameworks, but ultimately, we’re here to fit into the client’s working style/approach. ### Programme management Programme managers lead our delivery teams on large-scale digital projects with multiple workstreams. Each delivery manager takes on different responsibilities and priorities within their workstream, reporting into the programme manager who has ultimate responsibility for the project as a whole. Our programme managers act as an escalation point for any commercial or delivery risks. We’re skilled at removing blockers and manage dependencies of varying complexity, with our project and programme managers embracing the role of a ‘Servant-Leader’ who addresses challenges that might otherwise inhibit a team’s ability to deliver. We strive to adopt the right leadership style for each project to deliver the right outcomes. And as priorities change throughout the project lifecycle, we balance the objectives and redeploy people and resources as required. Programme managers take a strategic role in our client partnerships. We engage with senior stakeholders to understand the desired outcomes for their client’s organisation and the constraints and impediments currently preventing them from getting there. It’s our job to understand what our clients are trying to do and the environment they’re operating in so we can take a strategic approach to those requirements, joining business needs with innovative analysis. # Accessibility Part of our mission is to empower organisations to be more inclusive, so producing accessible products and services is what we’re all about. Everyone should be able to use a product or service in a satisfactory and efficient way. And the more accessible a product or service is, the more people will be able to use the service successfully. Good accessibility means making sure that what users are seeing and interacting with can be readily perceived, is easy to understand and use, and is coded in an accessible manner so that assistive technology works seamlessly. The easiest way to deliver services that work for everyone is to build with accessibility in mind throughout the project – from concept to completion. Our in-house accessibility team provides a range of services from project initiation to post-project reviews. Depending on the project stage, they can do: * Accessibility audits * Manage testing and/or subject matter expertise * Ad-hoc accessibility consultation through clinics and ‘live’ audits * Mentoring and training * Component accessibility reviews * Accessibility statement writing, including a roadmap of any future plans to improve accessibility Clients' requirements vary enormously. They may need a full accessibility audit of a live product, service or website where we highlight challenges and make recommendations. In other instances, we might be working on a project with a client to deliver a service and need an accessibility specialist's evaluation of a specific component that we plan to build. Whatever the needs, we flex our offering to best support the client while championing the importance of accessibility.
""
## Our approach ### Accessibility champions At NEC Digital Studio, our accessibility specialists act as consultants who oversee all aspects of accessibility on our products and projects. But they do not work alone, as we also have a team of accessibility champions in many departments across the business. Our champions have a vested interest in ensuring that everything we design and build at NEC Digital Studio is accessible. They are trained to advise project teams on a variety of different front-end and back-end elements of the service, as well as physical accessibility for the non-digital elements of a service. The champions' involvement assures clients that accessibility is at the forefront of our designs at all times. Having the champions embedded in our delivery means we have representation at every phase of the project lifecycle and produce more usable and inclusive services. ### Working the right way A vital part of delivering accessible services is understanding the full breadth of the users’ needs. This is why we conduct our research and design with a variety of people with a range of different accessibility needs. The Research Operations and User Research team are experts at recruiting and working with people with specific access needs. We know how to reach out to the right people and how to welcome them into a physical space or best prepare for an online meeting. Our usual practice always considers building breaks into meetings and offering questions in advance for people to prepare answers. We also offer additional support where required, such as making sure physical spaces are wheelchair accessible or we have the right technology for people to engage with on the day. For us, it’s all about providing options. We allow participants to direct us with their needs so we can help guide our clients to make informed decisions about their services. And armed with relevant insights, together we design and deliver the right thing. We have regular touchpoints throughout the delivery lifecycle to help build accessibility into our products and services. From weekly accessibility clinics where anyone in NEC Digital Studio is welcome to raise queries and ask for support through to monthly accessibility tech talks where our specialist and developers get together to discuss latest best practice for accessibility.
""

Working with a screen reader

### Why we work this way At NEC Digital, accessibility is baked into everything we do for three key reasons: * Ethical * Legal * Financial Ethically, accessibility is all about inclusion. Designing and building accessible services is about making them available to and useable by all users, regardless of ability. The more people who can access a product or service, the more widely it will be used. This helps our clients to reach further and enables better support and services for their users. Legally, all media such as websites and mobile applications in the UK need to meet the [Public Sector Bodies Accessibility Regulations 2018 ](https://accessibility-manual.dwp.gov.uk/accessibility-law/the-public-sector-bodies-accessibility-regulations-2018)(PSBAR), as well as the requirements of the [Equality Act of 2010](https://www.gov.uk/guidance/equality-act-2010-guidance). UK websites and apps must be compliant with the Web Content Accessibility Guidelines (WCAG 2.2 AA). WCAG 2.2 AA is a universal standard for accessible online services. It outlines criteria that are designed to make services perceivable, operable, understandable and robust. We comply with the regulations, not simply to fulfill our legal obligations, but because we believe in removing barriers that might prevent people from accessing essential information and services. Beyond legal requirements, we also work in line with different guidelines. A key example is the Government Digital Service (GDS) principles which are particularly important when working with government bodies but also feed into our work with private and third sector clients too. There is a large crossover between GDS guidelines and WCAG, as the local UK standard takes inspiration from the global framework and we have experience of ensuring products comply with both. Financially, we ensure the most cost-efficient approach for our clients. At NEC Digital Studio, we don’t see accessibility as a box-ticking exercise to complete at the end of a project. Where this approach is taken, audits come back with costly recommendations and organisations waste money and time fixing things they could have got right the first time. For us, accessibility is part of project design from the start to save clients future cost implications. # Our accessibility statement This is our accessibility statement that describes this site's compliance with accessibility requirements to provide helpful information to anyone who may need it. NEC Digital is committed to making the Playbook as accessible as possible, in accordance with the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations (PSBAR) 2018. This accessibility statement applies to the NEC Digital Playbook which is hosted by Gitbook. ## Compliance status This NEC DigitalPlaybook is partially compliant with the Web Content Accessibility Guidelines (WCAG) version 2.2 AA standard, due to the non-compliances listed below. ## Non-accessible content The content listed below is non-accessible due to non-compliance with the accessibility regulations: * \[A 2.4.1] The skip link is missing from the top of the Playbook, however users can use the right-hand navigation that lists sections of the article and jump to content of interest. ## Preparation of this accessibility statement This statement was prepared on 09 January 2025. The Playbook was evaluated by our Accessibility Specialist using automated testing (WAVE), screen reader (JAWS v24), keyboard-only and colour contrast analyser on Microsoft Edge. The statement was last reviewed on 14 January 2025. ## Feedback and contact information You can contact NEC Digital’s Strategy Team by email : Working hours: Monday – Friday 9:00am to 5:00pm. We aim to respond to emails within 48 hours. ## Enforcement procedure The Equality and Human Rights Commission (EHRC) is responsible for enforcing the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 (the ‘accessibility regulations’). If you are not happy with how we respond to your complaint, please contact the Equality Advisory and Support Service (EASS). # IT Managed Service We provide fully outsourced IT services to local government. That means end-to-end support from the computer on the desk, to the network that connects it, and the infrastructure in the background. It gives local authorities and their citizens peace of mind. Our service includes IT security, compliance, project delivery, FOI requests, office moves, and a support wrap focused on continuous service improvements. We provide these elements so councils can focus on delivering for the citizens of the area in sectors like education, social care, revenues and benefits, and social housing. Each account is different, because each local authority needs different things from their IT managed service. An important element of the service is our flexibility. Right from the start, we build each account around the teams we’re working with and the needs of the local area. Then we have tailored service-level agreements we commit to and deliver in line with those needs.
""
## Our approach ### Our delivery teams Our service can be broken down into 3 different functions: * on-site teams embedded in the local authority * support desk including a centralised cyber, service and technology team * account management Our on-site teams are local to each council that we work with. They are responsible for maintaining and proactively managing the council’s IT infrastructure and applications. All accounts have technical staff skilled in desktops, applications, networks, and servers as well as a service delivery management, project management and programme management. Working in an agile manner, the on-site teams agree with the council on the resources available and prioritise how best to deploy them. Because they are in the council offices working alongside council staff, they can also look for opportunities to better engage with the council and improve their services. Our support desk is based out of the NEC Hartlepool office and is the first-line triage for any support calls across all our IT managed services. The experienced team resolves 70% of calls that come through as a first-time fix. The remaining, more complicated calls, are passed to the on-site teams to resolve. Our support desk is reinforced by NEC Software Solutions’ Cyber, Service and Technology (CST) wider support team, with its rigorous cyber security and incident management capabilities. Our account managers play a vital role in the overall quality of the service we offer. They work on our contracts from the beginning, to ensure that what we commit to our clients is achievable and deliverable. Then they spend the duration of the contract building partnerships and trust in the council and local community. Each account manager also lives within the local area of their client, so is just as invested in the success of the partnership as the people on the ground delivering the service. We’re integrated into our partner councils from the bottom up and top down. ### Our processes While each account is unique to that local authority, there are consistent patterns we follow in service delivery across all our accounts. Every client has a monthly review board, where the NEC site-based leadership team meet with the ICT lead for the local authority to review the monthly service report. We review all key metrics for the service (like support calls raised and resolution times), identify any trends and agree mitigating actions. We consistently work in line with the Information Technology Infrastructure Library (ITIL), a best practice framework for IT service management. ITIL ensures predictable and stable IT environments. As an organisation, we’re ITIL version 4 accredited and certified to ISO 20000. Working within these frameworks, we deliver the best service possible to clients by streamlining processes and identifying opportunities to improve efficiencies. An important element of the ITIL framework is the Change Advisory Boards (CABs) that review and authorise changes to council IT systems. They ensure changes are managed effectively causing minimal disruption. We have an internal CAB within our organisation that works alongside the specific CABs in each council to scrutinise plans and advise on the best approach. As much of our work focuses on IT, we also liaise closely with the Technical Advisory Boards (TABs) too. Our robust first-line to third-line support ensures we answer any support calls in a timely manner. As first-line triage is done, simpler challenges like password issues can be resolved immediately. Then second-line support step in for more complicated remote issues, like applications not working. Where there are complex site-based problems that require a hands-on approach, third-line support (the on-site team) are ready to assist. For us, the priority is constantly seeking best practice to mitigate risks and respond rapidly when required. Say there was a major incident, like a network outage from the local authority’s telecoms provider. We’d be on hand with tailored disaster recovery plans, safeguarding data and diverting network traffic to enable key workers to deliver vital services while working with their telecoms provider to help restore wider connections.
""
### Building true partnerships We’re proud of our relationships with our customers, and rightly so. All of our accounts are long serving, the longest of which has partnered with us for the last 15 years. A big reason for the longevity of our relationships is our investment in local people and community. Where possible, we always recruit locally to the council using local residents to support local IT. That means our teams are invested in delivering contracts well, because it impacts their families and neighbours. We work as part of the council team. We’re not a provider, but an integrated and integral part of the service. Being embedded in the team allows us to understand the complexities and dynamics of the council better. Everything a council does must be: * in response to legislation, * of benefit to the citizens, or * a cost saving for the council. Working closely with our local government customers enables us to fully understand their priorities. And in doing so, we are best placed to review and innovate their IT systems. This might mean improving an online interface to allow citizens to engage more easily with the website, or it might be improving infrastructure security. Anything we deliver must meet the needs outline above, and in doing so our partners trust us to provide what’s best for them and their citizens. Our focus on continual service improvements helps find efficiency gains for our council partners. One of our partners has seen a 30% reduction in calls as a direct consequence of technology upgrades and improved tools and skills across the council. By prioritising weaker areas in the council’s IT, we’re able to proactively resolve challenges allowing staff to be more productive with reduced system downtime. ### Investing in the future We employ around 40 members of staff across all our IT managed service contracts. A really important part of that figure is made up of our local modern apprentices. Talented young people are brought into the council and encouraged to progress into increasingly more senior roles across Digital Studio and wider NEC Software Solutions. As part of our ongoing partnerships, we also invest in social value for the communities we work in. In Hartlepool, we’ve invested £1 million in setting up a new business centre for Hartlepool Borough Council. The building of the new business centre helped boost the economy through its use of local traders and suppliers. Now council teams, including our own, work out of the building every day. Our partnerships don’t just focus on one-off big investments. They’re about continually turning up for the communities we work in, which is why each year we invest further in local programmes. We support local charities by donating prizes for their raffles as well as helping to organise and run events. We also provide technology to several community hubs, enabling local people to equip themselves with digital skills to help in education, employment and accessing local services online. # Our SaaS solutions Our products are SaaS solutions, or Software as a Service. Some clients will prefer an off-the-shelf solution, so we provide these and host them in the cloud. That’s not to say that we don’t tailor the solutions. We regularly draw on our user-centred design capabilities and adapt them to meet our clients' needs. But because they’re SaaS solutions, our clients don’t need to worry about storing data, maintaining software or keeping the system secure. That’s our job. Our products are our own intellectual property. That means unlike the bespoke services, we own the rights to the technology we’ve created. We can package the products up and sell them to clients we know will find them useful. With over a decade embedded in criminal justice, our products support better outcomes across police forces, prisons, probation and youth justice. And some of our newer solutions, like [AnyCase](/solutions/bespoke-case-management), are sector agnostic.
""
## Our approach ### People at the heart of everything we do Our ambition is a world where all services work in harmony with people. We do that by delivering systems that are smarter, safer, seamless and more sustainable. Our people are the strength of our company. We know the sectors inside out because many of us have worked in them and now deliver to them. That means our software is created by experts, and the support is provided by teams with real experience. ### Deploying products well We empower organisations to be more effective, inclusive and sustainable through products and services that are intelligent, integrated and intuitive for all. And user-centred thinking is how we deliver that. We put simple and accessible design at the heart of our products and services. We have a dedicated [User Experience (UX) team](/team/nec-digital-studio-team#ux-designer) that focuses on constant improvements to our own products. They conduct reviews, from quick fixes to full UX audits. Our UX specialists work with product teams when designing solutions to make sure they: * meet the user needs * meet the business needs Innovation is at the core of everything we do. We don’t believe in being complacent when we can always strive for better. That’s why we challenge the boundaries of what’s possible in our products. Our drive for continuous improvement means we’re constantly iterating our software. We engage with our clients and users to inform these improvements. And with multiple releases a year, we make sure we’re delivering updates as quickly as possible. A key part of our continuous improvement approach is working in scrum. ### Bringing products to life with scrum Our ways of working are driven by the scrum framework, a process of evidence-based and iterative decision-making that focuses on transparency, inspection and adaption. The essence of scrum is to do something, learn from it and then change. We typically work in 2 week sprints, making decisions based on feedback about what we know. Certain things have to happen in a sprint, and these activities are called ceremonies. At the beginning, we start sprint planning. This lays out the work we need to complete in the next fortnight. We also review the backlog of requirements that are driven by new legislation, technology and processes or that have come through the support desk. The [product owner ](/team/nec-digital-studio-team#product-owner)and [scrum master](/team/nec-digital-studio-team#scrum-master) sit down regularly to review the backlog with input from development to feed high priority items into the next sprint. Then we have daily stand ups (short meetings) at the same time each morning to check in on progress and handle any blockers. Towards the end of the 2 weeks, we have a sprint review where we inspect the work we have produced in that sprint. This helps shape future work and gives the team the opportunity to share what they have done with key stakeholders. Finally, we hold a sprint retrospective (retro). The retro reflects on how we delivered the work and plans ways to increase the quality and effectiveness of our working practices. While the [product manager](/team/nec-digital-studio-team#product-manager) and[ product owner ](/team/nec-digital-studio-team#product-owner)are focused on the roadmap, the [scrum master](/team/nec-digital-studio-team#scrum-master) is focused on the team and scrum. They are accountable for the team’s effectiveness, striving for greater value in development and removing challenges. We use this framework to bring our roadmap to life and meet our service level agreements. ### Making migrations seamless Large data migrations are a big concern for clients. And that makes sense. It’s a huge task with high stakes. But we’re here every step of the way to make that process easier. We start by understanding the data. What format is it in? Where is that data stored? And what does our client expect us to deliver? These are all important question to answer before we begin a migration. Data can be stored in different ways and in different locations. Commonly, we work with whole databases, document libraries and xml files (exports of databases that condense data into a bitesize chunk). #### Getting the data ready One of the first steps is a data discovery, a way of visualising data to look for patterns and insights. Then we can map the data and configure it ready to be moved. All of this is signed off by the client to make sure our expectations are in line with theirs. We’re then ready to set up a secure transfer mechanism to get the data from point A to point B. It starts in the customer’s existing environment, before moving to a migration environment and then finally transferring into the live environment. Each move has the potential to make the data vulnerable, so we build security in at every stage. #### Testing the data Once the data leaves the customer environment, it sits in a data warehouse. This is a place to store and process large quantities of structured and unstructured data. It gives us the chance to do reporting and testing. We check that we can unpack the data and that it’s in the right format for us to use. Then we map where data from the client’s existing environment will appear in the live environment. We also test for data quality. This means checking that the data appears in the way it should do. For example, if all dates of birth need to be in the format 01/02/2003 then we have to change any showing as 1 Feb 2003. This must be fixed before the migration to the live environment. The final step is data acceptance testing with the client. Only once we have official confirmation that everything meets the client’s standards can we migrate the data into the live environment. #### Integrations Another consideration is integrations. This is when the system we’re providing needs to link to third-party systems to access more data. Take [Interventions Manager](https://necsws.com/digitalstudio/solutions/saas-case-management/interventions-management/) for example. We integrate with nDelius, the national database for people on probation. They provide the referrals for behavioural programs, and we provide information back about attendance and feedback. We adapt our technical architecture to absorb that data into our system and then share data in return, following data governance rules. #### Training To make a migration seamless, we provide [training ](/projects/the-structure-of-a-digital-project/live#training-the-users)to help clients make the most of our systems. Experts provide both train-the-trainer sessions as well as wider end-user training. And if needed, we can do training needs analysis to help each client pick the training option that’s right for their organisation. This full service during the migration helps our clients go-live as efficiently as possible.
""
## What we bring to the table Our products are hosted, so they sit in the cloud. We use a variety of public and private clouds, working with a range of suppliers like AWS, Azure and Oracle to suit the needs of our clients. We comply with the [National Cyber Security Centre ](https://www.ncsc.gov.uk/)best practice, which means our data is held in the UK and we always host in multiple locations at the same time for business continuity and disaster recovery purposes. Our clients don’t need the infrastructure or technical know-how to support a product. The services are accessible online in a secure environment. So from a user perspective, teams can log on and find the services they need from day one. Hosted solutions don’t have to wait for a major release to get updates into the software. As soon as a feature is ready, we can deploy it. That means we’re getting value to the customer at the earliest opportunity. And if there are any problems, we can get ahead of them quickly and offer solutions rapidly. ### Supporting our products Our software underpins critical services across the UK, so our clients need to know they can rely on us to step in when they need help. The team has worked on some of our products for over 10 years so we’re experts in our technologies. And we pride ourselves on going the extra mile to support our clients. With NEC Digital Studio, clients get the personal touch of a dedicated and friendly support team with the backing of the wider NECSWS cyber, service and technology teams. And that makes a world of difference to the support we deliver. On the rare occasion that there is a serious issue, we have a central major incident team who are trained to handle the process. They keep users and stakeholders updated while working with the support and development teams to resolve the issue. They are also responsible for writing up a major incident report to take lessons learned and incorporate them into our processes. In instances like this, clients need us to prioritise proactive support to fix the problem so that's what we deliver. ## What we expect from our clients It’s not just a one-way street. To deliver best-in-practice software, we require the support of our clients too. And this can be summed up in one word: collaboration. Whether the product is custom built for a specific customer or is being used by many different clients, we like to make sure it’s hitting the mark. That involves regular service management meetings to review the product roadmap and any outstanding calls, so expectations are shared and we’re held accountable for our promises. Transparency is key to our partnerships with clients. We believe in holding our hands up if something goes wrong and expect our clients to approach us with the same honesty. We value trust and openness, and we live by those values in how we deliver to our clients. We’re future minded too. We run user groups and meetings with clients to look at the market and understand their evolving drivers and requirements. This way, we can innovate and adapt to meet their needs. Our solutions are not just for today, they’re for tomorrow.
ALT=""
## See our work in practice
Helping to deliver better outcomes in youth justice Somerset Council /files/BthSl5K0oZa4fmuQvreRhttps://necsws.com/digitalstudio/case-studies/delivering-better-outcomes-in-youth-justice/
Helping to protect the public by streamlining rehabilitation The Probation Service /files/4wkwVxfIQclb5BDiVnbIhttps://necsws.com/digitalstudio/case-studies/helping-to-protect-the-public-by-streamlining-rehabilitation/
# Bespoke case management Our ability to evolve with the market and innovate solutions for the future can be seen in our latest development. When we first started NEC Digital Studio, we took stock of our position in the market. Our products were doing well, but we knew we needed to be able to respond quickly to the demands of a fast-paced market. We realised we needed something low code, that could adapt quickly to new opportunities and allow us to better serve the market. Enter [AnyCase](https://necsws.com/digitalstudio/solutions/low-code-case-management/), our bespoke case management solutions. {% embed url="" %} Working in partnership with [KMD](https://www.kmd.net/), an NEC organisation in Denmark, we built on their existing low code solution and added a new user interface (UI) to create a brand-new tool ready to deploy to market. AnyCase can be incorporated into the delivery of our bespoke services or used as the foundation for future products. It is: * configurable * adaptable * and deliverable, fast.
""
## Our approach ### Efficient use of time Many of the services that are integral to AnyCase are required in new and exisitng products. This includes capabilities like Office 365 integration and workflow management. By utilising these services rather than redeveloping them, we're able to focus uon updating and modernising the UI in line with our user-centred design principles. We can also integrate with external services, like AWS, for email notifications and keyword identification. We meet client requirements faster, and can show them something tangible in a really short time frame when they come to us with an idea. So they know they can trust us to deliver the whole project. ### Never go out of style We’re committed to an NEC Digital Studio design system of reusable components and design principles. A key part of that is building our own component library with different options to fit different user needs. We’ll lean on the core principles of the Government Digital Service (GDS) guidelines, but we’ll flex and develop to make it more accessible and intuitive. Developing this alongside AnyCase will allow us to create consistency across all of our applications. We’ll have a unique and consistent look to our products, increasing brand awareness and our position in the market. Not to mention the time and efficiency saving of tested and proven components ready to be used in our designs. We’ve already been commissioned to create a detainee management system for the UK, built in AnyCase, that can ultimately be deployed to private and public prison systems across the world. Look out for more from AnyCase soon. ## See our work in practice
Developing a bespoke case management system to manage detainee requirements Ministry of Defencehttps://necsws.com/digitalstudio/case-studies/ministry-of-defence-partner-with-nec-digital-studio-to-build-detainee-management-system//files/yIBavBgP5GU2MZbt6Vgj
# NEC Digital Studio team Want to know more about a colleague's role? Take a look below to learn about what we do and how we work best with each other. ### A
Accessibility specialist **What is an accessibility specialist?** An accessibility specialist provides support, advice and guidance on how to create accessible digital products and services. They apply their knowledge of accessibility guidelines such as Web Content Accessibility Guidelines (WCAG) and Government Design Principles (GDP) to make sure products and services are accessible to all users regardless of their needs. They work internally to train and educate colleagues on the importance of accessibility, and make sure we follow accessible practices and documentation is accessible. **Come to us for**  Any accessibility questions you have about to your projects. We can help with: * Accessibility guidance for your products and services - we have an Accessibility Clinic where we can help with any questions you have * Evaluating and auditing digital content using assistive technology * Delivering training sessions on accessibility principles, tools and techniques * Facilitating testing with individuals with access needs * Advising on procurement of technology and services **How to work with us**  1. Try to involve an accessibility specialist at the start of every project – the earlier we are involved, the better 2. Invite us to kick-off, mid-point review and design crit meetings so that we can guide you on accessibility principles 3. Request an audit or review of your product or service with assistive technology such as screen readers, voice activated software and keyboards, as well as automated testing tools such as WAVE 4. Attend Accessibility Clinics or simply contact us to ask any accessibility questions you have
### B
Business analyst **What is a business analyst?** A business analyst is focused on understanding and improving business processes and systems to deliver value to users. They gather, analyse, and document business requirements through engaging with stakeholders, users, and subject matter experts. Business analysts facilitate workshops, conduct interviews, and use various modelling techniques to map out current and future states of business processes. They ensure that solutions align with business objectives and user needs, bridging the gap between user researchers, technical teams and business stakeholders. Their role is crucial in ensuring that change initiatives are implemented effectively, delivering measurable improvements to services and keeping stakeholder expectations managed through clear and continuous communication. **Come to us for**  * Defining and documenting business requirements * Conducting process modelling and analysis * Facilitating stakeholder and user workshops * Analysing and mapping existing business processes * Identifying improvement opportunities in business operations * Gathering and validating user requirements * Producing detailed specifications for new systems or enhancements * Conducting feasibility studies and impact assessments * Ensuring solutions align with business and user needs * Bridging communication between User Researchers, business stakeholders and technical teams **How to work with us**  1. Provide detailed information about your business processes and challenges 2. Actively participate in workshops and discussions to define requirements 3. Collaborate on creating and reviewing process models and documentation 4. Share feedback on proposed solutions and specifications 5. Keep us informed of any changes or new requirements
### C
Client and product support manager **What is a client and product support manager?** The client and product support manager is responsible for the management of the application support teams, monitoring service level agreements (SLAs) and reporting on performance statistics. They also look for opportunities for improvements and more effective ways of working for the support teams, provide information on the support packages available for bids and work closely with the central CSMs to ensure contractual key performance indicators are met. **Come to us for**  Anything that would require support resources input or anything that affects the second line support teams. We can help with: * Any support related queries, including specific tickets * Information about new contracts / applications due to go live that require support * Information on upcoming releases * Queries about the Ivanti tool and its functionality * SLA information **How to work with us**  1. Give us as much notice as possible when new products are in the pipeline – we will have a lot of questions! 2. If you have any support queries or require support time, we will have questions, pop a meeting in our calendars and we can chat about what’s required 3. If you’re sending a message on Teams, send us the context of what you’re requesting or want to discuss so we can prioritise your request.
Client service manager What is a client service manager? The client services manager (CSM) is responsible for the day-to-day management and delivery of contracted services to specific customer accounts. This involves working across the organisation to ensure all services are delivered to contractual service level agreements (SLAs), and to act as the single point of contact for all service delivery escalations. This not only covers the business-as-usual aspects but also service enhancements and upgrades, implementation of agreed non-project related plans, service / change management, business continuity plans, disaster recovery plans and client review meetings, along with attendance at audits where necessary. **Come to us for**  Help in understanding how we engage with our customers and how we make sure that the levels of service that we are contracted to provide are delivered to the agreed set of standards. We can help with: * Understanding the contractual obligations, we are committed to delivering for each of our customers * Clarifying how and when we communicate with our customers * Planning for service / change management, business continuity and disaster recovery **How to work with us**  1. We sit in the central team, so make sure you keep us informed about the specifics of NEC Digitial Studio 2. We liaise closely with the clients, so work with us to give them the best service possible
Content designer **What is content design?** Content design is a user-centred way of thinking about the words, pictures and other content in your product or service. It is more than just writing and editing. It uses the tools of user-centred design to make content: * findable * useful * actionable * clear * accessible **Come to us for** If you use words, pictures, video or any other content then you can ask a content designer for help. We can help with: * instructions * help, advice and support * buttons and other microcopy * navigation, taxonomy and other information architecture * interview scripts and consent forms * research reports * bids and pitches **How to work with us** 1. Invite us early, during scoping if possible. Don’t wait until you’ve designed your prototype to ask us to ‘just fill in the blanks’. 2. Don’t worry if we don’t start creating content right away. Just like other designers, we need time to do discovery. Give us time to do research, write user needs and map user journeys before we start designing content. 3. Talk to us. Not least because humans speak more clearly than they write. We need to you to tell us about your product or service using your speaking words. 4. Remember that content design is a design discipline, not just an editorial one. The quickest way to upset your content designer is to hand them some writing and ask them if they can ‘quickly jazz this up a bit?’
### D
Data analyst **What is a data analyst?** Data analysts use data visualisation tools like Tableau, Power BI, and Amazon Quicksight to create insightful dashboards. They possess expertise in data wrangling, dataset creation, configuring row-level security, and have a solid understanding of cloud technologies and data security principles. They play a crucial role in gathering and interpreting client requirements to deliver data-driven insights that align with business objectives. Data analysts can also touch on some data science practices to further derive insights and predictive analysis. **Come to us for**  Help making sense of data and providing value and meaning from raw datasets in the form of charts, visuals, or even basic reports. We can help with: * Data consumption and presentation * Data wrangling * Creating datasets * Producing dashboards for data driven insights * Making sense of data * Forecasting * Data discovery and profiling **How to work with us**  1. Provide detailed requirements. This could be in the form of formulas, expressions, calculations and expression written in plain English 2. Where possible, provide mock-ups to further help the data analyst with building the final product 3. Provide context and reasons what for the requirements and what value is desired
Data engineer **What is a data engineer?** A data engineer designs, builds, and maintains the systems and infrastructure required for the storage, processing, and analysis of large volumes of data. They work closely with data scientists, analysts, and other stakeholders to understand data requirements and develop solutions that enable efficient data workflows. Data engineers are proficient in programming languages such as Python, SQL, and Java, and have expertise in data processing frameworks like Apache Hadoop and Apache Spark. They are responsible for ensuring data quality, reliability, and scalability, often leveraging tools and technologies for data integration, ETL (Extract, Transform, Load) processes, and data pipeline management. **Come to us for** Questions around data movement, velocity, volume, and variety. We can help with: * Designing and building data pipelines * Data ingestion * Producing data models for transactional and analytical systems * Transform data from one format/structure to another * Designing database schemas **How to work with us**  1. Explain in as much detail as possible how the source data is structured and formatted 2. Give details on mapping and transformation rules 3. Remember, diagrams are our favourite language
Data lead **What is a data lead?** The data lead assembles and leads a team of data experts, including data engineers, data scientists, and data analysts. They develop robust data strategies, working closely with the business to ensure that data strategies align with business objectives. **Come to us for**  Advice for any potential projects that require data movement, migration, integration, modelling, visualisation, data analysis, forecasting, machine learning, GenAI, reporting and/or visualisations. We can help with: * Communicating data strategies * Brainstorming * Setting up a sub-team for project work * Specific data challenges like: * Presenting data in a dashboard * Ingesting data from a different source * Extracting data * Creating sample data **How to work with us**  1. When you have a specific data question (like the examples above), contact us to book a short 15-30min meeting. We need to talk through the what, when and why of your request so we are in the best position to help you 2. Always start with the high-level concept, objectives and goals when you share a request 3. Communicate the value that would be added by your request 4. Work with us to agree on scope and further requirements
Data scientist **What is a data scientist?** A data scientist uses scientific methods, algorithms, and systems to extract insights and knowledge from structured and unstructured data. They apply techniques from statistics, machine learning and data analysis to interpret complex data sets, identify trends, and make data-driven decisions. **Come to us for**  Everything to do with insights and data. We can help with: * Programming. We’re proficient in programming languages such as Python, R, and SQL * Statistics. We have a solid foundation in statistical methods and hypothesis testing * Machine Learning. Ask us about our knowledge of machine learning techniques and frameworks * GenAI Expertise. We have experience with generative AI models like GPT, GANs, and VAEs * Data Wrangling. We have the ability to handle, clean, and preprocess large data sets * Visualization Tools. We are familiar with tools like Tableau, Power BI, and Matplotlib * Communication. We can help explain complex data insights in a clear and understandable manner **How to work with us** 1. Provide full requirements and context 2. Start with the end in mind, and share that long term goal with us 3. Provide data and supporting information 4. Be open to ideas and change
Delivery manager **What is a Delivery Manager?** A delivery manager is responsible for ensuring that the team delivers high-quality products and services effectively and efficiently. They facilitate the team's work by removing obstacles, coaching team members using agile methodologies, and maintaining a focus on delivering value to users. They work closely with stakeholders to define objectives, track progress, and manage risks, while fostering a collaborative and productive working environment. Delivery Managers help align team efforts with broader organisational goals, ensuring timelines and budgets are respected, and continually improving processes and practices. **Come to us for**  * Facilitating communication between team members and stakeholders * Removing impediments and obstacles that hinder project progress * Ensuring that project timelines and deadlines are met * Supporting the organisation and running of agile ceremonies such as stand-ups, retrospectives, and planning sessions * Managing project risks and issues and finding solutions * Tracking and reporting project progress to stakeholders (NEC and customer) * Assisting with resource allocation and workload balancing within the team * Providing coaching and guidance on agile practices * Overseeing budget management, ensuring efficient use of resources and revenue recognition * Ensuring alignment of team objectives with overall organisational priorities. **How to work with us**  1. Regularly attend and actively participate in scheduled agile ceremonies 2. Communicate any blockers or challenges you're facing as soon as they arise 3. Collaborate with us to set realistic goals and timelines 4. Provide feedback on processes and suggest improvements during retrospectives 5. Keep us informed of your progress and any changes to your capacity
Delivery operations What is delivery operations? The delivery operations team works alongside the different project delivery teams and managers to assist the successful delivery of projects. They ensure we deliver projects on time, to budget and to our customers' satisfaction. The team assists throughout the entire project lifecycle, supporting with proposal creation, resourcing, commercial guidance and assurance, project setup and support with ongoing project management and reporting. **Come to us for**  Assistance and support with all aspects of project delivery, resourcing and assurance. We can help with: * Customer proposal creation * Commerical support - order processing, CCNs, invoicing, etc * Kimble project setup and guidance * Resourcing requests and assignments * Working at risk guidance * Project reporting guidance * Internal project requests **How to work with us**  1. Where appropriate, use the forms available through the Life at NEC Digital site to request assistance from the team 2. For other requests, use the ‘Ask Delivery Ops’ Teams channel 3. Be timely with requests to the team, especially for things like resources, as these may not be straightforward (conflicting requests, contractor lead time, etc.) 4. Be proactive in letting us know about project and resourcing issues, such as absences, delays, etc. 5. Be prompt in responding to requests from the team for project updates, and adherence to baseline project financials and timescales
DevOps engineer **What is a DevOps engineer?** Commonly referred to as ‘DevOps engineers’, development operations engineers support the development and operation of software through tools, environments and practices. Their primary goal is to streamline the development, deployment, and operational processes to deliver software more rapidly, reliably, and efficiently. They are responsible for underpinning good development processes including managing tools and testing environments, central code control, maintaining development standards and writing software that automates systems. **Come to us for** If you have a manual development process that is cumbersome and error prone, we can help automate and streamline this to make it more automated and error free. We work with the software developers and scrum teams to help implement the infrastructure and automation to help the solutions run and deploy smoothly. We can help with: * Questions about AWS environments used across NEC Digital Studio * Help with deploying code or pipelines in use * Troubleshooting issues with public cloud environments * Help with application monitoring * Automating development and deployment process * Developing IaC code to create consistent environments to work with **How to work with us** 1. We have a dedicated DevOps board in Jira that is used across project, please log your requests here. 2. If you find an issue with any of the processes, please provide as much details as possible to help us troubleshoot the problem. 3. We are always looking for ways to improve our process of you have any suggestions please let us know
### E ### F ### G ### H
Head of design school **What is a head of design school?** The Head of Design School oversees all external training and learning activities. They lead the Design School, which delivers user-centred design (UCD) training to the public and bespoke training in house to organisations. Our training is both a product and a service to our customers, and is also accessible for internal staff. They also head up product training, which delivers training to help our customers use our products. **Come to us for**  All things learning. We can help with: * Writing and delivering UCD training * Discussing product training * Working up new ideas for courses * Advising on best practise for learning * Working up ideas that include training, such as workshops, hackathons, mentoring packages etc * Contributing to bids that include training * Liaising with clients around their training needs * Advertising training at external events **How to work with us**  1. Come with an idea for training (this may be a gap you’ve noticed, or a subject you are passionate about) that we can help you shape and form 2. Include us – we like learning, and therefore we’re keen to be involved in different areas of the business, to understand it more and work together. 3. Involve us from the start 4. Share examples and photos from projects that can be used in training 5. Come to pilot courses and contribute to their development 6. Sign up to come along to public courses (and be ready for interactive activities)
### I
Interaction designer **What is interaction design?** Interaction design is the practice of designing usable and accessible digital products and services. It involves defining the structure and behaviour of interactive systems, including: * the layout * the user * the flow * the navigation Interaction designers use principles of usability, psychology, and human-computer interaction to craft interfaces and experiences that are: * seamless * intuitive * functional * enjoyable to use. **Come to us for**  Support, help and guidance on creating digital services that meet user needs, and designing user interfaces that are intuitive and accessible to use. We can help with: * turning problems into solutions * making ideas come to life quickly through prototyping at various levels of detail, from hand-drawn sketches to fully coded prototypes * Design Systems and how to build libraries of user interface elements that help us work more efficiently * making online experiences accessible so all users can benefit * drawing things, such as flow diagrams and detailed user journeys **How to work with us**  1. Bring interaction in at the start of a project. We work best if we have a good understanding of the problems you're trying to solve and what you're trying to achieve 2. Remember we are not here to create pretty graphics, we create designs based on user needs, and sometimes that might look plain and boring! 3. Give us a style guide or design system to work from if you have one 4. Design is a team sport, so please invest your time in the design workshops and activities your interaction designer runs with the team 5. We want to be a part of your team, not just consultants. So, invite us to your stand-ups, agile ceremonies and relevant meetings
### J ### K ### L ### M ### N ### O ### P
Product manager **What is a Product Manager?** A product manager is responsible for driving the success of their assigned product(s) from ideation to market launch and beyond. They collaborate with cross-functional teams, translate customer needs into innovative solutions, set priorities for the delivery team and contribute to the division's overall product strategy. They also play a pivotal role in client demos to aid business development efforts. **Come to us for**  Information, advice and guidance on our products. We can help with: * Bid writing for our products * Demonstrations of products * Understanding the future product strategy * Understanding the product roadmap * Information on our customers and best way to communicate with them **How to work with us**  1. Set up meetings, we love to talk about our products and business area. Just check our availability as we may have demonstrations or be travelling to customers. 2. If you see us in an office and have questions, come over and speak to us. 3. Provide us with some idea of what you would like to know (we can talk forever about our products), would you like a demo of the product, want to know the business area or not sure but want an overview? It can help us prepare and not overload you with information. 4. If you would like us to demo a product, give us as much context to the client and potential use cases so we can adapt our demo to suit their requirements. 5. If you have any actions you need us to complete, send them in an email so they aren’t missed. But also feel free to give us a message on teams with any questions.
Product owner **What is a product owner?** The product owner oversees the ongoing development of our product suite, supporting product managers in defining, planning, and managing the product vision, strategy, and execution. The product owner works closely with stakeholders, customers, and developers to gather and prioritise product requirements, translating them into actionable user needs and stories. They also act as the main contact for product queries and manage the product backlog based on business value, complexity, and risk. **Come to us for**  A practical, in-depth knowledge of specific customer needs and requirements for the products they use. We act as the subject matter expert for the application and understand both the strategic and tactical direction our products will take. We’re central to application development and should be the first person you call if you have a question about the direction a development project is taking. We can help with: * Prioritising features for the future development of an application to maximise business impact * Understanding the short, medium and long-term product roadmap of an application * Understanding how to translate business requirements into technical pieces of work * How to engage with development teams on a day to day/practical basis * Translating technical details into user benefits to be used for marketing and promotion **How to work with us**  1. Include us during the planning process when trying to understand the impact of certain features on the applications end users 2. Maintain regular contact throughout the development process to make sure the right features are being developed at the right time to maximise business value 3. Understand that we will put business value first and may not be aware of technical considerations which may determine feature priority
Product trainer **What is a product trainer?** The product trainer leads, designs, and delivers application training services to customers, enabling them to gain maximum understanding and proficient use of NEC Digital Studio’s software products. They are also responsible for all the training materials and documents. **Come to us for**  Planning and delivery of training on NEC Digital Studio software products. We can help with: * Planning training needs for customers * Creating and updating training materials * Delivering classroom and online training * Providing feedback from training * Post-training support **How to work with us**  1. Keep us informed of potential training needs and when they are required. 2. Let us know what training the customer is expecting. It is good to know what is expected in terms of content, delivery format and number of days. 3. Introduce us to the client or customer who is the training contact. The sooner we can build a relationship with them, the easier it is to understand their needs. 4. Send any actions by email. As we work over multiple products and customers, we are not always available and cannot always provide an instant response. Emails are easiest to track. 5. Let us know the best channel for feedback from training. This can be feedback about the product or feedback from the client, customer, or user.
### Q
Quality assurance analyst **What is quality assurance?** The quality assurance (QA) team defines the quality assurance strategy across the whole of NEC Digital Studio and sets the standards that need to be followed to ensure the quality of development across all our products. They are responsible for making sure that applications are built and developed according to the documented design and user requirements. These requirements can be of a functional or non-functional nature and may involve both manual and automated testing techniques. Ultimately, the QA team acts as a gatekeeper ensuring that the quality of the product being developed are of a sufficiently high standard and fit for release into production. **Come to us for**  Understanding the different types of testing that we undertake, including manual, automated and performance testing. We can help guide how the testing process fits into the software development lifecycle and how the QA process embeds quality into the development practice. We can help with: * Creating test scripts for manual test execution activities * Planning and implementing QA processes into existing and new development projects, including automated, API, performance, functional, non-functional and manual activities * Implementing test automation frameworks to replicate end user activities and to build relevant automated tests * To help clarify how issues raised to the support desk by users can be integrated into the development scrum process **How to work with us**  1. Use the QA lead as an initial point of contact. They will be able to guide you through what options are available and how the QA function can help improve product quality 2. Get the QA team involved as early as possible. The sooner we’re engaged, the better the quality of the final development product will be 3. Embed the QA team in both the design and development functions. They need to be fully aware of the user requirements, documented design and development practice to formulate their testing accordingly
### R ### S
Scrum master **What is a scrum master?** A scrum master leads agile implementation, facilitates scrum processes and empowers teams for efficient product delivery. They work closely with development teams, product owners and stakeholders to foster collaboration and ensure alignment with product goals while upholding financial and technical governance. **Come to us for**  Help understanding the scrum process and how we interpret scrum at NEC Digital Studio. The way we run scrum development projects will vary from project to project, but the basic structure of the team and core processes we use will be common throughout all our projects. We can help with: * Communicating to internal and external stakeholders how we implement scrum * Clarifying the roles and responsibilities of team members and who is responsible for what * Understanding what the expectations are from clients and how they can impact the performance of the development team * How to structure development teams when planning projects * Understanding how UCD can be integrated within development teams **How to work with us**  1. Include the scrum master in the early stages of project setup to make sure the correct structure is in place to work out what resources and people need to be considered for an effective scrum team to operate 2. Invite us to occasional internal design team meetings so we’re kept abreast of the latest updates in UCD and further understand the roles and responsibilities of those involved and share knowledge 3. Get in touch if you have an interest in development and want to understand more about how we implement scrum for different types of projects and how to present thoughts and ideas
Service designer **What is service design?** Service design improves connections between users and the organisations which serve them. Services are everywhere. They’re complex and messy. Whether we’re booking a GP appointment, paying our rent, claiming benefits, or doing our shopping, services underpin all that we do in society. Service designers blend systems thinking and user-centred design to understand and solve the most complex challenges. Using a broad selection of tools and collaborative approaches, we help organisations explore the future of their products and services and create attainable strategies for getting there. **Come to us for** We can help with: * Understanding and communicating issues and opportunities with an existing service * Co-designing and communicating visions and strategies for new end-to-end services * Convening users and stakeholders to tackle issues and build consensus in creative and collaborative ways * Developing maps, diagrams, storyboards and other artefacts which provide compelling stories for change * Co-designing offline and online prototypes and touchpoints across multiple channels, systems and technologies * Designing accessible and inclusive services that work for everyone * Reducing risk and cost through evidence-led decisions and prioritisation * Building client service design capability for ongoing quality and improvement **How to work with us**  1. Bring us in early. We’re great at helping you to define your scope, acting as an impartial convener to identify challenges, create project briefs, identify goals and outcomes. 2. Work transparently and collaboratively - we love developing strong relationships with stakeholders. 3. Be prepared for us to question everything. We’re not happy unless we’re working in knotty and complex spaces. 4. Look beyond digital. We will likely want to go beyond the realms of digital to understand the full extent of a service
Software developer **What is a software developer?** Software developers (sometimes known as software engineers) play a pivotal role in creating innovative software solutions. They collaborate with cross-functional teams to develop cutting-edge applications that meet our clients' needs. Their responsibilities include writing clean, efficient, secure, and maintainable code, participating in code reviews, and troubleshooting software issues. They usually work on either the front-end (the user interface we interact with) or the back-end (the application logic), but some consider themselves full-stack. They contribute to the continuous improvement of all our software products. **Come to us for**  If you need to know how the application software works or how it communicates with other software and services, we can usually help you. Any required development tasks must always be directed through the Scrum Master for the given project. We can help with: * Bringing the ideas our business community has to life in our software solutions * Troubleshooting and resolving issues with software **How to work with us**  1. We usually work in a scrum team. That means working in 2-week long sprints and in line with scrum and agile processes. Please use the appropriate methods through the scrum framework to ask us for support. 2. Our work is allocated in 2 week sprints. So if you have a task that requires development support, create a ticket and provide the ticket details to the scrum master for that project. 3. If you find an issue with any software, please provide as much details as you can to help the developer identify the cause. This includes logs, screen shots, device, time and date, as well as the steps to reproduce the issue
Solution architect **What is a solution architect?** Solutions Architects plays a crucial role in designing, overseeing, and ensuring that software systems and applications meet both the technical and business requirements. This role bridges the gap between business needs and technology solutions, ensuring that the architecture of systems aligns with the customers goals, technical standards, and long-term strategy. **Come to us fo**r Support resolving a technical problem. Solutions architects create documentation to help justify required developments and provide the details product teams require to progress. They also have an overview of the technical landscape across the business, to help us make more informed decisions about future solutions. We can help with: * Help translating business requirements into technical specifications. * Evaluating and recommending technologies, frameworks, and third-party solutions to best meet the needs of the project. * Provide technical guidance and resolve issues that arise during development. * Design solutions that integrate with existing systems, ensuring smooth interoperability and data flow between different components. * Work with security teams to ensure compliance with relevant standards and regulations. **How to work with us** 1. Bring us in early to advise. We work closely with the bids team across various opportunities to help us make the right choices early on in our projects. We create the designs and documentation that can be required for bids and project delivery. 2. Explore challenges with us. We can help modernise legacy solutions and migrate them to current technologies and cloud environments. 3. Connect us to people. We are happy to engage with end-users and clients to help inform our recommendations.
Support consultant **What is a support consultant?** Support consultants provide second line support to customers using our applications, both online and over the phone. Their responsibilities include addressing customer inquiries, investigating incidents, maintaining detailed records, monitoring system logs, reacting to alerts and supporting application roll-outs. **Come to us for**  Everything related to second line support (like technical assistance and advice and guidance). We can help with: * Supporting the applications * Access requests to the applications **How to work with us** 1. If you require application support (including accounts created etc.) please log a ticket in Ivanti. Calls take priority so you will get a faster response 2. If you need our support for more than 10 minutes, please clear our time with our manager so we can manage workload efficiently
### T
Technical architect **What is a technical architect?** The technical architect is responsible for the detailed design and implementation of specific components or aspects of a software system. They focus on the technical elements, ensuring that the architecture of the software is well-designed, efficient, and aligned with both the project's requirements and best practices. **Come to us for** If you have a specific area of an application or design that you need to create with particular requirements (for example low latency or high throughput). We can help with: * Creating detailed technical designs and blueprints for specific components or modules within a software system. * Defining how these components should be structured, the technologies to be used, and how they will interact with other parts of the system. * Evaluating new technologies and assess their applicability to the project. * Producing comprehensive technical documentation that details the design, implementation, and operational aspects of the component. **How to work with us** 1. Log a ticket in our Jira board detailing the technical problem you are trying to solve. 2. Talk to us about any ideas you have that you are unsure if they can be achieved with a given technology. 3. Speak with us. We love helping developers implement new technologies and are happy to have virtual whiteboard sessions.
### U
User researcher **What is user research?** User research is the process of understanding the behaviours, needs, and motivations of users. We use various research methods such as interviews, surveys, usability testing, and data analysis. The insights we’ve gathered inform the design and development of user-centric products and services. This research ensures that the end solutions are effective, user-friendly, accessible and meet the actual needs of the target audience​. **Come to us for**  Everything related to users, understanding their needs and testing out new ideas. We can help with: * Understanding your users or potential users * Testing new concepts and providing actionable feedback * Usability testing with real or potential users to find out how your product or service is working * Bringing rigour and quality to analysis and synthesis * Translating research findings into actions * Telling compelling stories about users to your product teams, owners and clients **How to work with us**  1. Talk to us early about the project, product or service and what you are trying to achieve 2. Get involved! Come along to our sessions where we talk directly to users so you can see and hear first hand
UX designer **What is UX design?** User experience (UX) design is the process of creating products that provide meaningful and relevant experiences to users. As UX designers we cover all aspects of design, from user research, user testing, wireframing, content, interaction and visual design, information architecture, accessibility, and prototyping. UX designers focus on enhancing user satisfaction by improving the usability and accessibility of the product. They use various research and design methods to understand user needs, behaviours, and pain points, and to create solutions that meet those needs effectively. **Come to us for**  Delivery of end-to-end user centred design, focused specifically on products within NEC Digital Studio and NEC Software Solutions. We can help with any size of project, from the creation of a new product, a complete product redesign, or a change to an existing product (including usability and accessibility audits). We can help with: * Making sure our products: * meet business and user needs * are deliverable within time and budget * are functional, accessible, intuitive and engaging * General queries or concerns via our UX clinic * Any issues with an NECDS or NECSWS product that is affecting the users * Support with bids, events and sales. We can create quick prototypes to demonstrate a concept, instead of trying to explain everything with words or static images **How to work with us**  1. Speak to us when you form your project plan. We can help you to understand how long each stage is likely to take 2. Think of us as part of your project team and include us in the project kick-off 3. Ensure we have access to test systems as appropriate 4. Share information about how a user currently completes a task, or support us in gathering it 5. Allow time for user testing, checking workflows and design concepts early on to allow us to quickly iterate as needed, saving time and money
### V ### W ### X ### Y ### Z