ZokuVault is safety deposit vault that helps families plan, organize, and share the important details of their lives.
Research, Wireframing, Prototyping, Visual Design
Client Project for ZokuVault
Sketch, Axure, Photoshop, Illustrator
Defining the Challenge
ZokuVault is a B2B2C product that is offered to financial advisors, lawyers, and estate planners as a value prop for their practice. Those advisors would use the product with their clients, who would then promote the product to their friends and relatives.
In order for ZokuVault's B2B side to function, there was a dilemma in the B2C side that had to be sorted out. According to our clients, users were not actively engaged with ZokuVault. Tests they conducted with their current user base revealed that there was a dropoff in activity after users signed up for the beta. The CEO of ZokuVault claimed that the root cause of this was that users were unprepared for the platform. It’s capabilities were overwhelming users, and it deterred them from using the product.
A solution that the CEO and the Chief designer concocted was that the onboarding process needed to be iterated. The designer already had some high fidelity mockups that needed to be tested out before going into production. Before we concurred, we told them that we’d have to conduct research to get to the root of the problem.
Beginning With Research
“Why are users not engaged with ZokuVault?” was the focal point of our research. But before we could tackle that question, we had to dive deeper. We wanted to learn more about our current users’ behaviors outside the realm of the product. How often do they access their sensitive documents? What methods did they prefer to store it in in? We knew that answering those questions would be critical to understanding the domain. It would also give us a holistic perspective of the issue at hand.
We ended up organizing our interviewees into three groups: end users with prior product knowledge, new end users, and new business users. We then wrote a set of objectives and questions for each group.
Besides learning about our users’ habits, we also wanted to test ZokuVault’s live product. We wanted to see how valid our client’s assumptions were. If an onboarding process was the viable solution to their issue, then we needed to test their current flow. We needed to see what it lacked, and how it was failing to prepare users. This was of particular interest to me because I knew how critical this part of the product was. If it confused users instead of equipping them, then I wanted to find a solution for that. Our clients also emphasized how getting that part of the process was key for the next phase of their product. They were unable to release the B2B side if their onboarding was failing to meet its KPIs.
The Paper Trail
Our research uncovered how our users kept their sensitive documents. Synthesization enabled us to organize that data into usable insights. We discovered that there were two main ways that users managed their documents. It was either by having the paper copies, or with various advisors.
Our affinity diagram on Mural. Each color represented our user. We split our insights into their current experience with storing their documents, and how their ZokuVault experience.
Having paper copies of their documents was interesting to me, but unsurprising. It was what they were comfortable with. Also, our demographic was an older audience who tended to mistrust technology. Our interviews clarified that further, especially since the topic of hacking was brought up often.
“If a company like Yahoo was a victim, then anyone is fair game. Nowadays, everyone gets hacked.”
What surprised me was how their frustrations with paper started to push them towards technology. All our users mentioned how it was inconvenient for them to use paper. It was also difficult for their loved ones to discover where all the documents were in case of an emergency. One user told us how he had to show his wife where everything was once a year to be safe.
When we tested ZokuVault with users, they immediately saw how it could be valuable in their lives. 5/7 of our users claimed that the concept made a lot of sense. Users also found centralizing their documents for their loved ones appealing. But there were still issues with the platform that I’ll delve into deeper later in the case study.
The Challenges for ZokuVault
Another interesting insight we got from user interviews was how often users accessed their documents. According to all 7 of our interviewees, the documents that they would keep in ZokuVault were not things that they would like to, or need to, access daily, weekly, or even monthly. I was shocked, but there were numerous reasons that justified this behavior:
- Trusts and wills are something you look at ONLY when a major change happens in your life
- Wills makes you think about death, which no one likes doing
- It's their advisor’s job to keep track of their documents
- Tax returns are only looked at during tax season
We were able to deduce that ZokuVault was a product that users wanted and needed. But frequency of use shouldn’t define its value. Users were not likely to stay engaged with the product, but that didn’t depreciate it. The nature of the documents stored dictated their activity, not the product itself. ZokuVault’s main KPI should be the amount of users they are able to keep over an extended amount of time.
Besides learning about our users’ habits outside of the web application, we also tested the live product. At first, we thought each user had his or her own qualms with ZokuVault. But we noticed that there were four main issues that bogged new users down. These issues were caused by what was lacking in the onboarding process:
- What is ZokuVault for? Our testers were unsure of the purpose of ZokuVault. The web app has many features, but it confused the users. They wound up being unsure of how the product could fit into their lives. Thus, it lost its luster once users started to explore the web application.
- Why should I trust ZokuVault? All 7 of our testers voiced their concerns about the security of ZokuVault. The product had Swiss bank-level security, and our clients were proud of that. But they never mentioned that at any stage of the onboarding process. So users questioned why they should store their sensitive documents here. Furthermore, users wanted to know what would happen if the system got hacked. They wanted to know if there was insurance in place for those situations.
- How do I use ZokuVault? ZokuVault is a powerful tool. It has many features that could make users’ lives easier and more organized. Unfortunately, the product relied on a 4 minute video to educate new users. That was a major point of concern because of the possibility of users skipping that video. Our testing highlighted that concern when all 7 of the users opted not to watch the video when given the choice.
- Who has access to my vault? Another major point of concern for users was the verbiage used in the onboarding process. The product used the term “share” and “contact” without providing proper context. So users felt like they were sharing their entire vault with an advisor, and that didn’t sit well with them. One user even mentioned, “I wouldn’t mind having my accountant on this, but in terms of my financial advisors and brokers, I wouldn’t want to have them on this because my financial advisors are the ones who manage my investments, and they don’t need to see my will.” It wasn’t clear to users who had access to their vault, or that they were still in charge of their vault.
“I don’t know anything about ZokuVault’s security profile, and what they’re trying to do for security… what are the measures they’re taking for security?”
Narrowing Our Scope
Our research uncovered ZokuVault’s many pain points. And as much as we wanted to solve all it’s issues, it was not feasible. Our time constraint meant that we only had 2 weeks to conceptualize our solution then prototype and test it. Through hours of dialogue, we decided that we’d be able to create a solution for 4 out of the 5 pain points. Unfortunately, Why should I use this for my clients, required us to interview more estate lawyers and advisors. And the B2B side of ZokuVault was not ready for us to delve into.
We decided that the best approach would be to give users a purpose for using ZokuVault.
After we confirmed our team’s direction with our creative director, we began to lay the foundation of our solution. First, we had to determine who it was we were designing for. My team and I decided that the best approach to this would be to create a persona based off ZokuVault’s target demographic. So based off that and our findings, we created Bill P.
The What and How to Our Solution
Our problem statement streamlined our challenge and gave us a more cohesive direction. That was important because we wanted to create a solution that would touch on different pain points:
Our problem statement pointed to a solution that gave ZokuVault a purpose for its users. It wasn’t enough for us to know what we were designing though. We also needed to have a set of principles to guide how we designed our solution:
Conceptualizing Our Solution
The direction that we decided to take validated what our clients assumed about their onboarding process. It was in dire need of an iteration. Also, we felt like redesigning it would allow us to solve the problem that we outlined. Although our client’s suggestion made sense at the beginning of our project, we wanted to make sure that it was what our users needed. We were confident in making that decision because we had the necessary research to support it. So we designed three concepts for our solution. Each gave users a single purpose for using ZokuVault: prepare their sensitive documents for an emergency. These were the concepts that my team and I designed.
Wizard Concept based off our principle, Upload and Share with a Purpose, I designed an actionable dashboard. If users were not going to use ZokuVault on a regular basis, I felt that they needed to have a starting point. It would limit how lost they felt whenever they used the product. Each actionable item would also be simple to understand.
Users found the design of the concept to be easy to navigate through. However, some of the copy confused the users. 2/5 of the users were stumped by the term, “Set up inheritance.” They were not sure what that meant. 4/5 of the users found the CTA quickly, which indicated that it was easy to find.
Another feature that I added to my concept was a progress tracker in each process. I based it off our principle, Empowerment Through Direction. It informed users of where they were in the process, and how many steps remained in the flow.
5/5 of our testers found the progress tracker to be both helpful and desirable. Users also preferred this this setup for the flow because it met their mental model. One user mentioned that the optional steps in the flow shouldn’t be a main step. He said that it slightly confused him, which is why I created an iteration between that session and the next one. I highlighted the main steps in bigger boxes and numbered them. I then put the optional steps into smaller, unnumbered boxes.
The first iteration of my progress tracker
The second iteration fixed the confusion of optional steps having the same heirarchy as main steps.
Finally, I created a step in the process where users could request documents from their advisor. This feature clarified an advisor’s role in a user’s vault. By defining their role through simple, clear language, it satiated concerns about what access they had. I kept our principle, Your Vault is Your Space, in mind. Also, if there were certain documents that different advisors had, they’d be able to consolidate it all into ZokuVault.
Unfortunately, this feature failed because ⅘ of the users got lost at this point in the flow. The title, Request Documents from your Advisor, of step 3.0 was what threw them off. They were not sure what requesting documents was for. 4 of the users also thought that steps 3.1 and 3.0 should be reversed. Once they got to the part of adding an advisor, they were confused as to what the flow was about.
Users were unsure why documents were requested before an advisor was added.
Zoku-Drive Concept For this concept, my teammate decided to rework the structure of the dashboard into 2 main folders. “My vault” was private where only the user can see it. “Shared with,” was where the user could make a folder for his or her advisor, and put documents in it. The goal of this was to ease any confusion and concerns users had over privacy
The 4 users who currently use a cloud storage service found this to be familiar and easier to learn. 5 out of 5 users immediately understood that “My Vault” was private, and they found that to be reassuring.
This concept also enabled users to add emergency access to their vault. If something were to happen to them, their loved ones would gain access to all the documents inside of it. This gave ZokuVault a specific purpose for users. When we tested this feature, this was the feedback we got:
- 4 out of 5 users immediately saw the value in providing a trusted family member with access to their account.
- 2 out of 5 users mentioned the “add custom message” feature as something they would use.
- 4 out of 5 users were confused by the “wait time” feature.
- 5 out of 5 users said they would hesitate to put in anyone’s email address without knowing exactly how that information would be used
My teammate also experimented with the sign up flow. Users signed up by submitting their name, email, and password. After that, there would be a guided walkthrough in the dashboard. My teammate wanted to address the How do I use ZokuVault pain point. Instead of relying on a 4 minute video, each important element of the interface was explained to the user. That solved the issue of our users feeling lost in the dashboard. In testing, this is what users mentioned about this feature:
- 4 out of 5 users appreciated the detailed explanation of why they would would need to upload this document.
- “Power Users” appreciated the dashboard first approach. Going from explaining features to to prompting users to complete a task was confusing.
- 5 out 5 users did not understand where they were in the process and what they still had left to do.
My teammate wanted to get users into the product as soon as possible. He also wanted to provide them with context and help them understand the why behind everything they do in ZokuVault.
He also created a folder-based desktop application. Most of our users who were transitioning from paper to technology still retained old habits. One common habit amongst users was how they still organized their files into folders. And this feature aimed to mimic that mental model. In testing, this is how this feature fared:
- 4 out of 5 users said they would probably use a folder on their desktop more frequently than the web version.
- 3 out of 5 users were not clear on what this “app” does and how it works
- 2 out of 5 users said they would only download it after they had used the web version
- 1 out of 5 users expressed concerns over security
The goal of this feature was to make ZokuVault work around the user instead of asking users to change the way they work for ZokuVault.
Notes for Successor Concept my teammate took elements from the designs the chief designer of ZokuVault made and repurposed it. He stated that some of the elements of designs were valid, and users would find it aesthetically pleasing. However, he repackaged it because it didn’t give users a purpose. For his concept, he stuck to the main theme of our solution, but he added a new feature.
It fared well during testiing. The language of the prototype was very relatable to 4/5 of the users. The beginning section of the flow gave users “confidence” about where they were in the process. Users found that the picture icons were helpful communication tools.
Users need icon options for whenever they want to begin a task. It allowed users to think less, and quickly identify what step to take since it relied heavily on visuals.
My teammate also created a feature that allowed users to leave digital notes on important documents. The notes could be anything from instructions on certain sections of a will, to random notes left for loved ones. It’d then be accessible by the current or future successor that the user was setting the vault up for.
In testing, we learned 3/5 users liked the idea of leaving personal notes for their potential successor. However, they uncomfortable with leaving information on very important documents.
Users could leave notes for their loved ones on important documents. This feature was created to remind users that they had a ZokuVault account for a reason, which was to ensure that their family would be safe in an emergency.
Users enjoyed the guided walkthrough. Unfortunately, the digital notes on documents left users confused.
Copywriting, the Key to Our Solution
A prototype would not solve ZokuVault’s issues if it didn’t have the right written content. We wanted to give users a reason and purpose for everything they did on ZokuVault. Each document that we recommended to upload had to have a reason why it was critical. That would foster an atmosphere of trust because users would see that each document was thoughtfully included in the list. Also, with an older audience, the language used had to be black and white. It was a problem that the original flow of ZokuVault had.
Another element of our copy we had to keep in mind was the tone. In both the wizard and zoku-drive concept, the language used was too straightforward and technical. To simplify and keep the language clear, we ignored the human factor of the product. I was surprised when that was pointed out during our testing sessions. Users liked the notes for successors concept because the language used was friendly and welcoming.
We also had to decide what parts from each concept we would take. Because we were going to be doing a flow that involved numerous steps, we decided to use the progress tracker that I had. It was also a feature of my concept that resonated the most with users. It was familiar, informative, and unthreatening. Another aspect of my concept that we wanted to implement was how each step in the process had its own screen. Users only had to conduct one action and make one decision per step. I didn’t want to overwhelm users who weren’t used to using technology. I wanted to empower them by allowing them to make easy choices.
Besides the copy used in the notes for successors concept, we also decided to take the picture/icon design for buttons. It was not only more aesthetically pleasing, but it also enabled users to read the answers better. By doing that, it invariably made decision making quicker.
We also decided that the guided walkthrough feature should be included in our final prototype. It was an apt way to help new users navigate through the application. We also decided that the separate folders feature should be in our final solution. Users were concerned with who had access to their vault. So it was nonsensical to compartmentalize a vault to decrease security concerns. Finally, we decided to include the emergency access step in our final prototype as well. It correlated to our solution of setting up ZokuVault in case of an emergency.
For our convergence, we wanted to focus on the guided walkthrough, the progress tracker, and writing copy.
Balancing Research and Client Wants
Our tests revealed key insights that we knew our clients would appreciate. Furthermore, we were confident that the solution we designed was strong. It both addressed our problem and stayed within the bounds of our principles. When we we met with our clients, though, we ran across roadblocks that stemmed from their concerns.
- Partitioning a user’s vault conflicted with ZokuVault’s business plan. Our clients told us how the vault was primarily B2B. The B2C side was not a substantial element of the product itself. Most of the users that would be using ZokVault would be coming from advisors’ clients. If the vault was going to be partitioned, it would belittle an advisor’s role because of how the product was repurposed as more B2C.
- Our clients were wary that ZokuVault would be too different of a product by applying our iteration. The way we designed our solution framed ZokuVault as a one time setup, that required the user to interact with it only before his or her demise. But our clients were adamant about it being a product that users could go back to on a consistent basis. Even though our research showed that users did not need to go back to it often.
- We didn’t clarify whether the web application was responsive at the start of the project. So when our clients saw our concepts, they were concerned. They were particularly curious how we would implement the progress tracker in mobile form.
Balancing Research and Client Wants
The first order of business was to shift the focus of our product to incorporate what our clients wanted. We were still confident in our research, and wanted to stay true to it. So we made the purpose of using ZokuVault more current. We also decided that our users needed to have their documents in one secure place so that:
- Their advisors/lawyers can retrieve important information to better serve them
- They can organize their own information and access it whenever they need to.
- The person they trust the most is more prepared in case they’re gone.
- They and their family members can look through important documents together at any time.
We used the whiteboard to quickly map out our new flow after we pivoted.
Balancing Research and Client Wants
Next, we eliminated separate folders. We decided to rely on copy to clarify the role of an advisor in a person’s vault. Through simple, friendly language we emulated a sense of security that the separate folders procured.
We also researched what mobile patterns we to use for our progress tracker. We wanted to have the title of each step in the each tab to stay true to our design principle. Unfortunately, that wasn’t feasible with mobile. So sacrificed the titles when the screen shrunk down to mobile.
Bringing Our Solution to Life
I had one day to create a working prototype, and our users needed to grasp the concept within 4 steps. The one benefit of reducing the amount of steps was that it allowed me to create another variation of our prototype. It benefited us because we were unsure what the best structure of our flow was. We originally designed our flow to let users make one choice at a time. And that decreased the amount of decisions they had to make. We were worried though that by taking that route, we increased the amount of steps that users took. To sort our conundrum out, I created a prototype that allowed users to choose what documents they currently had and upload it all at once. We then decided to A/B test our flow to see if users preferred to make less decisions or have less steps
When we began our testing, I was curious to see which design would fare better. Before we got to testing that, however, we had a general section to navigate through.
Our users were still wary of putting their important documents into ZokuVault. Hackers were a major roadblock for them to trust an online vault. But they felt more assured with this prototype than they did with the original flow because of the additional information.
Users liked how we led with a question. They felt it encouraged participation, and it made their decision making more natural.
We had positive reactions to this screen. Users claimed that they felt more prepared when setting up their vault for a loved one. They also liked how it didn’t force them to think about what to put in their vault. Users questioned why they had to put all the documents in the list, so they were happy when they saw that each document’s purpose was included.
The results of this page was a mix. Some users were unsure why a message had to be sent to their significant other. A user also suggested that requiring a death certificate to be seen could be another added layer of security and assurance.
Our A/B testing revealed that users preferred the single choice over the multiple choice prototype. The main reason was they were confused by the action of having to choose a document to upload. They pointed out that they thought all the given documents had to be uploaded because that’s what was mentioned in a previous screen. Users responded better to the single choice prototype because they had to think less. It also gave them a better sense of what to do because it showed the big picture.
Testing showed that prototype B was successful. So we decided that it would be the design that we’d present to our clients. We also built a screenflow for them, to illustrate the information architecture of our project.
Our Solution In Action
Although our full design wasn’t adopted, our clients used the screens that covered security, advisors, and giving users a purpose. These were screens we advocated for because they were critical in addressing users’ pain points.
Before we worked with ZokuVault, they didn’t have a step that explained their security capabilities. It ended up being a roadblock for users who wanted to know why they should trust them with their documents.
Our wireframe for the security page.
ZokuVault's new design.
The step of entering your phone number in the process was a pain point for users. We didn’t create a screen for this, but our users told us how this was a frustration for them. They were confused with the entry, and they were not sure if their action was successful. They needed a confirmation screen to ensure that they would not get lost. Users were also thrown off by having the phone number field in close proximity to the code field. They would enter their phone number in the code section, or vice versa. So we relayed that information to our clients.
ZokuVault's old phone sign up flow.
Our clients updated this step after hearing of their users' frustration.
Our research showed users were concerned with who had access to our vault. The old step on the right gave the option, I want to complete my own vault and share it with others. With our research backed recommendation, our clients eliminated the confusion and simplified it to I want to complete my own vault.
One of the main issues we uncovered through research was how users got confused with who had access to their vaults.
After presenting our research, our clients changed the language of their process and removed the word sharing from their flow.
Users needed to be given a purpose for using ZokuVault, and that’s what this particular step was for. It decreased their pain point of feeling lost within ZokuVault.
Our wireframe for giving users a purpose
Our solution applied to ZokuVault's current flow
In the previous iteration of ZokuVault, users were not informed on why they should add a contact. Our research showed that users should always be made aware of why they make a choice. That fostered a sense of security, and it empowered users.
The old iteration of ZokuVault
Our wireframe for adding a co-owner
ZokuVault applying our solution
In the previous iteration, ZokuVault users were not aware of the type of documents that they could upload. Our research showed that users wanted to know what they needed for their successors. It was reassuring for them. Our research also showed that icons were more desirable than buttons.
Our wireframe for selecting a document
ZokuVault applying our solution
Our research showed that users showed concern when it came to adding an advisor. They were unsure of what they had access to in the vault, or they thought that they had access to the complete vault. By adding context to advisors, and giving them a purpose in the vault, the issue was resolved.
ZokuVault was one of the most challenging, and gratifying, experiences of my life. The time constraint that this project had, pushed me to become a better designer. The growth that I saw myself make was a pleasant surprise. I was also expecting for it to be a challenge that would only teach me better time management. So I was not expecting it to teach me all that I learned.
First, and most important, I noticed how I was no longer married to my process. It was still an integral part of the project, but it didn’t limit me. I was focused in on the user, and their problems. I wasn’t worried about what steps we should take, nor if we should use all our tools. Rather, we took the tools that was necessary, and applied it. That enabled us to move fast throughout the project. I was able to create, test, and iterate a concept in a day. I was also able to create two prototypes in Axure in two days. It was in this project that I noticed how effective the Agile Method is.
Second, I noticed how I improved my presentation skills as the project moved on. In our first client presentation, I was unable to speak much. Instead, I relied on my teammates to do most of the presenting. My creative director addressed that, and told me that I had to give more input. It was a team effort, and my role in the team was important. I took that to heart, and I focused on improving that weakness. In our final presentation, my creative director told me how proud she was of how I presented. She said that my improvement was noticeable, and that it was my strongest presentation yet.
Besides growing in many areas in this project, I also enjoyed it because of how challenging it was. I’ve had experience with dealing with clients from my previous job, but they did not give a lot of push back. Our ZokuVault stakeholders were the complete opposite (in a good way). They challenged our decisions when it interfered with their business plan. It was a welcome challenge though. My team and I learned how to tread the fine line between appeasing our clients and staying true to our research. At the end of the project, our clients were pleased with what we came up with.
Finally, I loved this project because of how our designs were implemented a few weeks after our final presentation. It was delightful to see how our designs helped a startup move their product forward. ZokuVault was also able to release their B2B side after our work. So it was refreshing to know that our hard work paid off, especially since I was working until 2 AM everyday in the final week of our project.