Design processes in the ISPsystem. How to introduce ideology, build a department and stay alive

    The story of a redesign that changed the approach to development in the ISPsystem.

    image

    I came to ISPsystem in April 2016. At that time, the situation with product design was as follows: product decisions were made by management and programmers, there were no designers or designers. The market situation required products with “other interfaces”, so management decided to redesign the client part of BILLmanager . It was supposed to be a trial balloon, the first attempt to do something with a new design.

    I was the only UX-designer in the company: I studied an existing product, was engaged in user research, got acquainted with the reviews of partners and their marketers. These are common product design practices, taking into account the specifics of a complex product. I was greatly helped by the product manager, since he knew the product best.

    Every week I showed the result in the form of prototypes, schemes, etc., to the management of the company. This is similar to how client designers work with customers, with all the advantages and disadvantages: you can deny yourself responsibility for the decisions, the main thing is to “sell” them to the management. But since I already had experience in a grocery company and the management trusted me in these matters, we quickly came to work together on solutions that I modified and turned into a prototype.

    Developers meet with prototype


    By August 2016, the prototypes of the BILLmanager client part were ready in their conceptual form. The functionality of the old version of the product is completely transferred to the new interface, with some modifications. The prototypes were quite developed from a visual point of view, but I wanted more, so we ordered a visual design from a third-party company. However, we quickly realized that this attempt was unsuccessful, constant iterative work was required on the visual component, and we needed a visual designer in the staff. Within a couple of months, we developed our own visual language. In fact, at that moment we had several parts of the future design system: a visual language, elements and templates.

    In parallel, approximately from August 2016, developers began to implement a new interface. The guys considered the prototype as an alternative to the technical task. As happens in such moments, questions began to appear in large quantities that boil down to one thing: we do what programmers quickly and simply implement or what was invented and designed by the designer? To quickly address these issues and simplify communication, we have created a team of designers and front-tenders.

    UX-department as a team of designers and front-tenders


    By mid-autumn 2016, the company formed the UX-department under my leadership, which consisted of UX-designers, visual-designer, front-end vendors and testers. Our immediate task was to launch an ISPsystem personal account with a new interface (we use BILLmanager) by the end of March 2017 and we had two groups of problems. The developers didn’t predict the timing of their work, and we didn’t quite understand how to build the interaction of developers and designers.

    What we give to developers


    When you use Sketch and Zeplin, the interaction between designers and developers is very simple. But we had 150+ pages in an interactive prototype, which we learned to use as an alternative to TK for programmers and a specification for testers. We did not want to draw all 150+ pages with different states in Sketch and we came to the conclusion that we would do this only for unique pages. Also, all the elements should have appeared in Zeplin: buttons, form fields, etc. After some time, we learned the name of such an approach - this is a design system based on atomic design . It is still in development, but it is already used by both designers and developers. Extreme in the company for the design system - visual-designer.

    As a result, we deliver two types of artifacts to developers:
    • mockups of what will ever become a design system in Zeplin (or rather already in Figma),
    • product prototypes, an alternative to HTML in the form of HTML, generated from Axure.

    In this case, the UX-designer is always ready to tell developers and testers what and how it should work and look.

    Scrum with designers


    In February 2017, we decided to improve the accuracy of forecasting the timing and tried to implement Scrum. The complexity of our Scrum is that the team is very different in terms of competence and culture of the participants. Designers are not like programmers: we plan our tasks differently, we treat differently what is considered a good result.

    Here is how we built the process:
    • designers work on the sprint forward;
    • there is a prototyped backlog, in which you can see what the whole product should be;
    • by the time the sprint is planned, the designers provide prototypes and mockups of the part of the product that is planned to be done in the sprint. These prototypes are detailed and described by the UX designer to such an extent that developers can deliver and decompose their tasks;
    • at the time of planning, the UX-designer actively advises developers and testers about what should work and how;
    • at the time of planning, the product manager must tell the UX designer what part of the product is planned to do in the next sprint so that the UX designer can plan his work.

    The developers quickly realized the value of the UX-designer, which can be quickly accessed when it is not clear what should work and how. Conflicts still happen, but Scrum practices, teamwork and common goals help to overcome them.

    What does the tester have to do with it?


    The role of the tester in the processes was very important. This is the person who knows the functionality of the product best of all. The tester was the first person to view prototypes of a UX designer and quickly give feedback on how to match prototypes and functionality. Approved prototypes provide the tester with a knowledge base on how the product should work. Both sides were interested in close cooperation.

    As a result, the team on time released the new interface of the personal account ISPsystem. We have learned to work on Scrum, to predict the work of the UX-department as a team of front-end designers and designers. And by the summer of 2017 faced a new problem.

    BILLmanager is a flexible product. And this is a problem for the designer.


    When a designer draws a poster, imposes a book or makes a cover for a magazine, he works with static information. He has specific text, certain images and other content.

    When the designer designs the interface of the application or site, the information is not static. There is information about what the data may be, but the data itself is not. Let's say there is a blog, each blog entry has a title, abstract, post release date, image, etc. There is no specific title, but there is an understanding that the title will always be, and the date will always have a date format. The task has become complicated, we have data types, but there is no data itself: you need to think about what content can be, what restrictions can and should be imposed on it. Most likely, the artistic value will be less than that of the poster, but the designer wants to get a result that will be beautiful, comfortable and understandable.

    In the case of BILLmanager, the administrator of the hosting provider can change the settings so that, for example, for a dedicated server order form, the set of fields can be different. In one case, we will definitely have a processor, disk and memory, and in the other - no (or, but, for example, one field), and it is impossible to predict. In this case, the designer does not even have a fixed data set, we don’t know not only specific data, we don’t know the types of this data ... and this complicates the work.

    When we started to make a boxed version, testers began checking all the settings possible in BILLmanager. Then it became clear that, on the one hand, the prototypes are not complete enough to cover the possibilities of BILLmanager flexible settings. On the other hand, the architecture of the old product was not flexible enough to implement a large number of design ideas. From autumn 2017 to spring 2018, we reworked prototypes and looked for compromises in order to solve this problem. And with some restrictions on the settings, they released the boxed version of the client part of BILLmanager 6 Beta in May 2018.

    UX-department of designers


    While the UX-department solved the problems with the flexibility of BILLmanager, management decided to rework the interfaces of other products of the company and introduce Scrum and design processes to the rest of the teams. We started with VMmanager 6, assembled a full-fledged product team from participants of different competencies, self-sufficient to create a product: backenders, front-end vendors, testers, UX-designer, product and project managers. It became clear that all other products would be gradually developed by the same teams, and we began a gradual transition to the matrix structure of product development management.

    In this context, the UX department had to stop being one of the product teams. After the release of the client part of BILLmanager 6 Beta, most of the UX-department has become part of the BILLmanager team and is now engaged in solving architectural problems and the mobile version of the client part. At the same time, we began work on the formation of a UX-department that could work with all products simultaneously.

    UX Designer - Each Product Team. Design Competence Center


    ISPsystem has four complex products. We made sure that every team has its own UX designer. This is the person who is responsible for the design of their product. His responsibilities include the preparation of prototypes for sprint planning and control that everything necessary for developers is in the pixelperfect version. He is the conductor of the company's design policy to his team. One of its tasks is to ensure that as a result of the development we get a product that matches the design.

    We also have several people who form the center of design competencies of the company. It includes a visual designer. This center forms the design policy of the company's products, is working on a design system. He also trains UX designers in teams, solves the most complex design problems, trains developers, product and project managers how to work with UX designers, introduces design processes into Scrum teams.

    Also popular now: