Today’s post relates the story of our cooperation with a laboratory that needed our help in solving certain issues relating to digitalization. Namely, of photographing laboratory samples and scanning of documents. Basically, there were two business targets that we were dealing with:
In the case of documents this meant the introduction of a bulk-scanning functionality without having to digitalize each document separately, speeding up the entire process immensely. Right from the beginning we knew that this solution would have to handle approximately 1000 samples daily. With these figures in mind a mere 30 seconds saved on every sample adds up to 160 hours a month.
We also intended our app to accomplish three fundamental tasks:
With these three golden rules in mind we set off to gather information on the lab’s workers’ routines and methods. We arrived at the lab’s headquarters and carefully scrutinized their workplaces and studiously observed how they get things done. We even recorded it on video so that we could go back and study any particular instance in our process analysis. This is how we arrived at the conclusions, devised solutions and designed user interface. So equipped with a thorough knowledge of both theoretical and practical aspects of the problem we could set off to solve it and, with our app ready, present it to the team at the lab.
We initially assumed that the lab’s employees scanned documents as they go, i.e. every time one was produced. However, we soon found out that instead, they preferred scanning all documents at the end of their working day. As we progressed with our analysis we quickly discovered similar subtle details. Users first printed out emails and only then scanned them in order to add them to the system. We also learned that the lab is equipped with a scanner capable of digitalizing multiple documents at once. Had we not looked at case in its entirety in minute detail but implemented our preconceived solutions instead we wouldn’t have asked ourselves some very important questions, the most pertinent being: Why have the lab’s employees picked a specific method for carrying out tasks? Is it perhaps not better suited than the one we considered the most appropriate?
The story of this project allows us to draw some important conclusions. The most significant of them concerns the supremacy of incremental, evolutionary improvements over revolutionary changeovers. Just because we think that we have come up with the best possible solution doesn’t justify the assumption that our customers’ employees will completely transform their working patterns in turn. Anyway, such model solutions exist and work only under idealized test conditions. If the lab’s employees receive hardcopies of their emails and only then scan them afterwards for the purposes of sharing them with other team members then there has to be a valid reason for it. Procedures adopted by the company may count as one such reason. External factors also come into play in adopting specific working patterns and even, unlikely as it may seem at first in this case, pure convenience. Ideally, one would devise an app that would retrieve emails automatically. However, this would entail not only a major change in the lab employees’ working patterns but also alter routines followed by the lab’s trade department. Foremostly, this could go against the customers’ habits and expectations by expecting them to adapt their behaviour to a new framework. We believe we have devised a solution that is both accommodating and universally applicable. Batches of documents in the range of hundreds of pages a day are scanned using a scanning device equipped with an automatic paper. Finally, these sorted documents are made accessible and searchable in the app.
It should come as no surprise then that the project has been an overwhelming success. Users of the app welcomed the opportunity to spend more time doing actual lab work (that brings the company more profit), instead of scanning documents. As a result, the lab itself has reached the adopted business targets. The process we developed is sufficiently flexible and adaptable to assimilate prospective improvements as the company grows. There is no need to rush, however, as every revolution has a mean tendency to “devour its children”.
Let’s bear in mind though that this, and indeed every, stick has two ends. People tend to become used to and complacent about solutions that might not necessarily be the most practical (and indeed not appropriately designed). Awareness of the ongoing process veers away from the essence. There probably is no better example to illustrate this by referring to a rather frequently used home appliance… the toilet flush. Specifically, the dual-flash toilet equipped with two flush buttons: a smaller and a larger one.
Does the larger button release a larger quantity of water? Or is it larger to facilitate more frequent pressing thereof? A competent toilet-flush designer should aim at lowering water-consumption – to the cheers of households’ budgets and mother nature herself. If the smaller button is the water-saving one then, by the nature of its size, its frequent use becomes impractical. Unfortunately, as we know it all too well from the IT world, there are designers who take shortcuts with thinking their solutions through and, as a result, condemn users to an unnecessarily lengthy trial and error learning process. Those users, conditioned to such ill-thought-out solutions, pay little attention to the fact that what they are using was actually designed with little regard for and scarcely any consideration of the surrounding context and circumstances. This is highly unfortunate, since the solution to the problem is ingeniously easy. Let’s see some brilliant examples put forward by experts from the User Experience Stack Exchange community:
Now this is a solution we wouldn’t let go down the toilet (well, in a way, we would).
I hope that this post has neatly illustrated how important it is to us to carefully study the preferences of our solutions’ users and the environments they operate in. The story outlined above is one of a happy ending. Unfortunately however, we admit that this hasn’t always been the case. Next time I will tell you the story of delivering solution to a problem where we made some mistakes and did not take heed of the customers’ employees experience and input. These omissions resulted in some extra work we had to do but now we consider it an important step in our learning process. See you next month!
Born 1989. Vice president and project manager at JMB Lab. A software developer for as long as one can remember, he wrote his first programme at the age of ten. Marcin has been a professional problem solver, and by that we mean there is no problem too big for him, for the last six years. Always on the lookout for broadening his experience, he is helped in this pursuit by his hobbies, travelling and cooking in particular (there is inspiration everywhere, right?). He considers honesty and commitment to be his strongest suits – and he consistently brings these values to his workplace. Marcin truly believes that realising the full potential of all members of a team is the key to success.