Our mission
How we imagine a better workflow between product managers, designers & developers
We try to empower creative teams of totally different people to work towards the same project goals!
The Challenge
Turning ideas into viable products is a big struggle for creative teams. It's a commonly used approach to plan and build projects iteratively (Build, Measure, Learn).
Every iteration requires interactions between product managers, designers, and developers (see the image below).
The challenge is to create a synchronized workflow that allows them to work towards the same project goals – meanwhile retaining everyone's responsibilities.
Every iteration requires interactions between product managers, designers, and developers (see the image below).
The challenge is to create a synchronized workflow that allows them to work towards the same project goals – meanwhile retaining everyone's responsibilities.
In order to empower each department with a meaningful degree of autonomy, there needs to be a clear division between Management (Business Strategy), Design (The Look&Feel) and Engineering (How it works).
From the very beginning, everyone is involved throughout the process cycles without handing over the reins!
The following articles describe our vision and efforts to create a design- and development-driven workflow for building websites, apps or software.
From the very beginning, everyone is involved throughout the process cycles without handing over the reins!
The following articles describe our vision and efforts to create a design- and development-driven workflow for building websites, apps or software.
Product Manager
Responsible for strategic decisions, setting up prioritized business objectives and monitoring the overall project process.
UI & UX Designer
The visual force of the team, providing aesthetically appealing and user-centered design decisions - mostly without writing a single line of code.
Engineer
Creates the overall system architecture and data model, implements frontend logic and integrates the backend system.
These are exactly the driving forces to build stunning products. But we have to change the way they interact with – and understand – each other.
In order to define a better workflow that involves the whole team, we need to identify common pitfalls and flaws. It seems like they have been accepted by most companies nowadays.
Workflow or Workflaw? Typical signs of broken or bad frontend workflows.
Product managers feeling left behind (not involved in the cycle)
Designers handing over .psd or .sketch files to the developers
Developers fiddling around with HTML & CSS
Product managers underestimating SPRINT goals
UX designers writing complex code
Developers fixing layout bugs (grids, buttons, pixels)
Designers handing over .psd or .sketch files to the developers
Developers fiddling around with HTML & CSS
Product managers underestimating SPRINT goals
UX designers writing complex code
Developers fixing layout bugs (grids, buttons, pixels)
These are the typical symptoms indicating a broken workflow within your product team. If you can directly relate to any of those points, you should follow us on our mission to define a better experience building great products.
Identify causes
Let's take an in-depth look!
How does each department work in order to fulfill an iterative approach? What are their common tasks? Is everyone contributing to the final product or release cycle?
How does each department work in order to fulfill an iterative approach? What are their common tasks? Is everyone contributing to the final product or release cycle?
(add introduction on iterative approaches)
By putting each ones tasks side-by-side, one can easily see that there is a resemblance between the cyclic processes.
Surprisingly (or not), even steps with the same meaning are aligned next to each other (e.g. Measure, Evaluate, Test).
This is a good starting point to define a workflow that combines those separate cycles.
Basic constraints and requirements:
Surprisingly (or not), even steps with the same meaning are aligned next to each other (e.g. Measure, Evaluate, Test).
This is a good starting point to define a workflow that combines those separate cycles.
Basic constraints and requirements:
- Respect the established workflows
- Define intersection point(s) within the cycle
- Little dependencies to ensure flexibility
- Leverage design thinking
- Make room for innovation & experiments
- Clearly defined responsibilities
Case study: building a website from scratch
Effectively using the iterative design & development process to build a complex website.
From client briefing to final website. How we effectively use an iterative approach without separating the parties.
The designer starts to create different website mockups in photoshop while relying on the client specs. The main goal is an overall look & feel without getting into technical details (placeholder images and texts are heavily used here).
A first review with the client is initiated to decide which design best fits his needs and personal taste (sic). Now the designer needs to rebuild the static mockups into valid HTML pages. We heavily use Webflow for that. It's a powerful and intuitive WYSIWYG Tool to build responsive websites from scratch.
At this point, we got a fully functional website (let's call it designer preview version) without writing a single line of code!
The developer is able to set up the data-model, server logic, and necessary data bindings in parallel.
The model can be external data of any kind. Be it an SQL database with customer data, a spreadsheet with dynamic content or data fetched through 3rd-party API's.
These sources are normalized by creating an endpoint serving static JSON for the data and allowing dynamic requests for user actions.
Let's glue those pieces together!
We evaluated numerous data-binding frameworks. It turns out that the best way to inject data into Webflow-generated html is by using KnockoutJS. The data-bind tags allow us to connect the static design to dynamic data in a nonobtrusive way. Even complex repeating patterns and master-detail views are no problem.
The website is now ready to be reviewed by the client.
The client feedback leads to minor layout adjustments and a completely new color scheme. The clear separation between frontend design and data-logic instantly pays off:
The designer is able to integrate all changes (no need to bother the developer with confusing emails) and has full control over pixel-perfect results.
Conclusion:
This degree of freedom gives us the ability to instantly react on future design changes (let's embrace iteration).
The designer starts to create different website mockups in photoshop while relying on the client specs. The main goal is an overall look & feel without getting into technical details (placeholder images and texts are heavily used here).
A first review with the client is initiated to decide which design best fits his needs and personal taste (sic). Now the designer needs to rebuild the static mockups into valid HTML pages. We heavily use Webflow for that. It's a powerful and intuitive WYSIWYG Tool to build responsive websites from scratch.
At this point, we got a fully functional website (let's call it designer preview version) without writing a single line of code!
The developer is able to set up the data-model, server logic, and necessary data bindings in parallel.
The model can be external data of any kind. Be it an SQL database with customer data, a spreadsheet with dynamic content or data fetched through 3rd-party API's.
These sources are normalized by creating an endpoint serving static JSON for the data and allowing dynamic requests for user actions.
Let's glue those pieces together!
We evaluated numerous data-binding frameworks. It turns out that the best way to inject data into Webflow-generated html is by using KnockoutJS. The data-bind tags allow us to connect the static design to dynamic data in a nonobtrusive way. Even complex repeating patterns and master-detail views are no problem.
The website is now ready to be reviewed by the client.
The client feedback leads to minor layout adjustments and a completely new color scheme. The clear separation between frontend design and data-logic instantly pays off:
The designer is able to integrate all changes (no need to bother the developer with confusing emails) and has full control over pixel-perfect results.
Conclusion:
This degree of freedom gives us the ability to instantly react on future design changes (let's embrace iteration).
There's more to come! Stay tuned...