A look behind the scenes: How MADDOX is made

For the user MADDOX is what they see on the screen. We pos­ted already in the past from the invis­ible tech­no­logy-stack on the serv­er in the back­ground (MADDOX sys­tem archi­tec­ture, NATS as mes­sage broker). There­fore, this post out­lines the devel­op­ment of what MADDOX defines: func­tion­al­it­ies, pro­cesses, inter­ac­tions such as fields and but­tons as well as visuals.
The devel­op­ment of these core fea­tures is called UX-Design (UX stand for User eXperience).
At the begin­ning the tar­get defin­i­tion is only an idea for a prac­tic­al new func­tion­al­ity. For example, should machines stops cap­tured as an event, edited, and logged. It should be also pos­sible to delete comments.
At that stage you usu­ally face the “makes sense, we can do it; how dif­fi­cult can that be” – moment. How­ever, do not judge a book by its cover.

There­fore, the actu­al chal­lenges reveal when the idea is replayed by the user in all details and with all con­di­tions. That is the moment when cer­tain inform­a­tion or aspects sud­denly do not fit into the tab­let screen any­more. Cer­tain cases can have undefined con­di­tions, or one wrong click can cause irre­vers­ible con­sequences. Espe­cially the last case can hap­pen fast on touch devices. There­fore, we use fol­low­ing intern­al design guideline: which we call the lovely fat fin­ger syndrome.

Based on com­plex func­tion­al­it­ies we after­wards devel­op Mock-ups with Adobe XD, that can be used as click-dummy online. That helped in provid­ing a test­able Mock-Up to the cus­tom­er beside the already imple­men­ted SAP-Inter­face and to col­lect fur­ther feed­back for the development.