Do’s and dont’s when making an app in one month
You are the designer in a new project, the deadline is closing in for the first version to be finished, there is no clear direction on how the app will be other than provide a holistic overview of the users economy, and the pressure is on to deliver first-class designs, pronto. I’ve been that designer in a recent project, and I’ll share insights, learnings and do’s and dont’s from this one-month-adventure.
When the pandemic hit, we started to see news of people getting into economic trouble. We teamed up with Shortcut and Susanne Håvardstun to create an app to help people control their entire economy.
In the Norwegian market, there are already apps that gather information about your unsecured debt (like Horde) and apps (such as Kredscore, goscore+)that provide you with an economic score based on your credit, taxes, debt and assets. However, none of these gives you a holistic overview of your economy or where you should begin to improve your economy. Why not ask for help from a professional advisor that can help with expensive debt, and implement strategies and tips on how to improve the economy into the app itself?
To help users answer these question we created PNGR. It is supposed to provide you with a holistic overview of your economy and with the possibility to ask for professional help and advice.
Now, let’s move on to the do’s and dont’s.
Make hard decisions
In terms of specifying a concept, I would recommend you to focus on a smaller group of users to focus on their goals and needs. In our case, the group of users were persons who found it challenging to collect the elements of their economy in one place, as that information is widely spread across different apps and systems.
Early on the team found out that we couldn’t spend time on integrations to collect real data. As a result of that decision, we created two personas to be used during the development and in the first version of the app. This made it easier for the design process and the development of the app. One important note while using personas is that they need to be used consistently during the development process because requirements change and so does the needs and goals of the personas.
Conduct user interviews and talk to experts in the field from day one
As we created this app for individuals with financial problems, we interviewed several debt counselling experts to capture their strategies and how they address their clients. One thing that came up was to show them the reality of their economy. That meant showing them how much equity they have in total, and how much they have left each month. During the user interviews, we found that they liked this layout as it gave insights on the whole picture, not bits of the economy. One person highlighted that this overview could help persons who are worried to check their mail if they have letters from creditors claiming money.
One of the challenges was that the design of the core functionality wasn’t ready before the developers had to start developing the app. Time was competing with the iterative process.
Make smart components that are reusable.
One of the findings from the expert interviews was the importance to show the current financial situation. As a result, we wanted to visualize the positive and negative elements with the use of colours in combination with a number that represented the current status of their economy. To visualize the current financial situation the positive elements are always displayed on the left, and the negative elements always on the right. The number provides insights on how much or how little they have in total equity and how much or little they have left each month.
One key takeaway is to make smart reusable components that can easily be adjusted by the developers (designers might experiment with the core concept a lot).
The designers always want more functionality while designing, causing more work for the developers, and ultimately making the first version a little “crafty”. On that note, designers need to ask themselves: how can we meet the needs of our users and how can we reach the desired functionality most easily, for the first version of the app? (Meaning there is no room for “easter eggs” in the first version).
Create clickable prototypes for developers to click through.
As a designer, I found it challenging to communicate with the developers on how transitions, animations and navigation should happen. Luckily, prototyping tools such as Figma, Adobe XD and Sketch all have the possibility to make clickable prototypes that can easily be shared. In our case, we created clickable prototypes in Figma to communicate with developers about the transitions and animations. We also used the clickable prototypes in interviews with the experts. Clickable prototypes create an easier understanding for a developer of how the UX designer wants transitions to happen, and to communicate the concept in interviews.
Designers: learn how to code!
To the designer: if you have no clue on how components are coded in the iOS or the Android system, challenge yourself to learn how to code! When you know how to, then you have more insights when designing components on how much or little time it takes for the developer to actually code it. You can read my take on it when I leaned SwiftUI.
While working on the PNGR-app, my questions to the team sounded something like this: “can we implement this little change, and is it hard to do it and does it cost us much time doing it?” Of course, this is a valid question to ask, but if the designer has some experience developing with, for example, Swift, the designer might have an idea on what is hard to accomplish and what isn’t. As a result, the prototype might be scoped even more when the designer focuses on the core functionality, and removing small specific components, or making them reusable in the design. When the design component is reusable, it will also make it easier for the developers making that smart reusable component.
When creating the reusable component, build it yourself rather than relying on a third-party library. Why? In the “app world”, such libraries can be filled with bugs that could slow down the development process. Trying to debug and fix it can be risky as the library can be deprecated and ultimately remove an important feature in the app. In our case, we focused on using native elements and creating the custom components from scratch to avoid future headaches.
Scope, scope and scope!
As a designer, you need to question the obvious. Do we really need both an Android and iOS app for the first version? If we have the resources to develop for both systems, it doesn’t mean that we should do it. Such decisions are not always on the designer’s table, but it can help to specify a version one. In our case, we developed both an Android and an iOS app of PNGR. However, we found out that we did not need to develop the Android version for version one, as we had no one testing the Android version of the app. If we did question the obvious from the start, we might have decided to develop only for iOS in the first version.
To summarize, I’ve listed up do’s and dont’s when making an app in one month
- Make hard decisions. What is needed to jumpstart the design and development process?
- Conduct user interviews and talk to experts in the field from day one! It will help both the design and development of the app focusing on the important design decisions.
- Make smart components that are reusable. Expect changes and new features that need to be easily implemented.
- Create clickable prototypes for the developers to click through. This creates an easier understanding for a developer of how the UX designer wants transitions to happen, navigation, animations, etc.
- Designers: Learn how to code! When you know the basics, then you have more insights when designing components on how much or little time it takes for the developer to actually code it.
- Scope, scope and scope! You need to question the obvious in general, and especially on a deadline: do we really need both an iOS and Android app for the first version?
