Re-evaluate and iterate it tomorrow
Hey reader 🙌
In this article I decided to share some insights about our Design process documentation that was shared internally in Transifex few months ago and after that followed and executed in numerous designs, experimentations, UX researches, and explorations.
The goal of this documentation was to be a clear, concise path to follow when uncertainty or vagueness emerged within the design team, the organization and also create some workflow in an agile and growing environment.
Developing your own process is almost as important as developing your own design style.These workflow peculiarities will get you through hard times, and they’ll make your service more memorable to clients.
Wasn’t easy at first because we had to actually learn, try and test all these practices. And we did. Each and everyone of them.
And we didn’t stopped there. We captured feedback, responses, we looked on engagement, and conversion of these practices in order to define which performs better if you are at the ~Understanding The Problem phase and which ones at the ~Proto.2.x_iteration2.sketch phase.
What I learned from documenting the process is that each practice or chapter has many variables.
You can do a design sprint that will not produce a thing, you can create 30 screens in InVision and get no direction but in the other hand you can present a spreadsheet with grey boxes or a B&W prototype and everyone magically just syncs with your vision.
So it depends on organization, team, use case, maturity, roadmap, customer requests and many more factors… Most importantly a process that respects itself should be flexible and adapt in new changes.
Enough with the prologue.
So…here it is — the raw, uncut, uncensored Design Process here at Transifex.