Thanks for the response!
Yeah, my thoughts exactly about time consumption. That's why I wanted to automate at least a part of it to minimize the need for interaction.
If I got you correctly, do you show all of the states a component can be in? Do you include some more developer-specific details?
Most of the time components are pretty self explanatory, right? I only draw a little ----> with side-information in between components when I feel like this needs extra information to understand. This is pretty rare though.
Design wise:
What I do create though is multiple versions for different states. So I got my <AwesomeButton /> component and this component will have a default, hover and focus state. The person implementing this just needs to look it up and be very strict to follow the example in there. If it says the padding is 5px, just copy what's in the design guide. The design guide should be the source of truth because everyone is following it. If it's flawed, everyone works off of a flawed base.
What I like to do upfront before even starting anything:
Create a good old entity relation diagram. Of course this depends on the size of the team but when working with very few people this is the perfect opportunity to brainstorm ideas. This is definitely more of the tech side of things, for example:
What properties should a user have?
How do we store this information in the database? What could the database-structure look like?
First pitch on technology/hosting that we plan on using
and so on
....
This diagram does (in my case) not get updated once we start and only helps for us to be all on the same page when starting out. Often time it also helps to find new ideas when just writing things down together and talking about them.
I feel like I drifted a bit off topic - hope I answered what you asked at least to some degree :D
The design stuff and the entity relation diagram make sense, but in our company, our design and backend departments take care of those things so I haven't put much thought into that. But thanks for your input, it's good to look at the bigger picture once in a while!
Of course and thanks for the time you've taken to explain it :D
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for the response!
Yeah, my thoughts exactly about time consumption. That's why I wanted to automate at least a part of it to minimize the need for interaction.
If I got you correctly, do you show all of the states a component can be in? Do you include some more developer-specific details?
Most of the time components are pretty self explanatory, right? I only draw a little ----> with side-information in between components when I feel like this needs extra information to understand. This is pretty rare though.
Design wise:
What I do create though is multiple versions for different states. So I got my
<AwesomeButton />component and this component will have a default, hover and focus state. The person implementing this just needs to look it up and be very strict to follow the example in there. If it says the padding is 5px, just copy what's in the design guide. The design guide should be the source of truth because everyone is following it. If it's flawed, everyone works off of a flawed base.What I like to do upfront before even starting anything:
Create a good old entity relation diagram. Of course this depends on the size of the team but when working with very few people this is the perfect opportunity to brainstorm ideas. This is definitely more of the tech side of things, for example:
What properties should a user have?
How do we store this information in the database? What could the database-structure look like?
First pitch on technology/hosting that we plan on using
and so on
....
This diagram does (in my case) not get updated once we start and only helps for us to be all on the same page when starting out. Often time it also helps to find new ideas when just writing things down together and talking about them.
I feel like I drifted a bit off topic - hope I answered what you asked at least to some degree :D
I see now, I get your point much better now :D
The design stuff and the entity relation diagram make sense, but in our company, our design and backend departments take care of those things so I haven't put much thought into that. But thanks for your input, it's good to look at the bigger picture once in a while!
Of course and thanks for the time you've taken to explain it :D