I worked in several Frontend projects in my past career by now. This article is my take on what I learned would be helpful to consider when starting a new product in your company. I try to make it short :-)
By now I've learned, that it is cheaper to involve the following disciplines as early as possible in a web project:
- product ownership
- quality assurance
Here's what I think they can contribute to. You will see it is quite complex. I expect to not find a single person per discipline but rather people with multiple strength in them. Otherwise the communication overhead will get quite high.
However, you will likely not get all parties on the table for a kickoff. So this article serves as a heads up on what you are missing out and thus will increase costs down the road.
Somebody has to make a final call and decide, what needs to be done.
A product owner needs to the customer best and decide, what steps will yield the most value.
By creating wireframes, assumptions can be tested early on, before much money was invested in the process. The wireframes should explore different information architectures and patterns (e.g. navigation).
By now, there are different tools online to allow work in remote teams also. This way, tests with different cultures are possible.
Taking wireframes or prototypes, people could be asked questions about understandibility of the project. This way the business idea can be validated or pivoted until a market niche was found.
UX should also work together with marketing to explore, who the competition is, what they are doing and how good they are at it.
Design plays a major role not only in how something looks but also in how it feels. This way a brand is communicated.
Also design should keep an eye on consistency and rhythm.
Words have power.
By setting the tone, a Content manager can influence the perception of a product. Keep in mind that it is not limited to the product itself, but also applies to other areas where customer talk about it.
Accessibility (a11y) is not only important for people with disabilities. But by keeping those in mind, you're supporting all of your audience.
Keep in mind, that you yourselt can get in aituations where you could benefit from it. Say in a loud noise or bright light.
Speaking of accessibility: Keep in mind that you have to abide to laws in certain countries which force you to meet certain accessibility standards.
Legal should also inform you about derivations like taxes or terms and conditions.
I refer to marketing not only to people ordering swags, but also to people who are responsible to spot audiences and market niches.
A product must find an audience if it wants to get customers.
This means not only get a good ranking in search engines (like Yandex or Google), but also on relevant stores (iTunes, PlayStore, Amazon Marketplace) or catalogues.
These people should make a call to keep the data collection to a minimum.
Because once data leaks (that's a question of when, not whether), it will cause damage. So by not collecting in the first place, the damage can be reduced to an acceptable level.
These people can give insights into what is technically possible. It is important to strike a good balance between getting a product out as early as possible (to get feedback from customers), but thereby not setting impediments for future grows. That is: Start lean, but allow scaling easily.
Speaking of scaling, it is likely that a product will develop a need for internationalisation (i18n).
That implies not only translations, but also affects the design (think markets, where people write from right-to-left). Adding the possibility to do so early on will make it way cheaper in the future.
These people are responsible for providing the technical infrastructure and make sure it runs smoothly. They should make a call, whether to run things in the own datacenter or in the cloud.
In order to be successful, you need to comply to certain performance tresholds. Otherwise people will just leave you for the competition.
You can already look for tools and educate people at the beginning of a project.
Security should be thought of from day 1. It implies not only what data to consume, but also to define the threat models and make some risk assessments.
Security should be part of the whole software development lifecycle.
Ah, documentation! It is highly valuable to have it. However, there is a risk that it outdates quite fast. That can be countered by auto-generate it (on demand) or by regularly checking it.
It will pay dividends once the product grows and more people are in need of onboarding.
Last but not least quality assurance. By bringing them on the table early on they can positively influence the design of the software by making it easily testable.
Also they can catch errors before thry land on the production environment.
Software development got quite complex. On the other hand, this makes it fun and challenging to work in this industry!
Did I miss something? Please, let me know!