A few days ago marked the day I’ve been working in-house for 2 years. I think overall I am very happy with my decision to go in-house as a product designer. I gained a new perspective by working on a product full-time for a longer time. The depth in which you can go as an in-house designer when compared to agency work is incredible.
The other day I was investigating the voiceover implementation in our native iOS and Android apps.
Sometimes there is work that forms itself over many months. For example over the past two years I’ve tried to hold a tight guard on improved branding of Doccle overall, with some successes and some ways to go. Another ongoing project is moving Doccle to be a primary example of a great native-looking iOS and Android app, that embraces Apple and Google’s respective design languages. I’m happy with the steps that have been taken and that we are taking.
Now, it’s only logical that your work goes deeper because you have many months to work on similar problems. I keep remembering is this tweet by someone from Github that you better document your work in product, because it’s going to come back anyway. My CEO tells me he sometimes feels like the living memory of Doccle.
Some activities of the past two years included working on user interface designs, doing user research, tackling brand and visual design, writing front-end code, work on product strategy, improve and write new copy (in 4 languages), … and so much more.
As a designer, I am and always looking for opportunities to improve what we have.
Sometimes this is perceived as a kind of permanent unhappiness, and it can really get on the nerves of colleagues. Navigating stakeholders and decisions when you are sometimes basically stepping on someone’s work is its own challenge. I’ve learned to be more polite and more considerate of past work.
I’ve also learned that you can’t simply change something because you want to change it. The change has to be an improvement. Moreso, the change needs to have all blocking questions answered and depending on what it is, need to be thought through end-to-end. This is not always the case, but for things shipping to millions of users, it is.
The desire for change causes issues for others in the company. Change can mean disruption.
Arriving with my agency perspective I quickly started work on improved designs, only to find out that the company didn’t move as fast as my designs did. I made designs that I knew best – category interactions – filterable datagrids. Tidied up design systems. Then, it took a while to get implemented.
At first I attributed it to the company, but I believe it’s a reality of product. I came in with the naive expectation that if I would design it, it would get implemented. Boy, was I wrong.
When I was designing in an agency context, I rarely saw the actual implementation side; we consulted and came up with designs, but we often didn’t see how long it would take to get to an implementation. Or, we would specifically be hired for a redesign track, so the redesign was already decided within the company we were working for.
At Mono, we knew in the back of our heads that we finished up a project 6 or 12 months ago. Sometimes we got updates, but sometimes we didn’t hear about it anymore. Then, two years after a design we’d suddenly see a public implementation of our work pop up. Not every project would follow this pattern but it happened more than I liked.
I’ve now internalized the reality of a product moving much slower than the designs. Basically you are there during the whole timeframe of the implementation. But the detail you go into is so much deeper. From lokalisation in four languages, to designing the same feature across three platforms with multiple form factors, to overseeing the final implementation details.
I learned that as a product designer, you are moving across different types of design. This was not as apparent in agency work. I feel like we often got hired for execution, and not for research or problem definition. When we got hired, we already knew what the problem was. This is not always the case now, and thus I’ve been improving my research skills.
Designing gives you the chance to evaluate solutions before they have to be implemented. You diverge to converge. There is still a possibility space, where once you are in the implementation zone, that space changes more to an impossibility space. Scope gets locked down and in order to achieve a timing, you can not add more ideas to the table. In a next post I want to elaborate more on the three types of product designs I’ve identified.
