Page Title

suppose we are working in a average size dev team then what would be the complete workflow of the design components from

inception to deployment

also how its determined how much freedom we have in going crazy with cool effects animation and stuffs ?

Answer by Janning

The average dev team is a myth. I've worked with a wide variety and they are all run differently. You can accomplish a lot in a short amount of time if you have hand-picked experts in each of the components you need and they all play nicely with others. What most companies don't understand is how to form a team. The tools and process are not as important because as a project/product manager, it's worth it to adjust and adapt to the workflow of the experts you've chosen. If you let them have their way in one thing in their wheelhouse, they are more willing to let someone else have that someone else's way on something else in that someone else's wheelhouse. That's my disclaimer: The team of chefs is more important to bringing a project from inception through to deployment than how the recipes are put together. The existence of recipes (specifications/designs) are important as a frame of reference for decision-making and contractual disputes.

That all being said, most dev teams (I say this without objective statistical verification) are on some sort of agile/scrum bandwagon. I personally believe it comes from an I-don't-know-how-to-evaluate-good-software-developers mentality from the top (VCs are particularly fond of this method), which trickles down to management in the form of well-we-don't-know-if-your-management-style-is-all-you-claim-so-we-want-to-feel-safe-by-having-you-follow-this-method/system, and because there's a system in place independent of the actual managerial skills of the managers, the expectation is that the system is so magical that it will make a ton of cheap junior devs as efficient as more expensive experts. The scene is set for utter chaos (disguised as organization) to ensue. You've got stories, you've got stand ups, you've got points systems (sometimes), you've got sprints, etc. All borne from a very short-term mentality of failure to commit (i.e. we can pivot at any time).

So we start our journey thinking that development should be an organized process from inception to deployment and it all hinges on the team's collective ability to make consistent decisions based on the specifications/designs.

A note about artistic freedom: It depends on the client. Some clients are very goal oriented and trusts the team with getting it done however they see fit. Others have a very specific experience in mind, in which case even if you took the time to create it your way, it might be under appreciated, thrown out, and redone. Many programmers haven't side projects as artistic outlets.

So not to sound like I'm avoiding a direct answer, I'll tweak the original question a little... Here's a rough sketch of the beauty of working for a non-average dev team -- one with experts, clearly defined roles, and play nicely with each other:

The salesperson ensures the client appreciates what the dev team brings to the table so expectations are well managed.
product manager works with the client to identify, articulate, and prioritize the features the client wants to see (you can see how this might be problematic for startups who don't even know who their customer base is half the time) enough to come up with specifications that will be included in the client contract and will guide the dev team's design choices. (Sometimes the client has specifications and designs ready, but it's rare that the documents they think they have are sufficient to execute on.)
manager brings contract back to project manager (s) and work out how to break up and assign tasks based on each team members' expertise.
Issues are loaded into the version control system.
culture is such that everyone is comfortable asking questions of each other and getting management on board with any changes or potential deviations. Everyone follows the style guide, review process, and deployment strategy.
The product manager puts together the software documentation for the delivery of work product to the client and works with the salesperson to frame the presentation.

It's more important to have whiteboards for working out designs with team members than to have a special software. I've used something extremely light like moqups before just to make sure we have the "feel" right for a couple of key screens, but otherwise, experts should be able to understand and translate storyboards in any form. My opinion.

Answered by Sumith G

Great detailed answer Janning⭐ . i have experienced some of them and mostly the priority gets shuffled when you are working in different projects at the same time.

now my further thoughts in this question. My experience have led me to understand that user experience of the interface has to be intuitive and simple. While you may start sketching in paper or on any mockup tools, it's more important to decide in the flow of you website. e.g

the placement of buttons,
neat categorization of menus,
content should be brief and concise,
use of simple animations and so on.

with the gaining popularity of Single page applications, you can try and work on building a single page app keeping in mind what contents need to make it to the website and what shouldn't

Your thoughts Janning!!!

Replied by Janning

Sumith G, I concur.

It's a good idea to have someone talented in UX on your team. It's much more than just minimizing number of clicks. For example,

having landing pages (call to action) for promotional campaigns and A/B testing them can also be important, so SEO folks are good too.
Someone can be in charge of the sitemaps, robots.txt file, indexing with search engines, etc.
Others can be in charge of testing responsiveness at different zoom levels, browser versions, screen dimensions, etc.

There's quite a lot that goes into a great website.

Workflow of WebDesign