Design & Development, breaking down the paradigms of their collaboration (Part 1)

Artwork by Jose Pablo Ledesma — Visual Designer

This essay embodies my experience of understanding design and development teams as one during the creation of a digital product by exploring and defining their activities and investigative processes.

The iterative processes: How to tackle problems in design and software development

As someone in an IT environment, you might encounter some situations where you need to find the proper approach to solve a problem or when developing a solution. This could be with some help of a particular framework, process, or even a recipe in order to solve them. No matter if you are a designer or an engineer, you probably have encountered this situation before, now or later.

From my own experience, I encountered these situations, and after a deep dive on some of the most popular ones, I came to the conclusion that some of them have similarities and follow the same pattern. As a former engineer and (almost) new UX designer, I will enlist how I find some similarities when developing a solution, and how these methods could be helpful no matter the side of the coin you are on.

Design thinking in software engineering

Development guides fundamentally their thinking following logic. Ironically, development uses a similar cognitive process because it makes sense first to discover the problem and then ideate solutions. Design thinking[1] serves as a framework for the generation of objective knowledge and this framework is not particular to the design discipline.

The investigative processes of both design and development have more in common than is believed, if not that they are identical, with the exception that the object of study differs. Here is a list of similarities between investigative processes:

• Both have stages of understanding their field of study.
• Both have stages of defining the challenge they are facing.
• Both have risks and complexities to identify in their design processes.
• Both have stages of ideation of the solution.
• Both have solution definition stages.
• Both have to define high-level structures.
• Both have to go from the conceptual to the concrete.
• Both have to test that they are on the right track and that their solutions work.
• Both iterate infinitely as far as the project allows.
• Both generate deliverables.
• They both need to think about how to deliver this product to the customer.
• Both design.

The question is, if they are so similar, why treat them separately during the creation of a digital product? Some will argue that, given the dependence of the development team for the visual part, they must wait to be able to begin the execution of the application development and because of this dependence they are separate teams; We differ, and we have two reasons why:

• The agile[3] and design thinking[1] paradigms allow us to parallelize efforts while iterating for improvement.
• The anatomy of an application gives us the chance to work by parts at the same time.

Design and engineering efforts

Having known the investigative processes that all science goes through, we can begin to understand the conceptual processes of each discipline. The efforts that both the design and development team must make to reach an application-level are:

Some investigative processes used at design

• Exploratory: Understand the motivations, goals, and frustrations of the user, understand the processes involved and the needs of the business.
• Descriptive: Define the problem the user is facing and their current workflows.
• Correlational: Define design hypotheses that can be problem or solution oriented and uncover their dependencies or associated risks. e.g: A hypothesis that says that children may be a potential market for a product but parents are the actual clients.
• Explanatory: Devise solutions around the user’s problem, define the user’s path, human-machine interactions, and define the content architecture that the user requires to perform their tasks.
• Applicative: Prototype the solution (Mocks), test, and iterate.
• Predictive: Predict how the user will interact with the productive version of the product and make a product plan based on this prediction.

Some investigative processes used at development

• Exploratory: Understand the tasks that the user wants to perform, the data involved, the systems involved and the business needs (functional and non-functional requirements).
• Descriptive: Define the problem and its complexity.
• Correlational: Understand dependencies and associated risks. e.g: A legacy portal that has multiple dependencies on deprecated third party libraries.
• Explanatory: Devise solutions around the problem, define the high-level architecture that reflects how these computer systems are related to each other and what data they require, define the database structure that will serve the user tasks, and define the stack of technology to be used.
• Applicative: Prototype the solution (programming), test, and iterate.

As can be seen, the design team seeks to understand in-depth the motivations, needs and pains of the user. At the same time, development focuses on how to meet functional and non-functional requirements through the use or creation of technology. Even though the object of study changes, both disciplines solve human problems and work closely with the business to make sure the solution is adapted to the user and not in the opposite direction.

The scientific method

In order to understand the efforts that each team must make when designing and developing digital products, it is necessary to compare the scientific methods[2] (Bunge M, 1996) most commonly used for the construction and validation of knowledge with ours. When talking about the construction and validation of knowledge, we refer to the scientific process found in the field of investigation that helps us define a problem and find an applicative solution to it. The stages we need to walk trough in order to generate and validate knowledge are (Felipe Supo, 2014):

• Exploratory: Used to create a new theory, establish theoretical knowledge.
• Descriptive: Describe an object under study. It is not exploratory.
• Correlational: Establish relationships between two or more variables.
• Explanatory: Determine the effect that a variable “A” can have on a variable “B”.
• Applicative: Apply the theoretical knowledge obtained from the previous levels and generate technology.
• Predictive: Predict the frequency of occurrence of an event. You should be able to elaborate a plan at this point.

These processes allow us to generate hypotheses and validate them along the way. We can generate new and innovative technology by going through several of these layers of investigation processes.

Paradigms behind the development of a digital product

Agile and Design thinking

Design thinking[1] is a methodology used to solve complex problems by going through several layers before execution to ensure that we are solving the appropriate problem in the best possible way.

This methodology consists of a series of linear investigative processes that depend on the outputs and inputs of the previous process for proper execution. This order of execution goes as follows:

• Empathize: Discovering and exploring; Understanding your users’ needs.
• Define: Stating your users’ needs and problems.
• Ideate: Challenging your assumptions and creating ideas.
• Prototype: Creation of the solution.
• Test: Where you need to test and evaluate your potential solution

In February 2001, a group of 17 software experts met in Snowbird, Utah, to discuss the dire state of software development. At the time, people created software using inefficient, bulky, and high-ritual processes like Waterfall. Agile methodology was born at the beginning of the 21st century as a need to correct certain inefficient practices in the development of projects.

We cannot refer to Agile[3] as a series of facets or steps to follow as Design thinking, but rather, as a set of principles and values that we must reflect in day-to-day tasks. Instead, here are some principles that you might find useful:

• One priority to consider is to satisfy the customer through early and continuous delivery of valuable software.
• Business people and developers must work together daily throughout the project
• Build projects around motivated individuals. Please give them the environment and support they need, and trust them to get the job done
• Working software is the primary measure of progress
• Simplicity–the art of maximizing the amount of work not done–is essential.

This iterative, progressive, and asynchronous nature gives Agile a way to parallelize tasks and keep continuous experimentation that in turn, helps to face adversities successfully as we deal with them little by little.

Takeaways

As we went deeper across some methodologies commonly used while creating and developing a project, we encountered some similarities, and in fact, some of them follow almost the same research principles and definition of activities regarding product development. This gave us a better perspective why software development and design are very similar. We learned how important it is to blur the lines between each other for a better collaboration, and how important it is to find similarities between both, and try to not keep them separate. In the end, they must coexist in order to achieve the same goal.

In the 2nd part of this story, you will learn more about how these two sides of the same coin complement each other.

References:

1. Brown, T. 2008. Design Thinking. Harvard Business Review, Brown, T. Wyatt, J. 2010. Design thinking for social innovation. Stanford social innovation review, Lockwood, Thomas. Design Thinking: Integrating Innovation, Customer Experience and Brand Value. New York, NY: Allworth, 2010.
2. Andersen, Anne; Hepburn, Brian. “Scientific Method”. In Zalta, Edward N. (ed.). Stanford Encyclopedia of Philosophy, Scientific method at PhilPapers, Scientific method at the Indiana Philosophy Ontology Project
3. “Introduction to Hybrid project management”. 20 July 2016, Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide), Fifth Edition, Abrahamsson, P.; Salo, O.; Ronkainen, J.; Warsta, J. (2002). “Agile Software Development Methods: Review and Analysis”. VTT Publications. 478. Archived from the original on 7 September 2011. Retrieved 20 February 2012, Shore, James; Warden, Shane (2008). The Art of Agile Development. O’Reilly Media. ISBN 978–0–596–52767–9.

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 🌿🧼