My recent work on a Proof Of Concept with remote users across the Atlantic
You have to be sensitive to your users at the level of a radar detector, especially when working with a small pool of beta testers or “potential customers”, you should be open, listen to and observe what participants are actually saying and doing. Working on the sign up feature to create photo book apps was fun and interesting as we faced a lot of technical challenges. One particular interesting one was figuring out user’s pain points especially when your users simply will not talk; they love it the app, they are mesmerized, but out of some kind of respect for what we were doing (or some cultural bias) they just will not complain or air their frustrations about the tool (probably trying not to hurt our feelings). What they did not realize was that we needed their complaints, the difficulties or annoyances they experienced when using the tool to build albums because without this, we wouldn't know what we could improve upon.
As part of the alternative process we were exploring to engage more users, which I spoke about in my last write up, we put a process in place for potential users to create quick and easy mobile apps for their photo albums which engages with a simple task - result (upload a few images to create the app) then takes you further to signup and continue usage.
The technical process however meant we had to put a system in place to manage these data (images and user profiles) either they choose to leave us personal details or not. The steps involved is to::
- Upload picture from your device (mobile or PC)
- Pictures are uploaded to the server and resized versions created as medium resolution & thumbnail versions.
- Add the records to the database tables with the right properties set
- List of thumbnails are displayed with file name (you choose one as a cover or icon for your app and have the option to revise your album or add more pictures.
- Next step is to name your album and other information which allows us to manage your content (and a client).
This was effective, through our test and feedback it was obvious that the photographers liked it; it simply worked. We got comments like “Wow!, I didn’t know building an app could be this easy“ and many others which inflated our egos. One even went as far as saying, “Why then is there this whole fuss about developing apps being so expensive since it's this easy to build from a smartphone?”
However, not to digress, only about 2 of the 15 photographers continued to create photo book apps for their customers consistently. We asked questions and had conversations with them but a key element of their “pain point” was missing which we still couldn’t figure out and that was why they just didn’t continue using it.
It was only when a student from UNN (God bless her) while going through the app voiced her opinion and Bingo! We realized what the problem was. She loved the nostalgia of having her own mobile app on her phone screen; her friends liked it too and created a few albums, both personal and shared albums, and it was all fun. However, a few minutes into using the app, she uttered the words, “... but this thing na data hug O! All my MB has finished!” in pidgin English. (for non Nigerian readers this simply means it consumes a lot of bandwidth) and that was it.
Understanding the way data is sold in Nigeria by Mobile Network Operators (MNOs), the bandwidth you use corresponds directly with the cash you spend (data for internet access is literally cash). When you do the basic math, it turns out that since the average size of a photograph taken on your smartphone can be between 3.5 mb to 5mb; when you ask someone to upload up to 50 pictures from their phone, they are essentially uploading 175 mb to 250 mb of data. This is aside the fact that a lot of people may upload and then decide to revise their album, deleting and re-uploading pictures to make that perfect album which can be less exciting when it’s costing you too much data (cash).
From this comment the problem was clear, naturally our potential users would shy away from anything that costs them data (“money”). The users liked the simple, easy to use feature but were somehow reluctant about voicing that particular frustration (pain point) which was major within this process.
We had factored this into our decision for the end user of the app (the customer, one who installs the created app when it's shared) which was why we had to create medium sized and optimized versions of the images uploaded in the first place but totally
left out this value from the creative user who makes the app. This meant we had to figure out a way to save the creative user’s data while creating an album. An approach we employed in tackling this challenge was to move the “resize and optimization
of images” function from the server side to the client side.
Resize function was moved from server side to be done on client device as the 2nd step in the process
This didn’t change any major part of the user experience but we had to make all the changes from the engineering and workflow. We leveraged javascript and inbuilt browser engine features to optimize the images in memory on the client device before it is uploaded to the server and this is what we worked on for another 2 weeks; running tests and iterating through.
This decision made all the difference as each image of 3.5mb -5 mb got optimized to about 300kb - 700kb and when multiplied by the number of images (50) this meant we dropped the file size and bandwidth utilized by about 90%. This also meant we wouldn’t be saving high resolution versions of the images for the users which had no marginal difference to our goal at the moment.
Uploading the images were faster; bandwidth for the creative user who is a major stakeholder in the process was saved and resources we were managing in terms of saving images on the server were better utilized.
That was even how we arrived at one of our USP “Saving you data (bandwidth) to share and showcase your work to clients.” This goes further to validate some of my theories about having direct feedback with users especially when in different environments. Doing this is one of the reasons companies like Google have had sustained growth and adoption in regions like Africa because of the local presence of teams that have first hand experiences of user challenges and figure out ways to tackle these with technology.
The Photo album tool is available here http://create.mudsuite.com as part of a project we started to simplify web development & management for small businesses in underserved regions. Mudsuite currently powers this website, my personal portfolio and a few other websites for select clients.
