over 3 years ago from Noorain Noorani, Product Designer at Symbility Intersect
I've been struggling with this recently - a screen can have different states based on different conditions. But how do you communicate that to engineering? While InVision is useful to see what the state looks like, how do you explain what drove that state?
Whenever I write the project brief for a developer, I try to write these sorts of flows in the form of a question. For example:
What happens when the user "does this"? (replacing does this with the action)
When should X end?
Who will see this screen?
etc.
Since a lot of these "if this, then what" flows are based on questions, I always find that it's easier to communicate the question we are trying to answer with the intended result/action. Having the issue to refer to, and speaking with engineering in person is always the best way to go if your team/organization supports that kind of back-and-forth.
Hope this helps!
How are you documenting these and making sure that the correct people are seeing them?
We use Github heavily, so all of the descriptions are stored in issues that we can reference later. We also try to create action items for each section of a description (i.e. the questions I mentioned earlier) using tasks - [ ] ……… that help to summarize what we expect to see once the PR is submitted. This way everyone is on the same page about what's been completed, and what's still WIP.
In terms of assigning people, Github handles that as well. You can assign the appropriate person/team to a particular issue, and so the right stakeholders are notified about the project. We also have tags that describe the status (i.e. In Progress, More Info Needed…, Priority Levels, etc).
That is an interesting workflow - built right into the engineer environment. Thanks for sharing, I'm going to consider this!
Login to Comment
You'll need to log in before you can leave a comment.
LoginRegister Today
New accounts can leave comments immediately, and gain full permissions after one week.
Register now