In the Kingdom of Calendar, or how to integrate the UX team with the front-end team

In the '90s, a Japanese series, laced with Italian dubbing - Yattodetaman - reigned supreme on 21-inch convex TV screens. The plot was not particularly revealing. Two teenagers - Beppe and Tina - the helpers of a famous detective, help Princess Sunday, lost in time, in an attempt to prevent her cousin from capturing the mystical Peacock of the Cosmos. Of course, in each episode, the youngsters reach a point where they can't deal with the enemy on their own, and in order to survive they must summon a giant robot from another dimension - the Star King, who eventually deals with the evil princess and her servants. But for the summoning to succeed, two artifacts are needed - a key and a padlock. We can use exactly the same recipe for success when we want to provide our customers with an excellent app that solves all their problems, or at least the vast majority of them.

Recipe ingredients

‍Ourkey and lock are two teams that in many organizations exist and interact with each other, but often remain separate entities - the UX Team and the Frontend Team. Let's take a moment to look inside each of them and see what elements they should consist of. Each member of the UX team has a specific function, and the scope of their activities and competencies varies. Among them we will find researchers (UX Researcher), designers (UX and UI Designers), people responsible for conducting workshops (UX Participators) or analysts who can build a high-level vision of the product (UX Architects). The Frontend Team remains slightly less diversified. Leaving aside purely technical issues, stemming, for example, from the language in which programmers specialize, we can distinguish two roles: the Web Developer (the person mainly responsible for implementing the look and interaction in the application) and the Business Logic Developer (the programmer in charge of creating the business logic of the application). What's more, these two roles are often combined by a single person, hence the mentioned job names do not come up very often in everyday conversations.

Leo, why?

‍You maywonder, what do we actually need all this UX Team for? After all, our front-end developers are executing projects brilliantly on their own. They may not be the prettiest, but maintaining another team generates costs, and for pretty eyes (read: design), you're unlikely to get anything in today's world.
In practice, the exact opposite is true. According to the CEI report, as many as 86% of consumers surveyed were willing to pay more for a better service or app experience. Nearly 9 in 10 customers would choose competing apps if the solutions they currently use did not meet their expectations in terms of design. What's more, 75% of users judge the quality and reliability of a service solely on the basis of aesthetics and the so-called first look (which lasts only 3.42 milliseconds on average) . What speaks to the usefulness of the UX team is that it can effectively reduce the cost of development through prototyping. This allows us to estimate our projects with much greater accuracy and avoids structural changes in their final stages. This is because all key changes occur right at the prototyping stage. In addition, we avoid the chilling phenomenon of Feature Creep - "feature creep" that expands the scope of the project with each passing day by adding unnecessary elements. Then we no longer rely solely on the inner voice saying: "this might come in handy someday," but instead rely on UX research that clearly answers the question of whether a feature is necessary. In the end, the UX team is able to test how the content of our application will be perceived. Studies show that almost every second user stops using an application or website because of unattractive content . Such testing at the prototyping stage allows us to avoid implementing unnecessary functionality and the need to modify it later.

The UX team can also be a support at later stages of the project. Positive user experience of our applications, contributes to their level of attachment to the brand or product. Using tools such as Customer Journey Map, heatmaps or eye- and mousetracking, the UX team can, so to speak, "step into the shoes" of the user and precisely identify which steps in navigating the application cause the most difficulty (so-called bottlenecks). Data from these areas allows the UX team to optimize the design and thus increase user retention.

In the end, all this work put together contributes to real savings in other areas. Creating a user-friendly and functional application will result in our users themselves praising it to their friends or colleagues. Such a channel of promotion is, of course, one of the most effective and builds the most trust - after all, no one will recommend a product that they themselves are not satisfied with. What's more, this form of promotion is free. The best example of the savings that can come from using the support of a UX team is IBM. This company, after implementing one of the UX team's tools, Design Thinking, saved more than $20 million in its projects in three years. Among other things, it reduced software development and testing time by 33%.

We put the key in the padlock

‍Sincewe already know how our key (UX Team) works, we now need to put it at the right angle into our log (Frontend Team). To do this perfectly, we need to know the intersection points where the two teams can work together. Assuming some simplification, we can fit these points into three groups: tools, frameworks and ideas.
‍
The latter include approaches close to both teams, for example, the idea of atomicity (Atomic Design), i.e. dividing a project (both programming and graphic design) into as small, functional elements as possible and combining them into larger groups (molecules, organisms, templates). For both teams, the idea of working in sprints is also unfamiliar. Of course, Design Sprints and Agile Sprints differ in a few places, but their leitmotif remains the same - iterative progress, development of the project and continuous testing of the developed solutions.
‍
Another latch in the padlock where the tabs on the UX key fit are frameworks. Following the design principles developed in a framework, streamlines the implementation of specific solutions, as the development team can use the same assumptions and ready-made components. Excellent examples of frameworks used by both teams are the systems developed by the giants of the IT world: Material Design from Google or Human Interface developed and maintained by Apple.
‍
The place where the key and the padlock meet the strongest, also causing the most friction, are the tools that the UX team uses to provide the developers with input for their work. Getting the design right and handing it off using Zeplin, Framer X or InVision has become standard. Of course, there are dozens of such tools, and it's only up to us which one we want to use.

Ballistics of the teams

‍Oneof the departments that ballistics deals with is the study of the individual marks that a threaded barrel leaves on a fired bullet. As the key is turned in the breech, similar depressions are left on both parts - things that teams learn from each other.

Despite the direct contact with the customer, developers often approach their tasks very mechanically. They diligently execute the tasks written in the backlog, but in doing so they make no effort to "step into the shoes" of the ordinary users of the application they are currently developing. This is a space where using the tools of the UX team can bring a human element to the developer's work. Getting to know and going through the Customer Journey Map should help the development team understand the meaning of the work they are doing and, by the way, positively influence their motivation.

On the other hand, the conscientiousness and precision of checking daily through Code Review the results of the work of colleagues from the Frontend Team, can increase the quality of the solutions worked out in the UX Team. Accurate comments, pointing out where some imperfection occurs, for example, on the mockup, will allow the UX Team to avoid collecting a whole bag of minor corrections in the next stages of the project.

Both teams can also benefit from knowing the basics of the other's work. The Frontend Team will find it much easier to implement and propose effective and functional solutions if its members have a basic understanding of usability design. The very awareness of the existence of, for example, Nielsen heuristics, positively influences the implementation of projects by the development team. On the other hand, basic knowledge of such technologies as HTML or CSS or JavaScript limitations allows the UX team to design solutions that will be implementable within a finite time and budget.

Is it worth it?

‍Incorporatingthe UX team not only into the front-end team, but into the entire organization, brings tangible benefits. The aforementioned IBM, after incorporating a UX team and using Design Thinking methodology, achieved a 301% return! The time to deliver more products to the market was halved, and the entire design process was reduced by 75%. In 2006, Facebook established the so-called UX Fund and invested $5,000 each in 10 companies dedicated to providing excellent experiences for their users. These companies included Apple, Nike, Netflix and Electronic Arts, among others. Within one year, the return on investment was nearly 40% (compared to an average return of 15% for the same period for the New York Stock Exchange). In the 10 years since the start of the experiment (hooked up to a major crisis in 2008), the entire investment yielded a return of 450%!

In the increasingly accelerating world of IT, no organization can afford to be left behind. As the numbers show, companies that invest in experienced teams can expect a quick return on their costs. However, that's not all. A good UX team is also an investment in attaching our users to a brand or application and building their trust. And who among us doesn't dream of having only satisfied customers ourselves?