GeneXus improves the synergy between designers and developers in order to create a good-looking application in record time.
The main idea resides in defining responsibilities for each role. As obvious as it may seem, Designers know about user experience and interactions while Developers know how to code and make the application functional. They both use different tools, different points of view, different processes, etc. When one role is missing or both roles start mixing responsibilities, early problems during the development cycle may arise and that is what GeneXus aims to simplify.
Currently, GeneXus offers support for importing a design model made with the Sketch design tool and Figma design tool (other tools will be available in the future). There is a guide for designers you must follow and an article of best practices for making the interaction with the developer easier. Remember to be tidy and keep your design simple in order to achieve a good result on the first try.
GeneXus offers a Design Import option tool for initializing the UI of your application. If you reimport a design, it will override changes that you probably had made by hand, so be careful. Remember that the result may not be perfect due to different reasons (aspects not modeled in the design file, platform gaps, etc.) but it should be easy for you to fix those details when you run it the first time. GeneXus only generates the GeneXus objects that are represented in the design files. On the other hand, the data content of the application is initialized by the examples given in the design files, and it is your responsibility to fill that data with real data. GeneXus only imports the UI; the business logic depends on you.
Designers and Developers speak different languages. Both roles should read the articles that GeneXus offers in order to better understand each world. The following table shows you a set of terms that you both (designer and developers) will start to use frequently and where each of them has a unique relationship.
|Symbol / Component
|Artboard / Main-Frame
|Link / Interaction
||Theme Class / Style Class
||Color Palette Item / Color Token
|Group / Frame Layer
Canvas (when there is overlapping)
Control (when a convention is applied: Combo-Box, Check-Box, Radio-Button, etc.)
TextBlock (when Static convention is applied)
Read-Write Variable (when Input convention is applied)
So, for example, if you are a developer and you notice that after importing a design there are some controls that should be together in a table, check with the designer if he/she groups that layers in the design. This process of importing a design by the developer and checking it with the designer to fix it will be part of your development process until you both achieve a good result. It is recommended that you start by designing a single panel, import it, and check the generated object (both at design time and runtime). Next, iterate until you are satisfied with the result before designing a new artboard, and so on until you have a fully functional application.
GeneXus' philosophy is to automate everything that can be automated. In our experience, the process of developing the UI of an application takes the most part of the development cycle. If the UI design is in the hands of an expert (the designer) there are two advantages: 1) The application will have a professional look & feel, and 2) The developer will have a set of panels previously created that may require minimal changes and then they can focus on the business logic.
DesignOps facilities are available as of GeneXus 17.