It’s Appening!
The story of an eventful design journey where a Mobile App and a Rebranding share a 6-months timeframe, a 2-people design team, and 1 mission: Demystify property investment.
But first, a tooltip as you onboard, and before I walk you through the process of how it all come to life.
B for Beanstock
Beanstock is a 3 year-old French Proptech start-up, a buy-to-let investment service which translates into an online platform allowing potential investors to browse through a marketplace, play around with a variety of simulation tools, and have access to a multitude of resources to learn everything about real estate and investment. I’ll let you picture the amount and diversity of content it gathers.
Shortly after I joined the product team, the company embarked on a rebranding journey, with an aim to have a fresher and more relatable identity. From there on, and for several months, back and forth workshops took place with the talented team of a London-based boutique studio and before we knew it, concepts and ideas materialised, leaving us feeling quite excited.
In parallel, and to allow for a new improved and more accessible experience for its users, Beanstock had plans to allow them to build and manage their investment portfolios through a Mobile App. One which would rethink and redesign the current experience, allow for various functionalities, and with which users could interact offline, and fast (because modern life).
C for Context
Investing in property is a complex, months-long and oftentimes strenuous process, encompassing a lot of interdependent steps. Beanstock’s mission is to make it seem like a walk in the park, by providing their investors (users) expert assistance every step of the way.
I’ll try to lay out, in a nutshell, what a standard (happy) path would look like. It took me quite some time to fully grasp it myself in order to untangle it.
The below might sound complicated but who doesn’t like a challenge?
So here it goes:
- 💻 Potential Investor gets an idea of their potential mortgage via the tools on the website. If interested, Potential Investor presses a Button that, in turn, informs a Sales Representative of their interest.
- ☎️ Rendez-vous 01: Sales Representative gets in touch with Potential Investor to explain the b.a.-ba (basics) of the offer & process to then guide them through a non-exhaustive 5-Button “to-do list”. This marks the start of their investor path.
- 📁 Sales Representative hands Potential Investor over to Advisor.
- ☎️ Rendez-vous 02: Advisor gets in touch with Potential Investor to validate project’s objectives and follow up on the completion of the previous “to-do-list” which then becomes homework.
- ☎️ Rendez-vous 03: Advisor and Potential Investor validate homework (and consequently project selection). Potential Investor then presses a Button to make an offer for the selected property. After that, they get 1 of 2 things: an approval or a counter-offer [if counter-offer, insert here another back-and-forth procedure].
- ✅ Offer is accepted, Potential Investor becomes Investor tout court.
- 📁 Advisor hands Investor over to CSM (Customer Success Manager).
- ☎️ Rendez-vous 04: CSM explains next steps and starts project orchestration (notarial, transactional & legal paperwork, visits organisation, etc..). Basically a whole lot of different Buttons.
Do you want to skip and scroll? You’re halfway there!
- 📁 Advisor puts Investor in contact with Financial, Legal and Construction Experts.
- ☎️ Rendez-vous 05: Investor exchanges with Financial Expert to establish and ensure funding strategy.
- 💬 [ Insert correspondances here]
- ☎️ Rendez-vous 06: Investor exchanges with Legal Expert to gain knowledge on their property.
- 📑 Numerous transaction-related things happen throughout, along with signing off on a large sum of money, entre autres.
- ☎️ Rendez-vous 07: Investor exchanges with Construction Expert to discuss scope of work, timeline and to validate budget & aesthetics.
- 💬 [ Insert correspondances here]
- 🛠️ Construction & renovation works take place for several weeks.
- 💬 [ Insert correspondances here]
- 🏠 D-Day: Property is ready to be let.
- ☎️ Rendez-vous 08: Rental Manager gets in touch with Investor and explains the process of recruiting a Potential Renter.
And it goes on, but I’ll stop here. You now have an idea of comment les choses s’enchaînent. I think we can both agree that there’s quite a lot going on!
The focus of the below is more about understanding the Behind the Scenes of an investor’s path and identifying the glitches, to consequently design a better experience.
D for Discovery
It goes without saying that understanding calls for exploration, and by definition, exploration goes hand in hand with discovery. Asking questions and getting answers by actively seeking out new information is what would allow for a deeper understanding of the problem and so, better design decisions.
“To know something requires growing within it and letting it grow within you, so that it becomes part of who you are”.
En d’autres termes, there is no better way of understanding something than to be immersed in it, as per the words of Tim Ingold, a British anthropologist whose work i came across while researching for the mémoire I was writing in parallel back then.
That being said, for a few weeks I immersed myself in the Hows and Whys of the investment process within Beanstock. On one end, breaking down the in-house cross-team operations and on another, observing what it translates into from a user’s perspective.
It is through Qualitative Interviews, User Flows, Behavioural Data Analysis, Benchmarks, Workshops, and countless brainstorming sessions that my team and I were able to lead our Discovery process and immerse in the problem.s that needed to be solved.
📝 Note to self: Although an immersion is necessary to get deeper understanding, I do believe that the Discovery for such a complex product is continuous. Also, people change their habits along with the technology they use, how can digital products ever be “done”?
E for End user
To gain deeper knowledge on where and how things were going wrong in the process, getting to know our end users seemed to be invaluable. As a co-leader on this mission, I dug into the database and reached out to a few investors and conducted 5 qualitative interviews (video & audio calls). It was important to have a panel of users that were in different stages of their investment process.
Who are they? How do they use our product? Where do things go wrong? What would they change about it? What would they add to it?
Through those exchanges I was able to have a better overview of who our users are (average age range: 25–45 y/o), what their experiences look and feel like, and gather knowledge on their needs, frustrations and wishes. What I was able to sum up is that users feel:
- 😵💫 Confused, e-mail threads are long and involve too many people.
- 🤨 Frustrated, they’re uncertain about the next steps of their process.
- 🥺 Left out, they need better communication throughout the construction & renovation process.
“J’étais passive, je ne savais pas ce que je devais faire moi, et ce que Beanstock fera et quand.”
“Il y a pleins de petits moments pas clairs.”
📝 Note to self: I would have liked to expand my user research further, speak to more users, diversify the research scope, observe some interacting with the product, but given the context (startup — timeframe), I had to make do with what I could.
P for Problem
Did you also think the list was going to be in alphabetical order? It actually is (kind of), but it didn’t make sense for the Problem to be stated too far down.
“As an investor, I need to have visibility on my next steps, have access to the information I need and have a centralized communication in order to successfully manage my investment project (and get my money’s worth).”
Coming back to the investor path stated above, and in reference to the qualitative interviews insights, the thing that stands out the most is the number of people an investor interacts with from start to finish. Apart from the external communication they might have during their investment period (agent, notary, banker, etc…), an investor’s process with Beanstock involves at least 7 different interlocutors, each with their own set of documents, procedures, deadlines and communication channels. Le tout, under one same timeline, which sometimes seem to be going un peu dans tous les sens.
That being said, trying to manage a whole process (while managing dozens of others in parallel), all the while being punctual, precise and equally à l’écoute in all of them, requires nothing less than superhuman orchestration. And since we’re not superhuman (yet), that reality left both investors and team members feeling overwhelmed, confused and frustrated. As a result, many projects naturally faced unnecessary delays and confusion.
In order to design a better solution, tackling the problems faced by different team members was as important as the ones faced by our users. They somehow go hand in hand. After spending some qualitative time with my colleagues, I was able to have a better understanding of their respective pain points. According to them:
- 👽 Clients aren’t aware of the amount of work and efforts put in the construction and renovation process.
- 🤔 Clients always want to know the “and then?”
🤯 “Si quelqu’un part en vacances, ça devient compliqué.”
😵💫 “Les clients ne prennent conscience de leurs documents que quand il s’agit d’argent. C’est à ce moment qu’ils viennent avec une avalanche de questions.”
📜 “Rappeler des frais à chaque étape par mail prend trop de place.”
We knew we needed to find a way to (conveniently) centralise it all.
G for Goals
The main goals for the experience we were aiming to redesign were then:
🗺️ Autonomy: make the user an actor of their own project, with the aim of reducing the amount of interactions between users and experts, which in turn, would avoid miscommunications and unnecessary delays.
👁️ Visibility: give the user permanent access to their project’s timeline, their schedule, their documents, and the informative content they need at the right time with the aim to reduce frustration and misinformation.
En gros, optimise all the Buttons!
F for Flow
On a micro level, User Flows are like treasure maps. They’re action-focused representations of the paths users take to complete a task in a product, which help identify friction points.
The concept of «flow» is a state of deep engagement when someone is fully immersed in an activity. In his book «Flow», Mihály Csíkszentmihályi explores the characteristics of flow experiences and their positive impacts (entre autres). As part of our Discovery process, it was essential for us, as a starting point, to lay the current user flow out in its entirety and ask ourselves:
What can we draw from the current state of flow? What are the elements that come in the way of an engaging and genuinely satisfying experience?
🚨 Spoiler alert: The experience was very far from being a state of flow!
For each step of the investment process, I laid out the actions involved, the potential roadblocks and interdependance, what information users must have access to, and I imagined how these could translate into features, Buttons and functionalities all the while highlighting key moments for users, to ensure proper communication & notification.
H for Hierarchy
In continuation to our Discovery activities, and given the large scope of work, the not so large labor resources and the relatively short timeline, the next logical (and essential) thing to do was to hierarchise. Therefore, we proceeded to lay out the essential JTBD (Jobs to be done) by a given user, and categorized them between Access, Actions, Visibility and Planning for every step of the investment process. We then voted (stars on image below) for the ones that would make it to the V1 (first version) of the product. And that, for both pre and post investment process.
What are the main things we want new users to be able to do with our product? What are the ones we want investors to be able to do, see and plan through our product?
This helped us prioritize the layout, features and functionality of the V1, for both Web and Mobile apps. We had a clearer picture of what each Button would serve for.
I for Identity
In parallel, on the Rebranding side of the spectrum, and after an identity-focused Discovery, 4 words emerged. They were to be the brand’s traits of character, leading the design for both product and marketing.
That’s when we started rethinking and redesigning the content of the previous website to follow this new tone of voice. Together with the Marketing department, we organised several workshops in which we pressed a whole lot of Buttons. We audited and analysed the whole of the online experience, benchmarked competitors & other inspiring products/ industries to then establish a strategy to ensure the translation of this new identity into the right content.
On this side of the spectrum, we deciphered every aspect of the identity-related content of the product: The About (the story), The Why (the values) and The How (the services).
J for Juggling
Being a product designer in a fast-growing start-up is no easy feat, let alone being one in a team of two. The amount of things to juggle sets the ground for growth and autonomy on many different levels. As a product designer at Beanstock, I wore the shoes of a UX designer, UI designer, UX researcher, UX writer, Content designer, Workshop facilitator and a Spokesperson.
As we were juggling between the Rebranding and the Mobile & Web Apps designs, we could not have succeeded without proper organisation, setting out priorities and most of all, proper cross-team communication.
L for Low fidelity wireframes
After the User Flow was established, it was then translated into Low Fidelity Wireframes that allowed us to better visualise the layout and functionality of the product. These wireframes were subject to several rounds of feedback, iterations and voting, and were an essential step for developers to understand the structure of the upcoming product to give us technical feedback. As they started building the skeleton, we started bringing the UI to life.
M for Managers
By definition, dans les grandes lignes, a Manager is someone who helps develop and implement business strategies in order to help the business accomplish its goals. In other words, they ensure the business is thriving, #nopressure. At Beantock, and given the variety of people within teams, directly or indirectly involved with the end users throughout their process (sales, marketing, product), having a homogeneous speech is vital (no?).
A few months ago I watched a Webinar organized by TPC (The Product Crew) with Alan (a French Health Insurance unicorn), about the importance of the PM and PMM pairing, and how it can change everything in the success of a product. Through the webinar, the speakers compared this duo to a relationship, and more specifically to a couple, denoting the importance of communication between them. Referring to a divorced couple, in a context where they don’t communicate enough.
After watching and assimilating the topics covered in this webinar, I naturally reflected on the environment I was working in. Being part of the product team, working closely (yet not so close) with the marketing team, and having spent quite some time with the sales team (observing the ways they work, and speak), I tried to look for the couples, but there were no rings.
S for Scalability
I know we skipped quite a few letters and jumped from M to S, but that’s the Story Manager’s strategy.
Qui dit vie moderne, dit scalabilité. (modern lifes means scalability)
As we juggled through the various dimensions mentioned above, when the time came for us to dive into the UI, we had to strategically think of how to go about building a new scalable Design System that would adapt to the product’s evolution. Easier said than done.
Reminder of task at hand: A Full Website and a Mobile App.
For some time we benchmarked renowned design systems, dug into their categorisations and layouts to then build the structure of our own, in line with our new identity and functionalities. And since we couldn’t sit and wait for the Rebranded identity to be de finalised, we tried to anticipate the different components we would need through our wireframes, from an atomic perspective. After discussing with the developers, the backbones of this whole thing, we thought a time-efficient strategy would be to move forward by designing the components, sending them to development, and later brand/ style them. This way, we wouldn’t be doing the work twice. When I think back at it, I wonder if there would have been another way to go about it.
To add some more efficiency on the clock, for both us and developers, we drew components from an open-source UI toolkit, that we then customised and modified. Slowly but surely, we managed to grow a functional, scalable design system, that allowed us to design accessible and responsive interfaces, one atom at a time.
T for Teamwork
This section is to express my appreciation for the teamwork and collaboration without which the product could not have successfully come to life. Whether improving work pace (and place), triggering creativity, learning from others, or bringing a sense of accomplishment, cross-team collaboration was one of the most (if not the most) enriching part of my experience within Beanstock.
Speaking of teams, throughout the design process, I found it equally interesting and important to have my colleagues’ ideas and projections about the product. Having their own ways of working, their own sets of daily problems, and being directly involved with the users, there was a lot they knew better than we did. So I collected ideas from 6 team members within 3 different teams that I was then able to categorize and infuse in my design thinking process in the form of “How Might We”.
V for V1
So much more happened in the process of bringing this first version of both the Mobile App and new Website to life, but there’s only so much one can write in a single (engaging) story.
Here are a few screens of the Mobile designs. The Web App is here.
Below is what it looked like with the old identity
You can browse through the old experience here.
W for What happens when you press the button?
When you press the Button you land all the way here, in the last pages of the story. The set is different, another tune is playing.
It’s been less than a month since the Rebranding and Mobile App have been launched, and from where I sit, I wonder how the product actually is speaking to its users. Is it managing to properly communicate?
If I was still in the picture, I would have been eager to get feedback, rethink, iterate. I would have been curious to know in what places we would have been proved wrong by our users. Where do the design choices stand, on a scale of 0 to optimal? What about the Buttons?
If I was still in the picture, I would have smiled at the answers, and at the constant reminders that “you are not your users” and that “if you never ask you never know”. It’s deeply weaved into our human nature to believe that others are like us, which is not a vice but rather an interesting bias to ponder on and to acknowledge. It somehow applies to any life context.
Communication beats assumption any day, wouldn’t you agree?
Speaking of communication, I also can’t help but wonder about my own design choices in the making of this story. What did the content design manage to convey? Am I assuming that you, reader, would be enjoying this? I’d be a fool to assume so, but I would love to know 💬.
If I never ask, I’ll never know.
