Project #1: Deki and the Mobile App (in-depth case study)

Anna Skoulikari
Anna Skoulikari
Published in
16 min readJan 31, 2018

This is a case study for our first UX design project as Red Academy trainees.

Main intended audience: UX professionals or UX hiring managers

Client:

Deki, a Bristol-based microfinance charity, that allows people to directly lend money to entrepreneurs in developing countries. These entrepreneurs use the funds to start their own businesses and gradually pay back the loan over the course of about 12 months.

Team: Anna Skoulikari, Will Duncan, Elena Gioti

Base: WeWork Aldwych House

Duration: 3 weeks

Working process:

We adopted the Agile philosophy and implemented it through elements of the scrum methodology. We would hold a scrum every morning at 9:15 before classes started covering:

  • What we worked on the day before
  • What went well
  • What didn’t go well
  • What we were going to work on today
  • Blockers

Project Focus: The focus of the project was learning to design a mobile app.

Overview: This was our first project and it was a great learning experience. Throughout the case study I have included various annotations that provide more information and insight on our journey through this project.

Deliverables and contents list:

  • Client meeting
  • Business Goals
  • Organisational Research (led by Elena)
  • Domain Research (led by Elena)
  • Interviews (led by Anna)

Client meeting

This was an in-person meeting with the client in which we asked on a lot questions on:

  • the background of Deki, how it got started and how it has developed
  • the brief, mainly focusing on some goals that the client had outlined

Business Goals

From our client meeting, we were able to narrow down on the two main business goals:

Business Goal 1: Increase the annual amount lent from £400,000 (2016–2017) to £700,000 (2017–2018).

Business Goal 2: Increase monthly engagement from 600 people lending per month (2016–2017) to 1,000 people lending per month (2017–2018).

Business goals

We would continuously refer back to these business goals in order to make sure our app features were fulfilling them.

Organizational Research

  1. First we had to understand the Deki microfinance process.
Deki lending process

An important point about the above however is that there is no direct communication between the lender and the entrepreneur. There are field partners (other NGOs) in the 5 African countries that Deki operates in that take care of all the administration .

Explanation of Field Partners by Deki

2. Next we had a preliminary look at the online user experience through the site. This would become a lot more nuanced after we had done some of our user interviews.

Deki Website Screens

In this part of the process we found out how useful a project wall was to visually represent our design process.

Domain Research

The domain research looked at other organisations that do similar work to that of Deki. Three of the main organisations studied were: Kiva, Zidisha and Lend with Care.

Each of them had something that differentiated them slightly from Deki.

  1. Kiva
  • Different: Kiva is a much larger organisation operating in 82 countries while Deki operates in 9 countries. And it is based in the USA while Deki is based the UK (cosy little Bristol to be exact).
  • App: Kiva officially does have an app however when one goes on the app store they are unable to actually find it. Therefore we assume it has been discontinued.

2. Zidisha

  • Different: Zidisha, unlike the other micro-finance organisation allows for direct communication between the borrower and the lender. Its website is a person-to-person lending platform, rather than utilising field partners.
  • App: Zidisha only has an Android app.

3. Lendwithcare

  • Different: Lendwithcare is actually a micro-finance website run by the larger development charity CARE International UK. Therefore it is not a completely separate organisation.
  • App: Lendwithcare does not have an app.

Interviews

Our user research was mainly based on in-depth interviews with Deki lenders that were based in London.

Before the interview

We designed the interviewee experience by organising our questions into three parts.

  • Part 1 Appetizer: These were warm-up questions which focused on getting to know the interviewee and their general charitable activities.
  • Part 2 Main meal: This was the meat of the interviewee, it focused on the interviewee’s relationship and interaction with Deki.
  • Part 3 Dessert: Finally to finish the interview off we discussed the interviewee’s relationship and interaction with digital devices, apps and websites.

When designing the interview questions we made sure to avoid asking leading questions. The question starter “Tell me…” became quite the favourite.

“Tell me about how you decide how much to lend to Deki.”

During the interview

Small talk: From the moment of meeting the interviewee at the entrance of the building to the moment the first question was asked, we made sure to put them at ease and make them feel comfortable with small talk. This was also a great way to just start getting to know the people we were talking to.

Website exercise: Along with asking questions we also gave the interviewees the option to walk us through their experience of using the Deki website. We had a laptop available that they could log into.

“Can you walk me through the experience of lending with Deki?”

This exercise allowed us to make observations that would otherwise have been a lot harder to notice if the interview has not been done in person or if they tried to provide a solely oral explanation of their experience of the website.

Phone exercise: When reaching the third section of questions, the interviewees were encouraged (although some did it on their own) to pull out their phones to walk us through some of the main apps they use. And more generally how they use their phone.

“Tell me about other apps and websites that you use.”

Once again this was a really great exercise which helped the interviewees to communicate their thoughts and preferences much more clearly.

End of interview

Audio recordings: It was helpful for the team to have a listen to some of the interviews in order for them to feel connected to the interview subjects and invested in the design.

Transcripts: Writing transcripts of the interviews allowed us to refer back to them over and over again throughout the project and it also allowed us to pull out extremely important quotes that would help clarify points and communicate the user’s wants and needs.

Challenge

Recruiting interview participants was a challenge we faced as we were London-based and the client was Bristol-based.

Finally, with our main research phase done, we progressed on to planning.

Deliverables and contents list:

  • Affinity diagram (led by Will)
  • User goals (led by Anna)
  • User persona
  • Feature list
  • Scenario
  • Userflow (led by Will)

Affinity Diagram

The first step in our planning process was to organise our qualitative data and draw out our key insights from it using an affinity diagram. From these key insights we were able to get acquainted with our user persona (you’ll get to meed Amanda in a second as well) and most importantly draw out what her user goals were.

Affinity diagram

The affinity diagram exercise was extremely useful but at the same time we learnt that it is often helpful to define a scope for the affinity diagram.

User Persona

Once we gathered all our qualitative data from our research phase we were able to start clarifying who it was we were designing for: meet Amanda.

  1. Getting to know Amanda we wanted to make sure we understood her social media habits. We found out that she really didn’t use social media much.

“Yeah, I don’t use social media much, I think that it’s more for the younger generation.”

2. We also picked up on some of her key frustrations regarding the Deki service.

“I don’t get much information during the lending process and at the end. That’s just like a black hole at the moment.”

3. Lastly we paid close attention to her interactions with other apps in order to understand what aspects of them she enjoyed and which aspects frustrated her. This will be circled back to in design research!

“What I like in an app is functionality but also a nice design.”

User Goals

The most important part of understanding Amanda however was understanding what her underlying goals were. There were 5 key user goals that arose from our research:

User persona (with user goals)

Feature List

Once we had gotten to know Amanda, and her goals, we were ready to come up with features for our app that would satisfy them. We narrowed it down to 4 key features (we will revisit them later on in more depth):

  1. Updates from entrepreneurs during the loan process
  2. Visual overview of current loans
  3. Visual overview of all lending activity
  4. Easy top-up and check out processes

Scenario

With the feature list locked down, we had to be clear as to how our Amanda would begin her interaction with the app and so we drafted a scenario

We made sure to clarify the context in which Amanda would find herself engaging with the app. As well as specifying how that engagement would be initially prompted. Lastly, we pointed out what her goals would be throughout her journey through the app.

User Flow

Finally with a clear beginning to the user interaction it was time to cook up the middle: the user flow (created by Elena).

User flow made by Will

The user flow shows the user actions (rectangles), the screens (rectangles with side lines) and the decision points (diamonds) of the journey through the app.

The user flow would also undergo multiple iterations as:

  • We received more information from continued user research
  • We tested the prototype with users

With a clear idea of who Amanda was and what she would want to do on the Deki app, it was time to start designing the how.

Deliverables and contents list:

  • Design Research and Paper Sketches (led by Anna)
  • Paper Prototype (led by Anna)
  • Testing Paper Sketches
  • Digital Wireframes (led by Will)
  • Testing Digital Wireframes

Design Research and Paper Sketches

In order to create the initial prototype of our app we chose paper as our weapon of choice. The design research consisted of three main elements:

  • First of all, looking at the existing site and its information architecture.
  • Second, exploring features of the apps that users mentioned they enjoyed.
  • And lastly, looking at general usability features.
  1. Deki website

Lenders expressed the fact that they liked the account dashboard because it gave them a good overview of their activity. However, they also pointed out that they would appreciate a more visual representation of some other information.

2. User’s App Preferences

Monzo was one of the apps that many of the users enjoyed using. They pointed out that it had a very visually accessible way of presenting information. We attempted incorporating this in our design.

Atom Bank was another finance app that got a lot of attention during our user research. Users appreciated its simplicity and ease of use.

3. Usability

Finally through our research we found out that users enjoyed easy interactions on their phones. One app that came up was BBC iPlayer which had a rotating wheel for choosing a radio station.

In designing how users would select the amount they would like to lend, we drew inspiration from the alarm setting tool on the iPhone. We found this an easy interaction that users would appreciate.

Paper Prototype

Feel free to click around the very first prototype!

Testing Paper Sketches

With consent forms signed, users in laptop hug position and cameras ready, we recounted our scenario and put our paper prototype to the test.

Laptop Hug position allows for video recording users’ actions

Users were ordered to complete a couple tasks (three to be exact) as we observed their actions.

The key insights from the user tests were taken into account in the next iteration of the prototype which was digital.

For example, one key insight from the user tests was that users often sought for a bottom navigation when it was not there.

Digital prototype and testing

Once the full digital prototype was ready, it was time to get back to testing once more!

One of the key insights this time around was that the account screen caused a lot of confusion. Users found it difficult to navigate. We decided to simplify it and to prioritise the most important user actions.

Final Digital Prototype

Feel free to have another click around!

Conclusion: Did we meet our user and business goals?

Now, we quickly circle back to see how our four main features fulfilled both our user goals and our business goals.

Recap: Business Goals

Business Goal 1: Increase monthly engagement from 600 people lending per month (2016–2017) to 1,000 people lending per month (2017–2018).

Business Goal 2: Increase the annual amount lent from £400,000 (2016–2017) to £700,000 (2017–2018).

Recap: User Goals

Feature 1: Updates from entrepreneurs during the loan process

User goal 2: By getting more frequent updates during the loan process this allows lenders to trust that their loan is being put to good use.

User goal 3: Updates also allow lenders to keep track of the progress of their loan throughout the whole procedure.

User goal 4: The updates about the entrepreneurs progress foster a much more personal touch to the entire lending experience.

Business goal 1: By providing updates throughout the lending process the app will encourage lenders to log in to their account more often and thereby increase the likelihood of more loans per month.

Feature 2: Visual overview of current loans

User goal 1: By presenting the account information in a similar way to other financial investments the app communicates how this is a loan and not a handout. Thereby reiterating how this is a way to help someone help themselves.

User goal 2: By having a visual way of viewing all the information on their current loans, lenders can follow the progress of their loan more easily and thereby trust that their money is making a difference.

User goal 3: The visual representation of their loans is an easier way to understand the different information available in lenders’ accounts.

Business goal 1: The visual overview of current loans provides a more engaging interaction with the loan process which will encourage more lenders to make loans and for them to do it more often.

Feature 3: Visual overview of all lending activity

User goal 2: Once again by visually viewing the accumulation of funds in a lenders’ account and the use of these funds, they are able to trust that their money is making a positive change in the entrepreneurs’ lives.

User goal 5: By having an overview of all past lending activity, lenders can feel like they are more in control and that they have more information from which to make informed decisions about their next loan.

Business goal 1: With similar logic as above because of the more interesting presentation of the loan information lenders will find it much more enjoyable to make loans and follow their progress.

Business goal 2: Due to the visual representation of how the total amount of money in the account is affected by topping up one’s account and making loans this will encourage lenders to make even bigger loans in order to see this graph continue increasing at a faster pace.

Feature 4: Easy top-up and check out processes

User goal 5: The easier the top up and checkout process, the easier it is for lenders to lend out loan money they get repaid and the easier it is for them to find new entrepreneurs to lend to. This creates an overall efficient service.

Business Goal 1: With a more fluid and easy top up and check out process, the user experience of using the app is more enjoyable and therefore will encourage more users to make more loans and more often.

And with the reassurance that we had to a large extent fulfilled the user and business goals we neared the ending of our project! 🙏

Presentation (created by me)

But before we did the presentation we made sure to do some sneaky reconnaisance work and prepared a little surprise for the client, Alex who would have made his way all the way from Bristol!

Retrospective

Finally, in order to bring closure to the project and to extract maximum learning from it we did a final retrospective.

We used the Sailboat technique.

The sailboat technique (don’t worry we will explain!)

In this technique:

  • Wind: represtened things that worked well
  • Anchor: represented things that didn’t work well
  • Iceberg: represented things to look out for

There were some key insights from our retrospective that we wanted to do differently in our subsequent projects, here are three of them:

Feedback: Throughout the project there were times where individual work needed to be done. After this work was done, the team would feed back about it in order to keep all the members up to date.

This is how it was to work in theory, but in practice there was a lack of communication. The rest of the team would not be fully aware or have processed the work done by another member and this meant that some work was overlooked during the rest of the project.

Important decisions: As a team we decided to make more of an effort to make time for big decisions to be taken all together. This was a particular issue with the design stage of our project.

For example, because we ran out of time a lot of design decisions had to be made on the paper prototype without consulting the rest of the team members.

Project Wall: Despite the fact that we found the project wall was extremely helpful as a visual and physical representation of our mostly digital project. There were many times where we overlooked updating it.

The effects of this oversight were evident when we would often forget to take into account previous research or insights at different stages of our project. We wanted to make more of an effort to keep our project wall more up to date in our next projects.

Time for reflection: I believe that sometimes some exercises were rushed and we didn’t have enough time think a bit more deeply about our insights in order to get more a nuanced perspective.

I wanted to carve out time for reflection in future projects. I thought this could be aided by keeping a journal. This would also allow us to keep a record or the progress through the project and could work as a reference tool later to chart our journey through the project and to work on a case study for the project.

Client’s comments:

“…Anna is focused and articulate. The questions she asked at the kick-off briefing cut through the complicated processes of Deki in a personable way — a very productive session. Whist it turned out to be harder than expected to interview Deki’s users themselves, Anna was able to get to grips with Deki’s model.

Three weeks later, Anna presented her research and designs; in a professional, engaging and confident manner. The marketing persona research that Anna presented gave invaluable insights into Deki’s audience.

Anna’s easy-going and confident style will make her an asset to any company. An easy recommendation from me for any UX design and research work.”

Alex Moreton, Digital Marketing and Communications Manager at Deki

The full review can be found on my Linkedin!

Contact

Hope you have enjoyed this case study and if interested in contacting me, feel free to pop over an email at: annaskoulikari@gmail.com ✉️

Otherwise maybe:

Otherwise check out this video 🎥 where I introduce myself:

Bibliography

--

--

Anna Skoulikari
Anna Skoulikari

Anna Skoulikari teaches Git and recently published a book with O'Reilly titled: Learning Git - A Hands-On and Visual Guide to the Basics of Git