App Price Calculator

MY ROLE

Product Designer – Researcher – visual Designer

ABOUT APSY

Apsy uniquely combines human creativity with AI efficiency to build elegant custom apps at a significantly lower cost compared with low-code or traditional dev shops.

DESCRIPTION

On the Main Apsy website, Users could request Casual Consulting Sessions to build an app. We Needed to Improve the process in order to get more information from users and also make the Session more interesting & understandable for users. we were already documenting features, their complexity and price at this time.

PROBLEM

unclear and never ending sessions with the topic of app building. users having a lot of repetitious questions mostly related to price estimation. also a lot of misunderstandings about the features ‘on the other hand conversions didn’t seem to look as expected.

MAIN GOALS

1 Discover

Interviews

on the next step I prepared the questions(sort of 5wh) of
the target users I wanted to ask to know about their motives.
Then I selected 6 potential users to know what they want to know when requesting a session.

Finally I interviewed via google meet and started with some warm-up questions to break the ice.
then I asked the questions and also asked in the end about
how they would think about an app calculator.

By affinity mapping I grouped users needs
Most of the Users questions could be prioritized like this:

what are the prices?
what are the features?
Do you have any feature suggestion?
what do the features do?
what is the example of an app I am building?
How long will it take?
How can I reduce the price without effecting my goal?
what features do I need for my idea?
do I have any other solutions other than app building?
is app building the best solution for me?
How would it look like?
How much supportive will your team be after making the app?

Also about the online calculator:
They mostly questioned its accuracy and how much it could help there knowledge but were excited generally.

Competitor Analysis

In the first step I needed to know how our direct & indirect competitors approached this issues.

The Competitors could be categorized into these 3 main groups:

App builder websites
websites asking for information before sessions
App Price predictors

The interesting group was the third group. which we had never considered. the more interesting
finding was the online app calculator feature that some websites had and users could interact with.
more research showed that having a calculator on websites could increase conversion rates dramatically!
and it could also improve time users spend on websites.
by knowing this and after sessions with other teams we decided to add this feature as a solution!

as a result I analyzed 4 websites from the third group and one from the first group by SWOT method
I chose this method because I needed to strategize this process.

I also used the data later in the Ideate step to know how better we can categorize features.

Define

Empathy Map

I used empathy maps based on Interviews & research data I had.

How Might We

Next based on the observations I gathered in the Discovery stage of the Design Thinking process We generated “how might we” questions:

How might we create an app cost calculator that is more user-friendly and intuitive than Others?
How might we design an app cost calculator that provides more accurate cost estimates than Others?
How might we differentiate our website flow from competitors by offering additional features or functionality?
How might we simplify the Process to make it more accessible to users who are not familiar with the technical aspects of app development?
How might we ensure that our website is transparent and easy to use, with no hidden fees or charges?
How might we leverage user data to improve the accuracy of estimation and provide personalized recommendations to users?
How might we integrate social proof into our app cost calculator to build trust and credibility with potential customers?
How might we make the New design mobile-friendly and responsive to meet the needs of users who access it on their mobile devices?
How might we create an app cost calculator that integrates seamlessly with other tools and services commonly used in the app development process?
How might we offer support and guidance to users of the website, to help them navigate the complex process of app development?

Moscow Method

in the end of this stage we prioritized what was needed to do with the help of managers. I used the MOSCOW method here:

Ideate

User Flow

This is the first user flow I created with a focus on the cost calculator. at this time we were still not sure about the categories & had to come back later.
one other question was how accessible the estimator should be because we knew that the website will have more important features in the future.
I just made sure that the user could easily navigate to every screen from where ever it is.

Card Sorting

Card sorting was a MUST for the design I had in mind and it was quite challenging. manegment had already priced
the features but they were toooo much! (125!) for any persona.We discussed to put out the unnecessary ones.

Many features were just alternatives of the same subject and after Content Audit I reduced items to 65.
But this number is still slightly higher then a suggested card sorting number
also considering that some users may not know what the labels mean without an explanation; which would also take time.

I have to another important point here:
by the knowledge we had about our persona we chose labels for features and already put out some complex ones. but testing these and coming up to the best mixture is another story.

65 features after the first filter:

So I did an open moderated test with users but in order to reduce the cognitive load I did it in two rounds. First round 40 items,
Second round 25 more including their final decision on Labels.

Final features with labels after card sorting session:

Rapid Prototyping

“>Was I satisfied at the end? no of course not! I needed something more. Participants had left many uncategorized Items
and had a lot of questions. I was still not sure how some features look in the product. I thought of a small test with a kind of prototype.
Thats why you could still count this part as card sorting! but I was not sure how to label this part of the process since design had started in a kind of way but I went back & forth in between .

So I started a bit of designing! I had already decided to add icons & a small description to each item.

“>For the second test I Gathered all my icons and added them to labels I just added description to the ones which may
needed it. put the items in a low fidelity looking prototype and tested. things were much better now!

Design

Wire framing

part of designing had already started, but this is the beginning of what we can call “Design”. I already had its skeleton in mind
and Just brought it up with figma.  Now important to say is that our main focus was the desktop size since most of our user’s were there. later in the process
I put most of the time & testing on the desktop size.

Prototype & Test

Luckily I already had our color & fonts so this was not something from scratch. we were sure about our minimal approach and
I had to be carful about not bombing the user with too much data.
I started with the main first pages and then testing them with users. I also used heuristic analysis in order to be sure
about not missing anything.

“>maybe I can introduce the design in 3 parts. 1.the intro 2.the seven screens related to elements 3.the final estimation.
the intro is just one screen explaining how the whole thing works. most of every thing is in the second part! but users should
easily be able to move between part 2 and 3(sth being missed in the first prototype).
after designing the second section I already had started testing.

so every thing was checked from the checklist and applied to the designs. this is a shot from the first try which did not have a preview feature:

After testing the first prototype and checking it by heuristic analysis I came up with many good results and noticed the edits needed:
user’s were already asking for a preview and how it would look on the screen.
user’s needed to go back and forth between the estimation and features. it was not easy in the first design. (number 6 in heuristics).
users wanted a fast way to undo there selection and see what they have chose.
decided to remove the request consultation from the right top corner since it made user’s confused. (this needs more research)
I have not put the price beside each feature since my client thought it would reduce interaction and make the interface busier. but it seemed
like most of the user’s where still asking for it. but i didn’t add this on the next prototype since more research was needed.

I wanted to save the clean interface but needed new options so I tried to make the prototype more interactive in the new prototype. users
don’t always see the estimate button or the preview screen and they only show up on certain matters. I also suggested adding snackbars
for certain moments.  numbers were added to the steps to ease the process. and CTA on questions to scroll down was another new nice feature. 

Result

Good research is never enough especially if you have not done it as soon as you could ! We reached the main goals of the project but learned we need to know more and managers even thought maybe this product was not what they want
after all !. but one thing was clear we had came closer to our users. 🙂