Designing B2E Software: Develop Phase

General Considerations

The engineering, or development phase, is the cornerstone of the software development lifecycle. It follows the design phase and aims to deploy the software based on requirements gathered and designs created in the previous phases. However, we will not touch on the process of writing a code, shipping the code into the environment, or any other tech-related topics in this article. Instead, we’ll talk about the importance of design within the development phase.

Let us look at the difference between B2C, B2B, and B2E approaches to tackling design while developing a new piece of software.

• In financial corporations, teams work mostly in silos, so designers “pack” their artifacts and pass them to the engineering team. (Kudos to you if you work in a cross-functional team!)
• Close to zero communications happen between silos until the new phase starts.
• Funds allocated to building software for internal use are classified as support costs and not as an investment.

Let's examine the software development process and review how the right design approach could eliminate inefficiencies and bring additional value.

Software Engineering Process

Companies follow a variety of methodologies to ship products on time. Scaled Agile Framework, Scrum@Scale, and Large-scale Scrum are very well-documented frameworks, and companies decide which one to adopt based on many factors, including the organizational needs and the existing practices. But the basic flow stays the same: understand requirements, write code, test what was done, deploy, gather feedback, and repeat.

Even though this set of steps is oversimplified, this approach helps us understand the challenges that professionals face at each stage and ways that design professionals could help at each stage.

Requirements Review

We observe many companies that pass written requirements or extensive PowerPoint decks that describe how a system should work. We have even seen prototypes built using Excel and a bunch of macros. But is it the best way how to ensure that the engineering team understands the set of requirements?

As human beings, we consume 90% of information visually. This is why we, as computer users, moved away from console-type interactions to graphical user interfaces. So, why do some product leaders continue passing requirements to the engineering team in the form of an article rather than a picture?

That is where design artifacts like screen designs, design systems, and interactive prototypes come into play. A nicely done UI design of a screen brings more specificity to an engineer than a bunch of paragraphs of " As I user, when I do X, then I expect getting Y.”

Such an approach brings more valuable results in the B2E realm, where stakeholders want to be as cost-effective as possible.

Not only does UI design help engineers understand the goal, but also enables the team to uncover challenges and major time-consuming elements swiftly. We’ve seen so many times when the team was under the impression that they clearly understood the objective of a sprint. However, after we reviewed several mockups, there was a significant “a-ha!” moment, and the team understood they missed some data points, underestimated the complexity, or found a way how to reuse something they had already created.

We’ve even tested the “design as a requirement” approach, in which all interactions except complex calculations were documented as interactive prototypes enriched with inline comments. It worked well for a comparatively small team building an internal risk-management platform.

Writing the Code

Engineers (mostly) like working with UI designs instead of requirements solely in writing. Actually, most engineering teams are more motivated when they implement a good-looking, sleek UI design rather than implementing the requirements based on some random template.

However, in the B2E case, most internal teams struggle as they don’t have sufficient access to designers. This leads to assigning design-related work to managers, business analysts, and engineers. So, engineers get more things on their plates—not only do they need to write a working piece of code, but they also answer a bunch of design-specific questions.

“Should it be a drop-down menu or a set of radio buttons? Or checkboxes?” “Should I make navigation a set of buttons or tabs?” “Which color should I use to highlight search results?” Could engineers answer such questions? Surely they could. However, this creates an enormous additional cognitive load and responsibility, and, as a result, users are less happy.

Design-backed Software Testing

Quality assurance engineers perform manual testing by comparing real outcomes with the expected state. The expected state, in most cases, looks like a set of test cases—descriptions of what should happen. You may imagine how hard it is to compare the real results with the expected ones if there are no visual references. That is another place where previously created mockups and user interfaces can be handy.

First of all, adding UI designs to test cases speeds up the overall process of onboarding quality assurance engineers onto the project. They understand the goal and the business value easily if they refer to UI prototypes or any visual materials.

Secondly, QA Engineers are able to find visual inconsistencies. They may seem less of a priority, but visual consistency is an inevitable part of a seamless user experience, thus resulting in a better adoption rate and user satisfaction.

Thirdly, due to the specifics of the B2E realm, company managers would have a better picture of the ongoing processes and robust reporting materials if designers had provided visual assets.

Feedback Gathering

Not only should the product team deploy something and provide value to the end-user, but it is also essential to support a continuous feedback loop. Feedback gathering is way more accessible but more impactful in B2E software development, as the number of users is narrow, so each feedback piece is more important than in B2B or even B2C software.

Sometimes, user interface designers are not invited to feedback sessions or such activities. This happens if the company treats the design team as the team focused on the “future”—new features, new screens, etc. But design professionals need to be there in a feedback loop, here is why:

First, designers should verify if the team implemented the functionality correctly and according to the designs. Project managers wrongly assume that the software piece, developed following the requirements, would work according to designs. Unfortunately, many things could go wrong, and critical flows may be ignored entirely if the design team is not involved in the feedback loop.

Second, designers help untie circular feedback loops. When it comes to gathering feedback from the end users, we’ve seen several scenarios when the team fell into a never-ending cycle—the team releases a feature, users provide feedback to change it, the team releases a fine-tuned feature in several iterations, and users provide contradictory feedback that puts the system in the initial state. Well, this happens, and not all hypotheses do bring value, so it is okay to roll the system back sometimes. Design professionals can facilitate revisiting design history and quickly analyze what caused decisions that were translated into a “wrong” functionality. It is also easier to find alternative solutions based on previously rejected screens, concepts, or other materials that were generated in previous stages.

Third, design professionals need to get feedback for future self-enhancement, like all others. Even though it seems sometimes unreasonable to get another person to a feedback session or meeting, it may have a positive impact on the future product and team progression.

Summary

In the B2E software design process, design plays an important role. It is not essential or crucial, but it brings so many benefits to consider:

• Design helps engineering teams understand requirements efficiently, decreasing the number of mistakes, bugs, and misinterpreted requirements.
• Well-done designs keep the engineering team more motivated and engaged.
• Requirements and acceptance criteria enriched by designs make manual testing processes swifter and more precise.
• Design professionals involved in the feedback loop can enhance productivity and decrease the number of unnecessary engineering iterations.