“Privacy-first digital products will not build themselves”

“Privacy-first digital products will not build themselves”

“Privacy-first digital products will not build themselves”

A glimpse of a couple of topics I covered at a Swiss-based, privacy-first company and the caveats that come along with it in terms of limitations or otherwise alternative approaches

A glimpse of a couple of topics I covered at a Swiss-based, privacy-first company and the caveats that come along with it in terms of limitations or otherwise alternative approaches

A glimpse of a couple of topics I covered at a Swiss-based, privacy-first company and the caveats that come along with it in terms of limitations or otherwise alternative approaches

@Proton

Senior Product Designer

Visit site

@Proton

Senior Product Designer

Visit site

TL;DR

TL;DR

  • Lead the ProtonMail app Android & iOS design development.

  • Face-lifted key app areas.

  • Monitored user feedback in order to improve the user experience.

  • Brainstormed & developed future app & suite features.

  • Participated in user interviews.

  • Advocated user centric approaches.

  • Aided the rebranding from a product perspective.

  • Created unique visuals for the suite as a whole (illustrations/product app icons).

Getting to know my surroundings

Getting to know my surroundings

Getting to know my surroundings

Getting to know my surroundings

When I first joined Proton my domain was simple: ProtonMail on mobile, both Android & iOS. Great! That’s what I do well and feel very comfortable while working on both. With that the first challenges also arrived. The initial product design until this point was handled by an outside agency and while they did an admirable job at it - certain aspects (especially platform native one’s) were lacking, not to mention very little to go by in terms of data or user insights.


The data part in particular was rather different than what I’ve experienced before. Normally you could track certain usage aspects of your product, but at Proton - privacy & security was the absolute priority and we all took it extremely seriously. If a certain tool even had a whiff of ill advised security built within it - we’d simply discard it or look for an alternative.


Luckily even though we couldn’t employ the usual methods Proton had something else that was equally helpful - a very strong, active & vocal online community of users. This was definitely a leg up when it came to gathering people later on for user interviews as well as quick glances of how a certain feature or a heavier update is being received. It’s always healthy to have contact with the group of people that use what we produced on a daily basis - it gives a great pulse check whether you’re moving in the right direction and are able to pivot quickly if necessary.

During my time at Proton I saw the product grow from V3 to V4 and finally to a rebranded V5.

The blueprint

The blueprint

I’m sure this image has been seen a thousand times by anyone working on product. It’s the ideal blueprint of how features/updates/changes are meant to be applied. While not always following it exactly - this was the approach we always had in mind when tackling various features & improvements for ProtonMail.

Message view

Message view

In my mind there are two areas of extreme importance within an email client like this: the message view & the inbox view. Both are crucial when it comes to either how quick can the users access their content and how that content is viewed.


The basis for this was again explored initially by an outside agency - definitely a great foundation that I can build upon with severely edge cases and other nitty gritty details that the product requires to take note of.


Together with the team we were able to align with both stakeholders, long time users and deliver a worthy update of the message view area that we then closely monitor the response of and lean on any feedback that we can in order to improve our initial take.


Last update that I did for the message area as I like to call it “content is king”. The approach here is to emphasise the message as much as possible while also offering a contrasting outline for the thread view in order to make it more readable for any visual impairment (see below).

Slight evolution of the message view.

With that it didn’t take too long to narrow down a few updates that we can work on to improve it even more. One update in particular was always to double check for accessibility colour-wise. This meant updating the taxonomy on a more global level provoking broader discussions within the product design team which was always great opportunity to bounce around some ideas and think of the product suite a lot more.


Bottom message buttons: Now, the following elements are something I’m really not a fan of, although I see the point of their existence. Basically it seemed a bit confusing how to reply to any given message within the thread. Not to all or the very last one, but to a specific one from the entire list. After numerous attempts this was the one that worked the best. The addition that came later - the ‘reply’ & ‘other’ buttons up top which is the part I dislike. But it’s something I can live with. Not all decisions are meant to be agreed upon in full, nor should it take a subjective turn - as long as it works and pushes the needle forward, I’m ok with it.


Attachments: The designs always accompanied slight tiles to the files themselves for quick access. That’s all fine & dandy, but the limitation that we’ve encountered was that we cannot offer thumbnail previews on file types at that stage (before the file type icon redesign) it was decided to free up space for user content instead.


Message rows: This area in particular was a bit divisive over a period of time. We’d get user feedback/data that it was too large and sometimes that it wasn’t large enough. Ultimately with a bit of a larger message touch up overall we were able to strike the balance of “just right”. Just right in terms of row exposure as well as user satisfaction.

Update to the row view: Initial vs. latest.

Special components (“Floaty”)

Special components (“Floaty”)

The element you see below is hard to name since nowadays this might refer to it as an “upside-down-dynamic island-wannabe”, haha. I simply called it a “floaty” since it floats at the bottom - the business/marketing need here was to create something a bit more custom or special whilst rebuilding the app from V3 to V4 in order to have a bit of something that’s not ordinary in terms of elements/toolbar + gives a bit more of a view behind it to your content, which is neat. This Floating element first appeared in 2 places: The message view (housing various actions such as “reply”, “move to...”, “archive”, etc. (as seen above as well) and the selection view - pops up when you’re selecting messages in the inbox view or otherwise engaging in a multi-select environment.


It seems like a fun little element to have, but there were loads of hot discussions around it as from both dev & design end it’s rather not that straightforward to maintain. That’s issue #1, issue #2 was that standard practices work for a reason - it’s what the users understand best, thus when my time came to develop this little component further it was simply discarded. It looks neat, yes. However - the value we create must reflect in the users “want” to see & use it to be fruitful of the time spent developing it. If it was fairly easy to juggle in various environments (dev or design) then sure we can experiment, but when there’s limitations - best to swap it with a more common approach.

“Floaty” in the flesh.

Inbox view (evolution)

Inbox view (evolution)

The inbox view is the very first glimpse of UI that the user sees. It’s also the very first area the user has a feel for the entire product - does it look stale?, Is everything immediately understandable at a glance? Do all the symbols make sense? But most importantly - is my content presented to me in a accessible and straightforward way?


That’s where I got to work - going through both user needs and stakeholder preferences alike we’ve landed on the first minor update: The elements gained a more structure, readability and sizing was improved across the board, covered loads of corner cases. Naturally when this update first launched users had feedback that we’ve definitely weighed for the next iteration.

Unfortunately I’m only able to share one last incremental look at this view - right before the more exciting explorations started. Now, mind you - all if the smaller changes are not currently part of any future update planned at Proton, only treated as an option to address some issues that may have overstayed their welcome: Introduction of dynamic font to the app/adjusted font sizes, some separation/padding fixes to tackle the readability aspect a bit more (Message row scanning) a swell as a proposal to have message time separation. Very minor stuff that adds to the overall aesthetic, but most importantly it tackles user concerns in terms of readability & content exposure a bit better than before.


It’s a bit of a shame I won’t be part of the future updates, but it’s been fulfilling to be part of it nonetheless. Hopefully whoever works on this next will retain the aspects that gotten the app thus far and pushes the envelope to provide clarity for user generated content.

How it started vs. how it’s going vs. how it could be.

Wrapping up

Wrapping up

2+ years flew by really fast at Proton - this is just a very small taste of some of the more important areas of the app that I had the fortune to work on. Seeing that this product is loved by millions of users it was a heavy responsibility to take & helm. I took all the shots that came my way with confidence and always advocated the user first.


This is barely scratching the surface of the sheer amount of work I’ve done at Proton. The explorations, the VAST number of features that are yet to see the light of day, work on other platforms (Mail web to a certain extent), a number of global initiatives that touch all proton products + the mountain of work I’ve done that are outside of the initial scope for a UX designer. I take pride in each and every aspect of it and wouldn’t have it any other way.


That being said my work at Proton always remained user centric. Anything else came after in one way or another - even if a business need overlaps a bit, I advocate the user first and try to steer the conversation to benefit them first.


I grew a lot during my time here and it’s thanks to the amazing product design team that I had the absolute pleasure to be a part of (you know who you are, haha). There’s nothing more satisfying when in a team setting than having peers that simply want to see each other succeed - sharing knowledge and pushing each other forward is what each product team should strive for.

©2023

©2023

©2023