The two founders knew the importance of having a dedicated UX designer in their core team (which is not so common, especially for startups founders), and that the way to work with her/him in the company was decisive for the product success (since its VP, Value Proposition, mainly relies on the UX).
They gave me the freedom to think about the best conditions for me to work. A way to design my own work experience which is quite a mise en abyme for a UX Designer.
The process progressively emerged in our team. It now consists in 3 main steps for UX Design.
1. Roadmap: Define the functionalities to develop
Since our VP is the ease of use, the UX needs to be part of the development prioritization.
A product can’t be user-friendly if:
- functionalities the user really needs aren’t available: your product will be off the target, won’t be used and then there won’t be a product market fit.
- it doesn’t match the user’s expectations: if you propose an advanced functionality, the user will expect the basic one to be in your product. If it’s missing, the user won’t understand why and might get lost or not use it properly. The experience won’t be satisfying.
Therefore we prioritize future developments together, taking into account the app goals, user’s needs and development complexity.
2. Design: Build relevant and complete specifications
First, I work on a design proposition on my own. I do a lot of researches and technology watch to get inspirations, and see best and bad practices. Then I make a first design according to our practical problematic and our product.
Then I confront it to developers and graphic designers for them to give me their feedback, ideas and feasibility. If needed we work together to reach a compromise.
By the way, this step is really important for a UX designer: the better we understand the other jobs’ constraints, the better we can anticipate them in our future designs.
Finally, I document the chosen design with specifications, visuals, behaviors descriptions, references, etc., so that developers and graphic designers can do their part in the best conditions.
It is also a gain of time for the future, we always have a comprehensible history of our different designs to refer to if needed.
3. Review: Test the feature
Once the development is done, the feature can be tested. During this step we make sure that:
- what has been designed on paper works well in reality: we can’t be sure a design is the good one without testing it; first by ourselves and at best and if possible, with user testing.
- the design has been respected: let’s be honest, sometimes some things are forgotten or misunderstood. It is our responsibility to follow developments and validate the UX.
At Opuscope, we decided to put the UX review at the same level as the code review. The developer creates a merge request, and they can merge on master only if it has been approved by both the code reviewer and the UX reviewer. This is a guarantee for a stable code and, above all, a great experience, because in the end, all that matters for the customers is our VP.
Technically speaking, we use Gitlab to do this. If I see a design problem in the merge request, I start a discussion in it to report it. I often use screen recordings to show the problem from the user’s point of view. We can all comment the discussion and we close it when the problem is resolved. A discussion is created for each problem to be able to easily follow the development.
I also use Gitlab to create issues relative to UX improvements for existing features. We work on it with the assignee just as for a merge request discussion. When the issue is ready, the assignee puts the “UX-review-ready” tag.