Efficient development workflow with design teams
When working with designers, the communication will most of the time boil down to you getting a sketch and converting it into a dynamic web app. During that process, you will fine-tune it and make sure that everything is as the designer(s) imagined.
While this sounds simple, if not approached properly, it can very quickly turn into unmanagable nightmare.
To improve this process from the very beginning, it’s very essential to coordinate workflow between developer, designer and revenue teams since they are the ones acquiring product features, which are then designed and converted into dynamic apps.
The Flow
1. Design
If you take a look at the flow diagram, you’ll notice that many paths relate to the design phase. This phase is in fact the most essential for us because it defines the work we’ll need to do when mockups are handed to us. For that reason, it’s very important to coordinate and open discussions between revenue and design teams and make sure that they agree on final design, both, UI and UX wise.
While mostly will not be the case, being part of this process and technically guide it could be of great importance cause you don’t want to end up with design super multimedia heavy and yet expect the page to be fully SEO optimized. It’s important to stay in the domain of beautiful but still efficient. It’s also very important to warn both teams that running backwards is much harder then moving forward. What I mean by that is, changing things in the middle of the process is a lot harder for us then let’s say for designers, who will drag and drop this and that and come up with requests which are very hard to implement without removing bunch of code which already took X amount of time to write.
For that reason, continuous communication between those teams and alignment on things that need to be done is essential.
2. Mock
Mocking phase is indistinguishable from the design phase. During this phase, designers will try to mimic the eventual UX and dynamicity of the design. Throughout this phase, designers should do their best to make the mockup as close as it should be to the eventual finished product. This will speed up the development process since most if not all logic and dynamicity will already be defined.
As always, continous communication should be part of this process since we don’t want to end up with overcomplicated UX which benefits no one.
3. Feedback
It’s time to test our awesome mockup. This is a great time to share it internally with all teams and get feedback. During this phase, we want to get as much feedback about UX/UI and see if something can be improved. Throughout this process, designers will discuss the feedback with revenue and development teams and agree if some of it should be implemented.
This is the best and the only time when requests should be accepted. If we don’t communicate and implement specific idea or features in this phase, doing it throughout the coding phase would be very time consuming and would effect the entire process. For that reason, spending extra time to talk to people internally will speed up the process by million miles.
4. Behaviour
While we’ll be able to “fetch” a lot of behaviour from the clickable mockup already, not everything will be there. Mocking tools are often very limited and it would be silly to expect that designers will cover every little use case.
At this point, we want sit together and discuss entire logic of our project. We discuss the flow and try to as in detail as possible define all the little things that could happen in our system. For example, what happens when user tries to check his profile and he is not logged in ? What happens if user is logged in but has no articles in his blog ? What happens if user has no products in his cart and tries to checkout ? Regardless of the use case, we want to define those things as precise as we can.
Luckily, this doesn’t need to be reflected in the mockup at all. Usually, the most efficient way is to take a pen and paper and write down all the little things. To us developers, this will be extremply helpful since it’s going to give us much clearer context of what needs to be done and how to approach the architecture.
It’s very essential to be very active and drive discussion throughout this phase as it will allow us to gather a lot of information about the system we need to build.
5. Coding
At this point, we should be fully knowledgable of what needs to be done. All we need to do is take the existing dynamic mockup, all the behavior we previously defined and start hacking. Since we live in an era of component-based frameworks and MVC / MV(something) architectures, next resonable step would be to either draw our component composition if we are talking about frontend or define an API if we are talking about backend.
In both cases, its important to focus on all the knowledge we gathered through the development-lifecycle and use it in our advantage to develop a good foundation on both ends. As always, grab a pen and paper and draw the architecture.
6. Integrations
Doing integrations works best when the actual product works as intended. If so, we define what we want to track and how we want our integrations to load. Regardless of what type of integrations we are talking about, it’s always best to integrate things on the code base which we are sure its not gonna be changed the next day.
When we speak about tracking (e.g. Google Analytics), we mostly track events on our UI, therefore, implementing tracking on the UI during its development would be completely silly.
Summarization
If you take a look at the flow again, you will notice that 80% of the process relates to non-developer teams. This basically means that we are not more then tools. How efficient we will be, how amazing our code-bases will be mainly depends on the information we get upfront and how well we interpret it.
This means that regardless of being out of the flow most of the time, we should be very active in asking the right questions and gather as much knowledge as possible.