Design and development, two siblings separated from birth (Part 2)
Intro
In our previous article, Design & Development, breaking down the paradigms of their collaboration, we have talked about investigative processes that have design and development in common, we have also talked about the efforts and activities they share; we have even delved into the paradigms that exist around digital products and services development. Now is the time to talk about how we can unify these disciplines.
Agile was born in a development environment and for Software development, while Design thinking was born for design to tackle complex problems that required demanding cognitive resources. The reality is that in practice no one completely follows 100% agile execution or something 100% linear, companies and teams seek to adapt to what gives them the best results and this is usually a hodgepodge of both paradigms.
For example, in design, there is a Google’s variation of Design thinking created by Google and called “Design Sprint” which seeks to introduce cycles to this linear process. At the same time, in development, there is an agile methodology called Kanban, which does not make use of sprints (cycles).
From the point of view of the Design team, there is no linear vs agile; they are strategies that we must consider depending on the point of the product or service life cycle that we are at, the complexity of the challenge, the context, and the risks that this entails. Because both paradigms bring different benefits to the table during software creation, we can get the best out of them without necessarily marrying one. By unifying paradigms, we unify teams.
Parallelizing efforts on the fidelity levels of a digital product
However, stills the dependency of development needing an interface that guides them to build the user-machine interactive part of an application.
Let us dig into the anatomy of an application from the point of view of a user:
- User-machine: The part that interacts with the user, which is an interface that is responsible for disposing and obtaining data that the user generates so that they can carry out the task they want.
- Machine-machine: The part that interacts with the “machines”, which is usually in charge of the execution and maintenance of the tasks that the user wishes to carry out by processing the data that the user introduces, selects or generates.
If we take into account the cognitive process, we can define levels of fidelity for each part of the anatomy of an application and the efforts required by the level of fidelity for both teams.
Low Fidelity
Conceptual level, we define the problem and the solution at this point. There isn’t a prototype involved yet, it is mainly a set of hypotheses formulated during the discovery cognitive process. Diagrams are what we see the most at this stage.
Design team
- Understand the motivations, goals, and frustrations of the user, understand the processes involved and the business needs.
- Define the problem they are facing.
- Understand dependencies and associated risks.
- Devise solutions around the user’s problem, define the user’s journey, human-machine interactions, the information architecture, the content structure, and the user flows using low fidelity wireframes.
Development team
- Understand the tasks that the user wants to perform, the data involved, the systems involved and the business needs (functional and non-functional requirements).
- Define the problem and its technical complexity.
- Understand dependencies and associated risks.
- Devise solutions around the problem, define the high-level architecture that reflects how these computational systems are related to each other and what data they require, define the database structure, define data flows and pipelines, and define the technology stack to be used.
Medium Fidelity
It is an already executed minimal but fully functional end-to-end part of the solution, stills not productive. This solution is fed with mocked data very close to what would be used in a productive environment and processes are not 100% defined in detail, being seen more like a series of black boxes that receive inputs and generate outputs.
Design team
- Generate mocks very close the final look and feel.
- Prototype the solution using mock data.
- Make usability tests and iterate the prototype.
Development team
- Prototype the basic skeleton, supportive methods, objects, tasks of the user journey using code, not 100% detailed.
- Prototype the solution using mock data.
- Make an end to end test and iterate the prototype.
High Fidelity
At this point, we seek to finish with the details of the solution, both visually and technically speaking. On the design side, the aim is to have the final look and feel, to have the visual elements placed in their final position and to polish the user-machine interactions. On the development side, the goal is to connect the application with productive databases, services and apply the final look and feel layer. Both parts are polished, the user-machine and machine-machine.
Design team
- Keep polishing the mocks until it reaches the final look and feel.
- Make any number of tests needed in order to have it ready for delivery.
Development team
- Keep finishing any detail until it reaches the final production form.
- Make any number of tests needed in order to have it ready for delivery.
Low fidelity is the one that requires the most effort; by nature, we need to put some extra effort to understand the problems we face. For the medium and high they are very similar efforts since it is about iterating with what has been learned from the tests and finalizing the solution in detail until it reaches the point where it can already be delivered. The only thing different between medium to high fidelity is the level of detail.
Here is a table on which one of our former designers has summarized her experience as a designer and software developer. The table compares the artifacts used at each level of fidelity by the design and development team to understand what kind of deliverables would be expected and their counterpart.
Adjusting the project goals to fidelities
This approach of going on the same ship sailing by levels of fidelity has one pre requisite, that the project lead needs to define success on each level, but that is what makes it also flexible, the ability to define the strategy and deliverables with the team and stakeholders. Also, the project strategy is something that the project lead needs to plan previously and share it with the team, so all members are on the same page.
It is worth mentioning that it is true that the design team should go a few sprints ahead of development since, ultimately, they decide what the user’s journey will be. Even with this dependency between teams, it does not mean that development should wait to have the designs finished to be able to act, since each team has discoveries to make about the problems each must face and they can help each other on these challenges.
This way of contributing works under certain conditions where both the design and development teams are assigned to the project almost simultaneously; in this way, they do not mismatch from the previously defined fidelity levels.
Whatever stage the teams coincide in, the job we have as team members is to help us better understand the decisions made on each side, to be translators within the team, to work as a multidisciplinary team, to create a shared understanding, and remove stones that may frustrate the team’s journey.
Collaboration best practices of a product team
Here is a summary of the key points to keep in mind when working with a product team.
Collaboration
- It is necessary to instill motivation and confidence in the members who are part of the project to obtain successful processes.
- Suppose a member of the team is in a position to be the translator between multiple disciplines. In that case, they should contribute to the transfer, extrapolation, and migration of the most relevant information between disciplines.
- Team members should have early visibility of the progress of each discipline.
- The team members will show interest in sharing the most important discoveries of each discipline.
- The team members must be respectful with the work and progress of the rest of the members.
- The team must work in a coordinated and joint way, using the selected methodology, as a useful and essential practice for the correct organization and development of work.
- Everyone in the team should be able to participate in well defined tasks that are not part of their discipline if needed or requested by them.
- Regardless of the discipline from which they come from, team members must seek the common good and support each other as much as possible.
Leadership
- The team leader will seek to encourage the creation of shared knowledge among team members.
- The team leader will seek to tie the time of assignment to the project to the disciplines necessary for a product of excellent quality.
Closing
The fact that teams do not work in silos will depend on the existence of people within the team who promote this vision of teamwork despite being two different disciplines and the creativity that we put at a strategic level so that both disciplines end up joining forces for a common goal.
The above presented is a point of view (or a stand), a way of working and mentality; it is not a magic recipe written in stone. How our teams interact and the work dynamics that they will have depends ultimately on the conditions of the projects and the culture of the company.
About the author
I’m a nerdy person. I like solving problems. It triggers my curiosity. 🤓
In my past lives I’ve been a Software Engineer, UX designer, Project management, and Freelancer.🏃♀
I like ecological stuff, I’m trying to change my lifestyle and consumption habits towards something more circular rather than linear, thus I have created an ecological soap brand 🌿🧼
