
The modern workplace is undergoing a digital transformation, and Business-to-Employee (B2E) software is at the forefront of this evolution. B2E applications are designed to improve employee engagement, streamline operations, and enhance productivity. However, the success of such software hinges on a well-executed discovery phase. The discovery stage is critical in ensuring that the final product meets users' needs and expectations. This article explores the importance of the discovery phase in designing B2E software, outlines the key steps involved, and highlights key differences that designers and product managers should consider.
The discovery phase is one of the phases of the software development lifecycle. It begins first and aims to understand project requirements and objectives clearly. Let us start with several important notes:
Let us start with the straightforward list of objectives product managers should achieve during a Discovery Phase.
Conducting user research is essential to gather detailed insights into employee workflows and behaviours. Product teams need to involve multiple stakeholders — internal employees, department leaders, and internal IT teams — in the process of understanding employees’ needs, pain points, and workflows. Legal and compliance requirements should be included as soon as possible, as requirements on data warehousing, information access, and sharing may have a direct impact on the result of a discovery phase.
Workshops are the most efficient way to get a solid understanding of users’ behaviour in this phase. In the B2E context, it makes more sense to involve a significant number of end-users. This shifts the focus from vague business objectives to improving internal employee experience and aligning with organisational goals. An employee-centred approach yields better, long-lasting, tangible results compared to a generic workshop suitable for B2B and B2C segments.
One reason the B2E segment exists and companies decide to design and build their own software applications is that no such product suits existing needs. There are no direct competitors, and there is no easy way to draw inspiration or analyse what others have done. However, the team should focus on other tools and approaches that face the same challenges but in different industries.
For instance, if the team is building an external-caused risk analysis tool in the financial vertical, product managers and designers could draw inspiration from weather forecasting and analysis tools. In most cases, the real competitors of B2E systems are Excel for data-related processes, email for feedback-related activities, and PowerPoint to store organisational knowledge.
Based on the insights gathered, a comprehensive list of requirements is drafted, including functional requirements (specific features and functionalities) and non-functional requirements (performance, security, usability). Prioritising these requirements is crucial for effective project planning and scope management.
Teams should be aware that in the process of translating needs into requirements, stakeholders lean towards overcomplication and overestimation of future needs. User experience is paramount in B2E — the software must be engaging, easy to use, and designed to fit seamlessly into employees’ daily routines.
Creating low-fidelity prototypes or mockups allows for early visualisation of the software. These prototypes can be shared with stakeholders and end-users to gather feedback. Iterative refinement based on this feedback ensures that the design aligns with user expectations.
The prototyping step is the most valuable, as stakeholders find it easier to react and respond to something visual like a wireframe or a prototype than a written user story or a diagram. Product managers and designers could verify hypotheses on a daily basis and get a solid understanding within two weeks of the discovery phase.
In collaboration with the IT team, a technical assessment is conducted to evaluate the feasibility of the proposed solution. This process includes reviewing existing infrastructure, identifying potential integrations, and assessing any technical risks. Unlike in B2B or B2C realms, the team could precisely define the necessary list of integrations and all integration details.
The final step of the discovery phase is detailed project planning. This step includes defining the project scope, creating a timeline, estimating costs, and identifying the team members who will be involved in the development. A clear project plan sets the stage for a smooth transition into the design and development phases.
The discovery phase is crucial in the successful development of B2E software. It lays the groundwork for a product that truly meets users’ needs and aligns with the organisation’s strategic goals. The main takeaways from the B2E approach of the discovery phase are: