OutSystems: Crucial tips for working with a Design team for the first time!
In the past few months, my last project gave me a super interesting challenge. I must say it was a new one for me.
As we all know, in this modern world, the most successful web applications are those that respond quickly and efficiently to user and business needs and are easy to use. This means that the new breed of web applications has another key focus: Users and how they feel when using their brand new tools.
OutSystems has provided its developers with a brand new set of templates, patterns and reusable blocks and functionalities to make things look good, but sometimes that is not enough. This is where the design team comes in. They are the ones who will help you to create that good look and feel on your application (Yes, they’ll do that, they are trained for that), but they’ll also bring a variety of insight, processes and methodologies that will take your application to the next level.
WORKING TOGETHER
Working with a Design team changes the dynamics of your OutSystems development team. They have their own dynamics, processes and methodologies that we, as a team, have to adapt to and embrace while integrating this new element in the development of your product.
Research, Brainstorming, Prototyping/Design Concept and Design refinement are processes and methods that allows the whole team to better realize and comprehend both systems requirements and users’ struggles or needs that need to be addressed. All this work allows the developers to be more prepared even before they put their hands to work.
However, the worst that can happen within this process is not having everyone on the same page. And this can happen if one or both development and design teams become frustrated with each other, which can easily happen. So how can we prevent this from happening?
· Smooth and transparent communication.
· Present to the Design team the pre-built patterns blocks, animations, and other elements that the Development team could build and customize fast. These components could then be used and customized by the Design team to make the application more appealing and user-friendly.
· It is always important to do some research and investigation before committing to an estimate of time and effort.
· Make small samples and prototypes of more complex components before applying them to the application.
· When things get more complex than you anticipate, just pause, take a breath, re-analyze. If you must, go back to the drawing board.
· Try to be consistent through the application and through time. As time goes by, the temptation to just copy-paste and adapt screens and components to a certain user story grows, and the possibility of bringing back old and discontinued features on both designs and developments grows real.
· One element of the Development team must attend the design concept/refinement meeting and have an active voice, for the design team to have inputs from the Development team as well.
· Share your struggles.
· Don’t destroy the design ideas even if they look too complex to implement. Yes, it can happen in one or other occasion, but if it happens frequently, it can destroy the designers trust in the development team.
· Be flexible, be creative but also learn when to say NO. Just never forget to justify it.
· While the Design team incorporates user feedback, there are functionalities that have to be re-done or polished, so it is important to also embrace those changes and re-work, and handle them with grace.
· Usually we, as developers, tend to focus on functionality over design. But just like designers do, we also have to pay extra attention to detail.
· Sprint retrospectives are a powerful tool to align the team, especially when struggles, problems, difficulties, bumps in the road are presented in a constructive way.
HOW THIS TRANSLATES TO OUR CODE
It can get messy really quickly if you don’t take care. The pre-built blocks animations and elements presented do not really fit all requirements, or aren’t customizable in the most fashionable way. Before you realized, you are customizing everything, spreading styles, JavaScript blocks everywhere. So what to do?
· Create your style guides. Refactor most of the spread classes through blocks, pages or elements into our theme block.
· Build your own layouts, patterns and other reusable elements when needed.
· Before customizing a system component ask yourself these 2 questions: Do you really need all functionalities from the standard component? Or do you need most of them? Then customize it.
- If you don’t need the functionalities attached to the standard component, just the looks of it, then make your own component.
· Be diligent. Refactor that little piece of code that you know that is not perfect, but works. Don’t let it stay. Before you realize, it will get too big to refactor. So starting to make things work is fine, but don’t forget to invest some time in making it work properly.
· Include the service studio specific properties “-servicestudio-xxxx” in your classes to make the code readable in the service studio as well.
· Be careful and start designing your weblocks in a way that they are readable on the pages and other blocks where they were used.
· Learn a lot from your mistakes. At the end lot could have been done better, but this is the brilliance of it. You can always learn.
IN THE END
The creation of this collaborative work environment, where smooth and transparent communication and where knowledge, feedback, success, struggles and complaints are shared within the team without fear and in a constructive way, allows the team to build a complete set of competences that make the team work its way into a more efficient process. That results in a better technical and visual solution to meet both the goals set by the business unit and solving problems faced by users.
