What a developer needs to know about working with a designer – InformTFB

What a developer needs to know about working with a designer

What a developer needs to know about working with a designer

The year is 2021, and the time has long come when designers and programmers began to work together on the same product. Now you almost never meet a development team that doesn’t have a designer. This was facilitated by the mass migration of the then “computer Operators ” to graphical interfaces. Now operators are an incredible number of different types of managers who manage various business processes in their organizations-starting from the formation of documentation, ending with the management of machines for assembling equipment.

A brief history of graphical interfaces

Interfaces have undergone many changes since the early 70s-this is directly related to the methods of entering information into computers. At first, these were levers and toggle switches (like radio and TV controls), there were joysticks and manipulators, then keyboards and mice appeared, and now new input methods are already appearing in the form of camera motion capture and neural interfaces.

With the advent of keyboards, methods of text input of commands into computers were invented – that is, a person simply wrote in a pre-set format what he needed from the machine and it gave him the result. This continued for quite a long time, affordable computers came to companies, and people who are engaged in paperwork began to be transferred to computers EN masse.

In 1983, the first graphical interface for computer management appeared – it was a windowed interface that offered the user to solve their tasks in a fundamentally different way. Since then, you’ve had to type fewer and fewer text commands and click more and more buttons. It has become easier and faster for the average user to work.

In 2021, text interfaces are still used, but almost all of them are needed for a very narrow circle of users, while all the others use graphical interfaces. This implies the need for companies to hire not only developers, but also user interface designers.

The face of a modern designer

Will this person draw pictures? This is probably the main question that programmers ask when they see an interface designer. The answer is Yes! This person will draw pictures, as designers did hundreds of years before him. But… there is a lot of extra work that differentiates an interface designer from a graphic designer.

We don’t just draw pictures

Yes, we draw pictures – but that’s not all, because when you see the interface, you (first) can use it, interact with it, change it… in addition (second) you clearly understand what the interface is for and how to use it.

The first is UI (User Interface) design, or user interface design, which deals with displaying information to the user, graphic content, adaptability, aesthetics, and visual concept. In this area of interface design, all tasks related to graphics are solved-fonts, colors, sizes, composition, universal components (tables, buttons, panels, menus…), illustrations, icons … and much more that relates to the appearance of the application.

The second is UX (user experience) design, or user experience design, which explains to the user how to complete his task, what he has to do, and shows him step by step, in his usual form, the process of solving his task. At this stage, an analysis of the problem and the ready-made solution is carried out, data structures, business processes, and types of users are isolated, algorithms for solving the user’s problem are built, and a decision is made on how and at what stage to show data to the user.

Can UI exist separately from UX?

If there is only a UI designer in the team , then you will get a design that is aesthetic, neat, and conceptual…. but it is as far removed from reality as the Earth is from Mars. This design will win the heart of your investors, but once you start developing, you will get a result that will break the investor’s heart.

If there is only a UX designer in the team , then you will get a working interface at the output, which will be devoid of everything except functionality. UX designers are very similar in their work results to programmers who mediocre display data to the user – they can not be blamed for this, they have a different field, they should not care about the appearance of the design. The result of an interface that is built only on UX – no Commerce, just solving the user’s problem. An example is Linux graphical shells-like LXQT, or the LibreOffice Suite of office programs-like Yes, they perform user tasks, but if the user has a choice , they will happily switch to MSOffice, or even GoogleDocs.

The conclusions here are obvious : in addition to developers, both the UI and UX designer must work on the interface, otherwise your interface risks becoming a failure.

Who dictates the terms?

This often happens when the designer looks at the interface and sees that (for example) some table fields that are included in the design are missing from the app’s interface. It starts with finding out why the designer drew and the developer didn’t.

Or it happens when a developer has created a field in the application table and asks the designer to add it to the design table. Or it makes the interface to suit its own taste, assuming that it knows best.

The result is an unavoidable development-design conflict that clearly doesn’t lead to anything good. Stress, resentment, reproaches, and all the other symptoms of a team relationship become apparent.

  • And who is right? You may ask…
  • Answer… The person who designed the system.

The architect may generally have a deep view on your conflict, and he has every right to cancel the actions of both the developer and the designer, or he can fully approve the adjustments of both the designer and the developer – while logically integrating them into his system.

In situations of conflict between development and design, you should always contact the person who is authorized to resolve issues of changes in the system.

Questions of competence

Here everything is simple – the designer can’t dictate to the developer how to write code, and the developer can’t dictate to the designer how to do the design. Everyone was hired to do whatever job they were most competent at.

Of course, no one cancels initiatives – but they should be as careful as possible so as not to bring chaos to the team, and it is better when the developer and designer jointly came up with an innovation in the system and proposed it to the designer – then the conflict between the designer and the developer becomes minimized, and everyone goes about their own business.

The interface designer can’t help but understand how the program works

A banal example is that your application is built on SSR, and each request is accompanied by a page reload to render the response. And the designer makes it look as if you can only update part of the content without reloading it. Here big questions arise about how to implement this design. Few people will say that you can use AJAX, but this is not an option, because of the high specificity and labor costs of the solution. This is a mistake of the designer who did not do what the project needed. Here you need to ask questions about the competence of the designer, if he knew that the application was on SSR, or about the competence of the person who introduced the designer to the course of business, before starting his work on the interface. The question of the competence of the developer who made the application on SSR instead of SPA should also take a serious character.

Working as an interface designer with JSON

For example, let’s take a task : you need to make a product map that has many parameters (configuration options, colors, etc.) of the product, photos, price, and quantity of the product in stock. The development Department receives a task, the Manager distributes tasks to specialists, and work begins. You can give the designer a JSON object that contains all the necessary fields – and at the output from the designer, you can expect an interface with the structure and data set you need.

Conclusion

If the article turns out to be interesting, and if possible useful , then I will be happy to write a series of articles on how to make development and design friends.

Anderson
Anderson
Web site editor and tester.

Leave a Reply

Your email address will not be published. Required fields are marked *