Deciphering online transfers: First-timers remote Design Sprint

Edith Davina Smith
Nov 6 · 12 min read

On our second day of the UX/UI online Master in NEOLAND, five of us from different points of Spain got together on a video call to dive into our first ever Design Sprint.

The idea behind this crash-course was to immerse us into the skin of a UX designer in our second class, giving us a taste for what was to come. With a short introduction to the theory behind Jake Knapp’s Design Sprint we dove straight into the challenge.

Before starting, just a quick note: I’m going to assume that you’ve already heard of Design Sprints and spare you all the details, focusing more on how our experience -or lack of- and situation impacted this sprint. If you’d like to read up on the theory before continuing you can have a read here.

That said, there were several challenges that our teacher made us were aware of from the start:

  1. We’d all only just met.
  2. Some of the team didn’t have any experience in design.
  3. We were not going to be in the same room at any point of the sprint.
  4. We only had 3 days instead of the normal 5 as it is a weekend online course.

Even though this sounded intimidating to us, he reassured us that it would make the process more interesting and for sure affect the results in a positive way to have people from different backgrounds with unique points of view. Here’s a peek at the overall planning before we start in case you’re curious.

Day 1 — Understanding

The first step in the process was to establish the challenge ahead. Our teacher and facilitator suggested that we think of something we use in everyday life that we feel is unnecessarily complicated and immediately online banking came to mind. We all agreed that at some point we’d struggled to complete a task through our online bank ourselves, or had someone in our life that could benefit from simplifying the process. To focus the process on something more specific, we decided to centre this design sprint on redesigning an online transfer for those who struggle with the use of new technology.

Given we weren’t in the same room, our teacher decided to recreate the post-it ridden wall present in most Design Sprints with the online whiteboard tool Miro. There we began by pinning our main goal on a big yellow post it to make sure we all keep it in mind while we move through the process.

Once the goal was clear we were instructed to create a User Map, this would be used to make sure we were seeing the problem from the user’s point of view and creating solutions to help them and not ourselves. In my personal case, the biggest issue I’ve had with online transfers is when my father has had to transfer to either my siblings or myself as we all live abroad or away from home. In most cases I’d end up doing the transfers myself, after my frustrated father hadn’t managed to click on the right buttons while I coached him through it over the phone. I decided to create a user with this specific problem as I was sure there must be an easier way to do this.

With a specific problem and a specific user in mind, we moved on to establish Sprint Questions on more particular aspects of the transfer process, to see if we could find innovative solutions for each issue that came up. We were each assigned a post-it color and took 15 minutes to think of as many questions as we could, then we read them out loud, discarded the similar ones and pinned the rest of them on our whiteboard.

Many interesting ideas came up here of different ways that could facilitate or add to the experience of an online transfer, such as: Will the user be able to receive immediate help during the process? or Will the user be able to carry out the transfer without typing in the account number? From all these ideas it became clear that it was very important for the user to feel safe and trust the system, that the user needs to feel like they’re being assisted by a helper throughout the process, and finally that we needed to remove the clunky feel of an online bank and turn it into a more accessible experience, changing up both the language and the interface.

Once we’d pinned our many sprint questions we transformed them into How Might We questions in order to move to a problem-solving perspective. From here we were each given two votes to place on the ideas we’d most like to pursue throughout this Design Sprint, even though the facilitator would then have the final word on which approach would make most sense. Once we’d voted we found that there were very divided opinions and given there wasn’t a clear majority, in order to proceed the facilitator picked out two different approaches, split the team into two and each of us then picked the one that most resonated with us.

By the end of the first day we’d each established the objective of the sprint so we could dive right into prototyping come the second day. In my case, I chose to go with finding a way to allow the user to send/receive transfer requests from/to other contacts. Taking into account my user story it seemed to be the most logical approach, as if the son could request the transfer from his mother and she only had to accept, the process would become much easier for everyone involved.

To prepare for the second day we were also told to look for inspiration in other websites and applications to bring to class and inspire us for the upcoming wireframes.

Day 2 — Problem solving

To start up the day we all took turns sharing the inspiration we’d found in different existent websites and/or applications. This is normally referred to as Lightening Demos and the idea is to quickly run through everyones findings on the team in order to draw ideas for the next step.

Once we’d all shared and noted down any inspiration we’d found, our teacher suggested that to start up the prototype process we could use a technique often used in Design Sprints: Crazy Eight but in our case we decided to do a Crazy Four as we were tight for time. This consists in folding a piece of paper into eight (or four in our case) and using each rectangle as a screen, with one minute to spend on each one to create a quick sketch. Given this Design Sprint was remote, I decided it made more sense to use my iPad to sketch each one out to make it easier to share them later with my team.

My idea at this point in the sprint was to create an easy step by step app, where the user would receive a notification for a transfer request and would then have to click in, insert some sort of code to make sure the system was secure and then receive a confirmation of completion.

After having created these rough sketches, we continued to work on our idea, producing a more elaborate wireframe that should be able to portray our idea without the need for any extra explanation.

To make sure this was the case, we all put our wireframes in common and the teacher proceeded to go through the steps of each one, narrating what he understood from the minimalistic wireframes we’d created. At this point everyone had established their main idea, more screens would definitely be needed for the final prototype but the basic functionality was clear.

Before starting up the prototype I decided to elaborate the idea a bit more in wireframe form to make sure I wasn’t missing anything obvious. In this stage I decided to add a screen that allows you to choose from which bank account you’d like to do the transfer and also a final screen where the person you transfer to has the possibility of sending you a thank you message. This last idea came from someone on my teams wireframe and I decided to implement it as it added to the security and familiarity I was looking to achieve for my user, adding an extra layer of confirmation to erase any doubts.

Having come this far, it was time to start working on creating a more visual prototype that could actually be used to get feedback from potential clients on if they believe this solution would work for them. To do this, we had an express class on the basics of Figma and dived right in.

Easybank — We make it easy

Taking into account my user story, I knew I had to create an app that would make the user feel safe, understood and at ease while carrying out a transfer. I wanted to make sure the experience would be equivalent to going to a bank to do it in person, but easier as you could do it from the comfort of your home. To ensure all of these ideals were transmitted to the client, I decided to use a very simple interface, with accessible language, warm colours and a familiar tone when addressing the user. Here’s what I came up with:

As you can see in the prototype, the idea from the wireframe remained the same, only with some additional screens to facilitate the usage and add some extra functionalities to the app as a whole. Here’s a step by step of how the app would work:

The user would receive a notification that they could choose to be reminded of later or to access app and see more details. If they chose to access the app they would be asked for their ID and password to be able to access, this is a screen I hadn’t included in the initial design but ended up considering it was necessary given it is bank related and extra security is essential.

Once the user had logged in they would be able to see the request, in this case a request to transfer 200€, and again choose to accept or reject. In the case that they choose to accept they would be taken to a screen where they would choose which account they’d like to use for the transfer, and after that would have to insert a 4 letter randomly generated password that would be sent to their phone via sms to add an extra layer of security.

In order to make sure the user has the security of everything having worked out, the app will send them a notification to confirm that the transfer has worked, but also the person who requested the transfer will be able to send their own personalised message.

Finally, a these are a few extra screens I added in to the prototype to make it feel more realistic and give it a certain depth for the user when testing. The first screen is for if the user decides to decline the transfer request, and it also gives you the option to undo that choice in case it was accidental. The second screen is a menu accessed from the hamburger icon in the top right corner on the screens. The third screen is a sort of inbox where any requests that haven’t been completed yet would stay for a certain amount of time for the user to access.

So now we’d finally given our original problem a solution and that solution an interface that can be used to test it out with other potential users. This would be the final step in our Sprint, to make sure our solution actually made sense for the people that could find themselves using it. If it was a success we could then take whatever feedback we got from the testers, apply any necessary changes and launch the idea.

Day 3 — Testing

To make sure we were getting reliable feedback, we were told to make sure to test our prototypes with at least 5 different users as less wouldn’t give us enough variety of opinions. I managed to find 5 people willing to test out the Easybank App, established a series of actions I wanted to make sure they could accomplish efficiently and asked them to rate each experience as easy, hard or mark with a X if it wasn’t possible. Here’s the results of the testing:

In general I was very happy with the results, as it became apparent that by using clear language and step by step instructions everyone had managed to fulfil the tasks I’d asked of them with no issues. The only part some people had difficulty with was finding the menu, I discovered that this was because some people that don’t use technology as much as myself don’t identify the hamburger icon as an access to the menu and were instead looking for a button that read menu somewhere throughout the app. Even though this icon is generally recognised, given this app was supposed to be created for people that didn’t have a broad knowledge of technology, it would be worth considering changing the menu to something more obvious to accommodate their needs.

Conclusions

For something as complex as banking, it’s hard to find innovative solutions without losing the formality and security of a traditional bank. This added complexity to the sprint as if we continued to test with more users, I’m sure we’d find people that were apprehensive to the idea of having their bank information in an application on their phone. This just comes to say that you’ll never find a solution that works for everyone, but in the case of the user story established on day 1, I do believe the final solution would solve their specific problem.

Diving straight into a design sprint on the first day of the course was both challenging and interesting, I’m sure as we move on in the course and continue to expand our knowledge on both UX and UI we’ll look back on this first sprint and clearly see where our experience lacked. It was interesting to attempt to create an app from scratch with no pre-established ideas, only through following the simple steps that our teacher and facilitator gave us to follow. I would be curious to come back to this same issue in a years time and see if I still would’ve resolved it in the same manner and analyse how my new experience and knowledge has impacted my problem solving.

In the end, I think Design Sprints are a very good resource to use when you don’t have much time or need to test out many different approaches without going too deep into the process. The start was confusing as we weren’t entirely sure how each step was going to lead us to this final prototype, but if you stick to the steps it leads you to a final conclusion that could really help in your project. That said it was very frustrating for me at some points to not be able to go back and reevaluate decisions I’d made in previous steps, but at the same time I appreciate the philosophy behind it: better done than perfect.

Edith Davina Smith

Written by

Bilingual designer based in Spain

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade