Wundertax

Wundertax logo
Mobile UX Design • 2024
Project Overview
Already having a well-working webapp, Wundertax wanted to transform their content-heavy, form-based tax declaration service into a native mobile app. Challenging here was especially the tight timeframe, limited UX maturity in the company and product management responsibilites - Therefore I applied Tommy Geoco's framework Making Design Decisions.
The MVP immediately achieved an install to purchase rate of over 7%, which is highly satisfactory for a 35€ app-product.
Download on the app store iconGet it on google play icon
Screenshots of the Wundertax app
Similarly to my work at AXA (insurance), the german tax declaration is a topic that people usually do not enjoy and that 47% of employees don't even do, although the average return is over 1000 Є. Frustration and confusion usually play a big role for people.
Moreover, it's a once-a-year process. So the most important research was if potential users actually want to download an app.
Given Wundertax's large mobile traffic, an increasing amount of inquiries for a mobile app in CS and a handful of user interviews, we decided to go for a MVP version for simple tax cases to gather more approval without a high-risk high-effort solution.
↪ No one actually wants to do their taxes or understands them
Foundational problem 1
I was the first UX designer at the company, which meant that existing product/design material of the webapp was very scarce. I needed to create an overview over hundreds of form fields, checkboxes, help texts and tax categories as well as flowcharts and user story maps. In addition, evangelizing basic UX principles in the company was part of the process.
Due to that there was less time for traditional user research and the need for hundreds of fast and effective design decisions.
↪ Status quo
Foundational problem 2
Design thinking process by stanford and a trash bin icon, connected by an arrow
Designing well functional apps very fast, without comprimising on thoughtfulness, requires thinking outside the box of traditional processes, like the Stanford Design Thinking or the common 5 step procedure.
Today’s library of cognitive psychology, design systems research, and interface patterns is full of reliable contributions designers can use to design fast. Especially utilizing ChatGPT to get that knowledge on the spot can boost productivity, if you know what to search for. Pairing that with techniques like Rapid Prototyping and Guerilla Testing speeds up the process even further. Moreover, following the maxim good is good enough instead of driving for perfection, was key for this project.
We started with an information scaffold instead of an UI kit. The design system was developed simultanously with working on the flows.
↪ How to design effective UI at warp speed
Process
My personal scaffold exists out of psychological concepts, market opportunity, fitting UI patterns, Atomic Design, usability heuristics, economic fundamentals and accessibility references. This scaffold is basically a large PDF that guides me through design decisions.
Using a list of preliminary requirements from this scaffold, I agreed together with the dev-team on a technology that can support those. Those meetings also enabled them to already set up the backend, and thus decreasing time until the launch, before even receiving designs from me.
↪ Using an information scaffold
Design decisions
2 screenshots of the app, one with the old design and one with the new design
We noticed from earlier usertests on desktop that most users felt overwhelmed by the amount of formfields and checkboxes in tax declarations (even for our simple tax case there were 200+). My intuitive design decision would be to reduce the amount of visible choices per screen. Miller's law also suggested to focus on chunking information into smaller, digestible pieces to accommodate the short-term memory limitations of users. This was especially important in the design of the app’s form fields.
However, my information scaffold also told me that an important usability heuristic is user freedom and control. Weighing both principles and the small screen size and less input possibilities on mobile, we decided to go for a principle I named forced guidance. This reduces cognitive load significantly, but on the cost of user freedom. Here, my information scaffold helped me to consider pros and cons of a design decision to keep them in the back of my mind for future user feedback and possible iterations.
↪ Forced guidance over user freedom
Foundational Design decision
A screenshot of a design system in Figma, the pages and the typography section are enlarged
We adopted an Atomic Design approach, breaking the interface into small, reusable components that could be quickly assembled and iterated on. This method not only sped up the design process but also ensured consistency across the app, making it easy to scale and adapt. By designing atoms, molecules, and organisms in parallel, we could collaborate with developers early, allowing for faster implementation and fewer design handoffs. This modular system kept the project agile, enabling rapid adjustments without sacrificing quality or coherence.
↪ Atomic Design
Design system
If you want to design at warp speed, UI libraries might be one of the first things that come to mind. However, after agreeing that we only need a handful of more complicated custom components and that we want the functionality to be somewhat similar to our webapp, we agreed that there is no library that supports our needs. Technical difficuties for designing large, content-heavy forms and certain immaturities of libaries like TamagUI made developing natively the more efficient choice for us.
↪ Why we didn't use UI libraries
Design system
screenshots of the user story map and different flowcharts
Working mostly remotely, we turned distance into a strength by leveraging Google Workspace for instant updates and quick meetings, while we used Figma for real-time design collaboration. Slite kept everyone aligned with a shared knowledge base. These strategies turned potential communication hurdles into seamless teamwork, driving the project forward with pace and cohesion.
Very detailed Flowcharts and User Story Maps were the foundation for a common understanding.
↪ Harmonizing with a team of remote developers
Collaboration
We conducted 3 low-effort rounds of user testing and interviewing, one before, one during and one after completion of the MVP. Our core assumption, that reducing the amount of visible and clickable elements leads to the user feeling less overwhelmed by tax terms, was validated. Moreover, the clearer hierarchy reduced it even more.
Adding status bars to the high-level step overview as well as to deeper levels of the tool gave reassurance to the users.
↪ Users loved hierarchy and knowing what's up
User testing
2 different changes in the app, portayed by 4 screenshots - one is the Expenses section and the other one is the step overview page
Once again, I got the realisation and real-world proof that good UX design is not about fancy components, micro animations or cool UI, but mainly about what the user expects where in your system and what information you need to provide for a smooth ride. For the future, I want to ensure to apply a certain level of storytelling to every experience I design.
↪ UX isn't art
Learnings
After 4 months of work, we published our first MVP to the appstore. The initial data suggest that the app works well and according to our goals. We achieved over 2000 installs in the first week, most of them with organic traffic. With an install to purchase rate of over 7%, management and product were very satisfied. The amount of customer support tickets was lower than on the website per purchase, however we also only supported simple tax cases.

For future developments we decided, due to the good launch, to incremently add more tax cases to the app. We will start to add the cases that have the biggest drop-off rates in the onboarding, where we sort out those complicated cases and send users to the website. We will go from high to low demand.
Other important KPI's we'll take a look at for iterations of existing parts are task-success-rate and user-error-rate. We can track those for each step in the tax declaration individually. User testing will then be done with particular emphasis on those steps with friction.
↪ User-friendly tax declarations without headaches
Results & outlook