Getting started with the design and development process

Team collaboration is very important, so a good (the best!) approach is when the Designer, Developer, and QA (and any other team members) can work together from the very start. But will they all have something to do? Of course!

Close teamwork and focus will allow you to achieve a very good quality of software/application building. The product will be refined, pleasant, attractive, complete, and free of errors.

When a whole team is mobilized the team members will complement each other from the very start, which will allow for even better results than when you add people to the project mid-way through. Oftentimes, problems will be resolved before they even start, and you will save valuable problem-solving time and be able to put it into actual web development, UX design (not to mention having more time for the whole design process), architecture testing, and much more.

How do start-to-finish teams work together? How do they fit together? Read all about it below.

The whole team matters, not just developers and designers

When the whole team works together, they all know the project parameters and the client’s expectations. The team consists of specialists who perform the work at various stages, but support each other throughout the entire project.

The full team consists of a project manager, designer, developers, DevOps, and QA – of course, it may happen that the teams do not have all the groups, but a “set” like this allows for efficient development of high-quality software.

They all connect to each other and sometimes to the client through a project management platform of their choice – like Jira or Asana.

This article is devoted to the  QA – DEV – DESIGNER collaboration in particular.

The designer is responsible for the preparation of the app design (I am writing the app in a simplified way, but you know what I mean :)) in accordance with the design process, i.e. previously conducted research, analysis of the collected material, meetings with the client and discussing all details such as creating a persona, customer journey, etc. Basically, making sure that the design team and the client are on the same page.

Then, the designer actively participates in the whole rest of the process and introduces all necessary changes on an ongoing basis, providing comprehensive information on any topics or inquiries from the development/testing side so that everything is as clear and understandable as possible for each team member.

Designers and developers

Developers are responsible for programming matters, and depending on their skills, they deal with the front-end (what the client sees) or the backend part (what is happening underneath).

The front-end developers are tasked with implementing the user interface in accordance with the client’s expectations (this interface has to be designed by a professional designer), connecting the application with the server, external websites, and bringing the application to life with interesting animations.

Accuracy and consistency when coding a design are extremely important features for a frontend user.

The designers from TSH are people who are experts in their craft and they do amazing work. The developers have a challenging task – they must reflect what the designer has created in the best possible way.

The project team not only consists of a developer who implements the frontend, but also developers responsible for the backend, i.e. everything that happens inside (of course, they can be full stacks who sweep the front and backend: D).

Working with them is also very important. A correctly implemented application is the interplay between the front-end and back-end parts. In this case, our backend developer can indicate application areas, e.g. validations that should be handled by the front, and thus the designer should prepare views for this and take it into account in his projects.

The QA role

QA is responsible for testing the software and checking whether it complies with the customer’s requirements. They report errors, supervise the testing process and inform both the team and the client about the state of the application after testing.

However, before starting testing, they analyze the requirements and check whether the prepared designs have been made in accordance with the mock-ups and arrangements. At this point, they are in constant contact with designers, report bugs, and look at things from the user’s point of view. Their reports contain comments and improvements, and when everything was done very well… they say:

“Well done, designer!”

It is not just dry feedback (hopefully it’s never dry), but more about conversations and looking for solutions together, throughout the whole design process. Getting holistic feedback is what makes these development teams so effective.

The QA often comes back to the designer during tests, showing how developers implemented views in the application. This already shows how the three roles work together. The QA asks questions, looks for common solutions, compromises, and generally gets on well!

Thanks to teamwork, the entire design process develops very quickly, we find bugs that are instantly communicated to programmers who have already had the opportunity to see where the bug occurs.

At TSH, we like to incorporate QA more. Thanks to various specializations such as business analysis, performance, or security tests, and finally user testing, they are able to identify deficiencies in documentation, requirements, define stakeholders, provide guidance on the performance and security of the application, and of course, we consult all of this with our team. This is what distinguishes us from others – we love the cross-functional team. 🥰

What are the benefits for a client who uses a cross-functional team?

• High-quality software
• Quickly catch errors and correct them
• The team knows each other and knows what to expect from each other and the communication is better
• Confidence that the product (designer) designed in accordance with the previously collected data will be properly implemented (dev) and tested for compliance with the established business and design assumptions
• A “triple” point of view on virtually every aspect of the process because often densely experienced QA can pick up or propose some elements in terms of design and development. The same is true for a designer and developer.
• What is above, i.e. communication – the smooth flow of information allows you to minimize the risk of downtimes in the design process, such as that suddenly it turns out that the designed section is too complex, so its implementation will take more time than it should or the case where the implementation “on average” coincides with the previously approved design.

Can we imagine working in a partial team?

I admit that years ago I thought that the “one-man army” approach was the only right approach to development, but as with everything, over time this approach had to be verified quite drastically.

Especially when a platform enters the scene and it’s a bit more advanced than a single-screen currency converter. Personally, I am not able to imagine a “waterfall” type process where I first spend 4 months on a design that, after the “developer” inspection, is gutted for various reasons like tech limitations,  long implementation time, etc.

Or that when testing the app, a million errors pop up that could have been avoided if the process was monitored on an ongoing basis by devs and supervised by the QA department.

What could go wrong

Is working with a dream team (Design, QA, Dev) a guarantee of success? After reading the above information, it may seem so, but the client needs to be aware that this isn’t always the case.

So what if we decide to put Ronaldo, Lewandowski, and Messi all on one team, if they won’t be able to work together? Exactly. The same goes for project teams.

Inappropriate matching of a team whose members do not understand each other is the first step to failure! This could be caused by different backgrounds, whether professional or personal, lack of excellent communication, and having an altogether different perspective.

As I write this section of the article, a situation comes to mind – from long before I came to TSH. Let’s just say that there were many misunderstandings in one project.

What did go wrong

Long story short, developers took offense at QA when too many tasks landed in the “to be improved” column, which resulted in a rather unpleasant atmosphere and the fact that QA had to think twice before communicating that the developers’ work was done wrong.

Another thing that I remember is that we didn’t have a permanently assigned designer. Only when the given views were implemented, a designer was hired again to create the UI for the next parts of the application.

At first, you might think that this is a good way for the client to have some money left in his pocket, but the reality was that such a designer did not know our application, did not understand the client’s needs and requirements, and the designs he created differed from the style. that has been used so far.

Hiring a full set of professionals from the very beginning of the project is a kind of investment. Thanks to this, the client will avoid soft project problems like the ones I just mentioned.

By employing a full spectrum of specialists from TSH, the client can count on a complete, interdependent team that will collectively strive for success.

Q&A: Real-life answers

Here are some interesting arguments that the stars of the development process themselves had to share.

Question for Alek (Product Design):

What’s valuable about working with a developer?

When a designer and a developer work together (preferably next to each other) that’s when you basically get the essence and the key to success when it comes to proper design and implementation.

The feedback works both ways, because on the one hand, the developer is able to react on an ongoing basis when the designer has a fantasy and designs something that may be problematic in implementation, and sprints are made to be altered, so you can correct the work “live”.

This spares you the argument: “But I designed it differently”, and the designer tracks and compares the implementation with the project, thanks to which he can quickly catch all sorts of inaccuracies such as incorrect spacings or incorrectly displayed microinteractions, e.g. with the hover effect.

If, in addition, both sides present the “pixel perfect” approach, then we are guaranteed to deliver a digital product in “prima sort” quality.

Why do you like working with QA?

When working with QA, I appreciate the fact that they supervise the whole development process –  a designer and a developer are only human and mistakes happen all the time.

With their skilled eyes, a QA makes sure that those mistakes are fixed as early in the development process as possible, and a good QA will also prioritize the problems so that the dev and designer know the priorities and act accordingly in a situation that might be chaotic otherwise. In other words, the QA always sees the “big picture”.

Apart from that, I would like to add that I appreciate the fact of keeping tasks in Jira – I often write tasks more or less sloppily, and QA will either draw my attention to it or it will fix it themselves.

Besides – due to constant tests, QAs actually know the application inside out, so they often advise the designer how something works or where to find some deeper hidden feature or a solution (it helped me a lot when I started working at Forsah).

They can also propose an actual improvement that I would not have thought of myself. Some time ago,  Mateusz Przekwas noticed a small irritating element in the navigation and he proposed a solution. I designed it, and thanks to that we changed the world for the better – or at least our job became much easier :).

Generally, in the absence of QA in the team, the whole process would be much slower, because designers and devs would have to check if everything was done correctly. This would cause them to be kicked out of their activities, lack of concentration, and thus even more errors that they would have to report themselves, which would make the entire development process simply impossible to complete to a satisfactory degree.

Question for Kacper (Front-End Developer):

What’s valuable about working with a designer?

What I appreciate most about collaborating with designers is the fact that we strive to give the project the right shape together. The designer uses his skills to create a high-quality user interface and the programmer’s task is to translate this design into code and give it interactivity.

Working with designers from TSH, I can be sure that the application reflects the appropriate character with its appearance, meets the requirements of accessibility, and is user-friendly. When this is combined with good-quality code, intuitive animations and excellent interactivity make the final product top shelf.

Why do you like working with QA?

In my opinion, a good QA is the basis of a successful project. The QA and the dev who understand each other are able to create a team that goes ahead without looking at the ticks in Jira, which every now and then successfully end up in the “DONE” column.

Personally, what helps me immensely in my work is that the QAs know the business logic of the application inside out (they are able to bend the product owner more than once). Thanks to this, I feel safe during my work – I know that when I get lost in the requirements, I will not be left alone in the middle of nowhere – I can count on the knowledge of a software tester.

QAs from TSH have skills that allow them to test functionalities on the server-side (e.g. rest API or AWS lambda), thanks to which they supplement the frontend with backend knowledge.

The courage of our QAs is something that cannot be overlooked. As Alek mentioned earlier, sprints are not made of rubber. Unfortunately, sometimes it happens that, despite the upcoming release, the state of the staging environment differs significantly from what was expected.

Of course, when that happens, everyone works under a lot of pressure. That’s when the QA comes into play, and sometimes they don’t even put the deadline as a first and foremost priority, but say “I will not let it go into production in this state”.

In my opinion, this is a sign of great professional maturity, because after all, they go head to head with Product Owners and Project Managers, but they do it for everyone’s good.

QAs at TSH are characterized by an extraordinary work discipline, as Alek already mentioned when describing the organization in Jira that they can maintain. I subscribe to it 100% and I will add – the errors they report are complete from A to Z, and you can be sure that each card in Jira will contain:

• a precise description
• specifications on which device and browser the error occurs
• instructions on how to reproduce the bug
• error screenshots
• data of a specific user (so that dev can log in and work immediately)

Such structured tasks in Jira mean that you do not have to think twice. You just sit down and act because you have everything served on a plate.

Questions for Ania (QA):

What’s valuable about working with a designer?

Working with a designer allows you to feel safe. With the design, the designer shows how the application should work, which means that the other people in the team have visualization and knowledge about how the application should work. 

This is very important to the QA! A good designer is open to discussions, explanations, and is willing to make changes when they introduce the starting stage design – this makes the final product so much better!

I like the format of the beginning stage designs, which can be clicked and tested – this makes my work easier :). If that wasn’t the case and the views of the application were “bare” I’d have to guess how something should behave.

What’s valuable about working with a developer?

Working with a developer is like going back to school for me. The dev is a teacher, and I can learn new things from them! They show me how to use development tools in my software quality control work, and what to pay attention to when testing frontend and backend applications.

At the same time, they are open to learning from me about QA needs, and the improvement of the development process. In our work together, I really like joint testing, which means that the developer “sees” their work and how the application works, is able to detect errors themselves and is my support in case of difficult tasks.

Honestly, their best advantage is that they always speak straight and look for the best solution. They also come for support when, during task implementation, they want to understand how a given part of the application or functionality works, and they are not afraid to ask.

Developers are not easy to grasp :P. Everyone is different and people on any team need to get to know each other as they work. The application isn’t possible without devs, so getting to know them and keeping up a great atmosphere is a priority!

Three heads are better than one!

A well-coordinated QA / dev/designer team is an unstoppable force against often densely unforeseen client feedback. The argument supported by three people on the development side has much more power, especially if it is previously discussed by the team so that it is presented to the client from all sides.

It’s true the other way around – feedback that is not fully thought out on the part of the client (and it happens very often) can be relatively easily and tactfully “refuted”, provided that the development team prepares one overlapping version to be presented at the meeting.

Therefore, it is in the interest of each team member to be in full agreement. Besides – working with a team that is not at odds with each other looks great from the clients’ perspective, and the entire process is not hindered and time wasted by opposing views on the project’s technical aspects.

Tools – “maybe you need a tool where everyone can exchange information?”

Miro or FIGJAM or any similar whiteboard (we tend to lean towards FIGJAM) would be perfect for collaboration (not only the designers but for other team members) because everyone would have an insight into the development process, could leave their feedback in the form of any sticky note, comment, leave an emoji, etc.

Thanks to tools like this, everyone would be up to date with the project, which would increase the quality of team communication. Without an efficient flow of information between team members, the entire process may be disrupted, cause delays, or even stop it altogether.

The big takeaway of working together

As we can see, devs, QAs, and project designers love working together – it’s a good process all around. They get more feedback, are more open to changes when they actually need to be made (no one likes working on something for a week and only then being told that they were missing a crucial aspect or that it’s impossible to implement).

The key here is an as-needed, on-time collaboration with team members that are fully committed to the project from start to finish. They’re happy, the client is happy (and better informed), and the end product always looks and performs better than when produced by a fractionalized or randomly arranged temporary team.

Even if breaking up this team seems tempting when it comes to budgeting, in the long run, the budget speaks for keeping them together from start to finish.