Teaming up with Hendrik brought a lot of insight into building a prouct and we came to a quick outcome with a process to learn much from.

– Dennis Bauer, product owner & programmer @ mercanData

Case Study: MercanData

My tasks: Concept, Naming, User Research, Information Architecture, Prototype, Interface Design, Usability Testing


Dennis and I had the problem to have several products and no synchronisation between devices for like mails, contact list, etc. When we looked into similar programs we came to the conclusion that a lot of tools are either expensive or have a too complex feature list whereby the overview can quickly be lost.

Therefore we thought about a minimal program that fits our needs and could be used in small companies from 1 to 6 people. This little program is called mercanData.

Approach & Solution

Before we started with the production we put down our needs for a program like that and build up a feature list. We iterated this list several times and added some more features from time to time while we always had in mind to keep the program as basic as possible.


When we had the most based features written down I didn’t start with the design in the first step. Dennis started with the coding part and only a had minimal wireframe design in it which was only temporary for the test-phase. Dennis implemented the most basic features from the first list while I made the simple CSS for the ground based design to visualise these.

After testing on Windows and Mac systems several times we build up a test version for real user testings. We approached small companies, startups and freelancer we already new and asked them how they handle their client data and invoices. While small companies already had bigger softwares that we also tested beforehand ourselves, freelancers and startups mainly worked with iCloud contact sync and Word or InDesign to create their invoices sending them individual via mail to the client. Both groups had usually the same problems that we discovered too: Either the programs are too complex or the effort is too big to handle everything in different places. Also the syncing process between different devices or accounts was to complicated.


When it knew that the people we did the research with matched our criteria we sat down with them and showed them our prototype. We got a lot of insight out of these sessions while the users were blindly testing the program in our moderated usability testing guided by me.

Despite many design flaws the users understand the functions and where overwhelmed on how easy the process was to add a new client, define projects and linked them a specific client. While this project we felt the clients alone with their thoughts and only wanted them comment their thoughts and actions. Easily they went through all the different process like finishing a project and automatically sending out the invoice with an easy click on a button. Also creating the protocols for the meetings and calls with clients and linking all this together. After several tests like these I finally could start the first designs and improving the concept of our program given by the feedback from the participants.


I tested the program again with the first design step and came to the conclusion that it is too complex and not giving a real overview with loose information overdrive and sat down again with Dennis to iterate the design and thinking about how the minimise the information and tackle the lack of overview.


Still not being happy about the outcome I shut down all my thoughts about the first design and sat down for a completely new try without aiming to improve the old but rather do a fresh start. I picked up the idea of having a quick overview on the calendar but also having a small overview about the finances and goals of the month or year. Therefore I made the complex more simple, telling a story by what needs to be done and what should come next. I added the concept of future plans to the dashboard to show the user when it is time to get more cash flow by acquiring new projects and clients to keep going.

From this point on I came to the 5 Second Rule which declares that the dashboard should provide the relevant information in about 5 seconds. I tried to not flood the overview with data that isn’t needed to be pulled to the front page. The outcome of this design was tested again with the participants who backed up my theory and provided even more feedback for future iterations.


Outcome & Conclusion

The project had a big impact on our skillset and managing skills between distances. We only worked in a team of two but still had to manage the remote work and task management. Still we were able to put together a small tool for appointment, past phone calls, mails and meetings including protocols.

Because of it being a private program that will only be given to selected friends and partners. That way we didn’t have to monetise it for maintaining it. Thus we made sure it will stay a small side project we can test new technologies on and learn new skills in our free-time.

You want to work with me too?