Wundertax

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.

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.

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.

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.

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.

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.

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.

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.

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.