What are the most important factors for a developer needs to know about dealing with a designer? It’s 2022, and it’s long past time for designers and programmers to work together on the same product. Now it’s almost impossible to meet a development team that doesn’t have a designer. In any project today, there are an incredible number of varieties of managers who manage various business processes in their organizations, from generating documentation to managing machine tools to assembling machinery.
Dealing with a designer: The face of the modern designer
Will this person draw pictures? This is probably the main question programmers ask when they see an interface designer. The answer is yes! This person will draw pictures, as designers have done for hundreds of years before him. But… there’s a lot of extra work that distinguishes 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 (one) can use it, interact with it, change it… besides that you (both) 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 the display of information to the user, graphical content, adaptability, aesthetics, and visual concept. This area of interface design deals with all tasks on the subject of graphics – fonts, colors, sizes, composition, universal components (tables, buttons, panels, menus….), illustrations, icons. These specialists use various services like Retoucher Online. Finally, they do other things that relate to the appearance of the application.
Second is UX (user experience) design, which deals with explaining to the user how to perform his task, what he has to do, and showing him step by step, in a familiar way, the process of solving his problem. At this stage, the task is analyzed and the final solution is created, the data structures, business processes, and types of users are distinguished, the algorithms of solving the user problem are created, and the decision on how and at what stage to show the data to the user is made.
Can UI exist separately from UX?
If you have only a UI designer in your team you’ll get a design that is aesthetically pleasing, neat, conceptual… but is as far from reality as the Earth is from Mars. This design will win the heart of your investors, but once you start developing, you’ll get a result that will break an investor’s heart.
If the team only has a UX designer – then you will get a working interface, which will be devoid of anything but functionality. UX designers are very similar to the results of their work on programmers who mediocre data displayed to the user – you can not blame them for this, they have another area, they do not have to care about the appearance of design. The result of the interface, which is built only on the UX – no commerce, only solves the problem of the user. An example would be graphical shells for Linux – like LXQT, or a set of office applications LibreOffice – like yes, they perform the task of the user, but if the user has a choice – he would be happy to move to MSOfficе, or even GoogleDocs.
Conclusions here are obvious – the UI and UX designer must work on the interface besides the developers, otherwise, your interface risks becoming a failure.
Who dictates the terms?
Often happens when the designer looks at the interface and sees that (for example) some of the table fields, which are in the design are absent in the interface application. It begins to find out why the designer drew and the developer didn’t.
Or it happens when the developer has a field in the application table and asks the designer to add it to the design table. Or he makes an interface to his own taste, assuming he knows best.
The result is the inevitable conflict of development and design, which obviously leads to nothing good. Stress, resentment, recriminations, and all the other symptoms of team relationships become apparent.
Dealing with a designer: So who’s right?
The answer is… Who designed the system.
The architect may not give a damn about your conflict at all and has every right to override the actions of both the developer and the designer, or he may fully approve the adjustments of both the designer and the developer – while logically building them into his system.
In situations of conflict between development and design, it is always worth going to the person who is authorized to deal with system changes. And definitely, the authorized person must consider the standards when dealing with a designer.
Belayet Hossain is a Senior Tech Expert and Certified AI Marketing Strategist. Holding an MSc in CSE (Russia) and over a decade of experience since 2011, he combines traditional systems engineering with modern AI insights. Specializing in Vibe Coding and Intelligent Marketing, Belayet provides forward-thinking analysis on software, digital trends, and SEO, helping readers navigate the rapidly evolving digital landscape. Connect with Belayet Hossain on Facebook, Twitter, Linkedin or read my complete biography.