Designing B2E Software: Design Phase

General Considerations

The design phase is one of the phases of the software development lifecycle. It follows the discovery phase and aims to produce a detailed blueprint of the software's architecture and interface. When the discovery phase is over, it is time to start bringing ideas to life and extensively verifying them. So, what is the difference between B2C, B2B, and especially B2E approaches?

Let us start with several important notes that we’ll be relying on:

• In B2C and B2E, the UX design is paramount. However, a great UX would not bring more customers beyond the number of employees who would use the B2E system.
• Great, visually appealing design is good, but it adds value for marketing in the B2C segment.
• Unlike in the B2B case, there is only one organization with its set of data.

Now, it is time to understand the objectives of the Design phase.

Objectives of the Design Phase

The primary goals of the design phase are to translate insights from the discovery phase into actionable design elements and to create a user-centric interface that aligns with the organization's strategic objectives. Key objectives include:

1. Creating User-Centric Designs: Develop intuitive interfaces that cater to employees' specific needs, ensuring high usability and engagement.
2. Developing Prototypes: Create low-fidelity and high-fidelity prototypes to visualize the software and gather early feedback.
3. Incorporating Feedback: Iteratively refine designs based on user and stakeholder feedback to ensure alignment with expectations.
4. Ensuring Technical Feasibility: Collaborate with technical teams to ensure that designs are technically viable and scalable.

Design Consistency Over Visual Attractiveness

One important thing to consider while designing the application is consistency across the other applications. This would require reviewing the existing application ecosystem that employees use right now. The existing applications may dictate some patterns that are obvious to users, and they will stick to them regardless of whether there are better solutions.

For instance, we were in the process of designing a new platform to manage financial vehicles. In the previous system, the uncollapsible rows were indicated with a “+” sign. Users used to understand the “+” icon as something they can uncollapse and the “-” icon as something they can collapse. We could see that using triangles or arrows for collapse and uncollapse is not intuitive for the user group, and if we try using the “+” icon to indicate the addition of something, it is perceived as something to uncollapse. We decided to proceed with the old pattern even though this is not the best solution outside the company.

Do not Design for a User, Design for Jessica and Brad

When designers start building the user interface, they think about the “generalized” person, a user. Those abstract users (even if user personas are created) are hypothetical, and designers could only imagine how such personas would behave. Luckily, in the B2E realm, designers actually build systems for real human beings they (mostly) have access to. Designers create an application for the real Jessica, who works two floors above in the same building, and for the real Brad, who is on vacation today. Even several discussions with future users can make a bigger impact than dozens of empathy maps and user journey diagrams.

Build Personalization Over Customization

Designing a user interface for hundreds and thousands of human beings may be challenging. People with different cultures, backgrounds, and experiences would ask for different, mostly conflicting ways of how they prefer doing their work. That is why B2B systems provide a wide range of customizability options, so users can set their working environment as they need. In the B2E realm, there is no need to give control to configure the system according to the specific requirements. Instead, as we are able to define users’ needs precisely, we can design the right personalization—the process where the system tailors content or functionality to the user automatically, mainly based on the user’s assignment to a functional team or group.

Both personalization and customization aim to enhance user experience by making software more relevant and efficient. However, it makes more sense to focus on the former while keeping the latter at a minimum.

Think About the Side Effects

In the B2E world, the organization acts as the independent consumer and beneficiary of the product, and the organization’s goals and needs may conflict with the end-user's needs. Those requirements should be prioritized over users’ feedback. Even if this approach goes against the generally accepted user-centered methodology that prevails in the B2C realm, we should acknowledge this priority when we design B2E applications.

Let us consider something as simple as a confirmation screen when a user creates another record. Most users would say that an additional confirmation screen is unnecessary and requires one more click. However, this confirmation screen acts as a “sign-off” or acknowledgment of an employee who creates a record. This acknowledgment will be important for the company in terms of user accountability and will help a lot if things go wrong.

Be Mindful of Resources

B2E applications have one significant drawback—they always increase costs and eat budgets. From the organization's perspective, custom software for employees is a risky investment with a foggy ROI. So, being cost-effective is more important than ever. We cover it in detail in the Principles of Cost-Effective Design article. For a B2E domain, here are some additional methods that help reduce costs:

• Do not overcomplicate. There is no need to think ahead for three years, but there is a need to focus on the current efficiency. Unlike in the B2B, scalability and further evolution of a product are not a priority for most B2E systems. There are no straightforward rules that help decide what you can do in a quick and dirty way; just use common sense for that.
• Don’t skip obvious things. It seems logical to skip something trivial like the authorization process first and prioritize features that actually bring value. However, the team should dedicate some time and visually rebuild such omitted flows a bit later. This helps engineers see the full picture, avoid overthinking, and streamline testing procedures.
• Cover as many corner cases as possible. While project managers and stakeholders consider the project's value and how it would work, they pay less attention to how the system would behave if things go wrong. In a perfect world, nothing would go wrong; however, we live in a real world. On the engineering side, all cases should be covered, regardless of whether they are success case scenarios or not. Covering such cases is a designer's responsibility.
• Design for target screen sizes, deprioritize or skip the other sizes. A risk analyzer tool does not need a mobile-ready design, as nobody analyzes financial risks on the go. Similarly, point-of-sale terminal software does not need a responsive-ready design if it is to be deployed to the same device model with the same screen size.

Keep Content and Math Consistent

Content is a vital part of the design process in general. It includes plenty of elements, like the overall tone of voice, the way buttons are labeled, the way questions or confirmations are stated, etc. When it comes to designing the content for employees, professional jargon and abbreviations start playing a significant role.

The straightforward approach used in the B2C world builds on common-sense principles, like clarity and conciseness, accessibility, consistency, actionability, and inclusiveness.

In the B2E world, professional jargon is inevitable as it makes more sense faster. So, “assets under management” or “net asset value” should be replaced with “AUM” and “TNA,” as those abbreviations are widely used among the target audience. Interfaces built for employees may be confusing from the start, but they would be more functional and effective after training and several cycles of use. The same approach applies to professional jargon for actions, documents, processes, and even system modules.

Another major part of copy and content design is math. While designers focus on layouts, fonts, usability, and affordance, users look first at content. A good design team understands that people involved in demos or working sessions pay attention to the content and immediately find wrong math, unrealistic numbers, and wrong trend directions. So, building a cohesive, realistic B2E design and getting relevant feedback requires designers to dive into calculations and verify the correctness of data and math. Otherwise, the team would spend hours and hours discussing irrelevant data-centered issues, missing the opportunity to get design-centered feedback.

‍

Conclusion

The design phase is another impactful phase in the successful development of B2E software. It builds the right blueprint for the future system or application, aligns stakeholders, and saves costs on future development.

The main takeaways from the B2E approach of the discovery phase are:

• Designing consistency should be prioritized, as it makes the learning curve shallower.
• Designing for current employees is preferred to designing for a “user persona.”
• Perzonalization design plays a significant role, replacing customization where it is possible.
• The design process should include the organization as the independent consumer and beneficiary of the product.
• Cost-effectiveness is a vital part of a design phase in the B2E realm; it is even more important because business-to-employee apps don’t generate revenue directly.
• Content design could and sometimes should include jargon and abbreviations if they are well-known across the organization. Data grids should have consistent content and math to avoid irrelevant discussions and non-actionable feedback.