How I ventured into Product Design while coding
Amidst the nice summer break between the end of college and beginning of my first job, I received this request to join work earlier. With a bit of pain about cutting short my holidays and the excitement of what future held, I decided to join UXArmy about a fortnight earlier than the joining date in my offer letter. The first day at work was full of handshakes with colleagues, reading up my own stuff, setting up company email, git account and and an informal chat with company management. My first responsibility was to figure out and develop an advanced piece of software technology that could help users visualize colours on their walls digitally.
My first few Google search results hit an article which almost convinced me that the responsibility that I was asked to shoulder was a job of the experts, it takes over a year and a dedicated team of unicorn software engineers to complete. When I showed this find to my management, I was told that company had decided to take a calculated risk in getting a fresh graduate to “make it happen”. Few hours went by and I realised that I had accepted the challenge.
In my first few days at work, the day would typically start with instrumental music in my headphones and a monk like concentration on my laptop screen. Trying out snippets of code was routine — sometimes I created them based on research papers or at times advice from highly ranked contributors on Stackoverflow. Some days I stepped out of work quite satisfied with what I had accomplished, there were also days which felt like four steps back after the three steps ahead from last week. Overall, I was excited because a real problem was in front of me and there was no widely accepted solution or framework available to start with.
Folks at UXArmy
While the demo applications which I made got the other team members and management excited, I was still unsure if I’m writing “industry level” software or was I traversing the shortest route to the solution. I believed then and I still believe that a highly experienced software engineer would have done the same job faster and better, even though my management believes otherwise. Such difference of opinions are common at work when we discuss over design choices for our online user testing platform.
Completely immersed in software development and my dispassionate encounters with UI (I really hate UI), I found myself talking about user experience and user goals. Our product development team, has highly skilled people who enjoy tackling challenges and accomplishing difficult tasks — in the pursuit of building best known yet!
As a team we were in the design process for the Visualiser App, the one where my work of digital wall painting technology was supposed to be used — aka the colouring technology that is programmatically complex and extremely intuitive for mobile phone and computer users.
My objective was to create a better colouring technology than is known to the world and it can work cross platform. The goal of the App was that users of all ages and abilities can easily reimagine room colours by repeatedly changing the colours in various sections of an image. Experimenting with many colours can help the user arrive at an optimal colour choice — well before purchasing and applying a single drop of paint.
Along with colleagues and stakeholders from business, I was regularly involved in brainstorming and mind-mapping sessions. We found that we could serve an important need by creating a superior experience in which a consumer could see how the walls of a room look with different colours.
I was continuing progress on familiarising myself with finer details of Computer Vision algorithms and other colour attributes like intensity, hues, tones and shades. At the same time, several of story-mapping meetings were happening which became a complimentary routine to my software development role. As a team, we used to discuss and describe each of the exact steps that would be a part of this experience. An image from our (often intense) user centered design discussions is here:
I had transitioned from a “pure” (no UI) to a “polluted” (a bit of UI along with UX Design) software developer but this transitions made so much sense. I felt an increased sense of ‘belonging’ to the team — we were divided and united in our discussions by one and only one thing — users’ benefit. Each of us knew and understood that a successful product development team knows that shortcuts are often detrimental. So our team was discussing thoroughly and our user researchers were adequately conducting user research.
One of the initial ideas for the application of the colouring technology envisioned the user performing a drag-and-drop technique to choose the area for recolouring. Not only did this seem somewhat geeky to us, we realized that this would be a tedious process for the user. Also, we thought about some previous feature designs in which the user would have too much of a burden in executing the selection and manually performing the masking to achieve a desirable outcome. Following user validation with key representatives of the target user community from our User Panel, some of those experimental designs only led to user frustration.
Our goal was simple, but we knew it would be challenging. The best design would make virtual painting effortless and hassle-free. An experience that does not require much effort from the user would invite many potential customers to give it a try. This meant that we had to design and build the virtual painting app to do as much of the tedious work as possible — but also require minimal effort from the user so that the experience is entirely natural.
We knew for sure that the user would import an image and also have some initial colour choices in mind. If possible, we didn’t want the user to have many concerns beyond the image and those colours. Our biggest challenge was to distinguish the area to be painted from any areas immediately adjacent. This was a problem that could be solved by developing software that would readily identify objects and surfaces in an image. Additional design work revealed that the key to the solution was more about colouring efficiency and simplifying the User Interface Design for the user.
Hard work to make it easy for the user
We started with the idea that the user would select a specific area to paint. The app would replace the colour of that area only, and leave all other objects in the image in the original colours. Drawing from our combined experience in the team, we initially thought it best to pursue object detection. A potential problem with that approach was that the list of possible objects would be endless, and this would limit the number of cases that the app could handle.
We then decided to work on an approach that would involve general identification of surfaces, such as walls, doors, ceilings, and tables. We chose to employ computer vision technology together with machine learning, and designed a method for identifying a surface area by taking any point inside that area as an input. In addition to object identification, we sought to divide the image into surfaces. This was also the simplest approach, since only one user input is necessary. A simple tap onto a particular surface could change its colour. We extended the design to ensure that any ambient lighting and shadow effects would be retained on the surface after applying the digital paint. This extra effort resulted in much greater realism in the recoloured image.
With the design complete and the technology implementation had taken good shape, we built an app in which a user can simply tap a surface to recolour the walls of a room in an image. This greatly assists the user in understanding how a potential colour change would affect the appearance of a room.
My two cents for new software engineers
Anyone who is joining new roles in startups should always make efforts to keep themselves aware of the latest stuff in their field, not fear change and tirelessly strive to improve their technical skills. The business would automatically benefit from it.
My definition of senior programmer got revised. In terms of speed senior programmers are a better bet for businesses but one’s own research capabilities and new problem slims down the difference between senior and ‘new but persistent’ programmers.
Summary
A good way to solve any problem is to do research and discuss with the people around with an open mind while staying away from shortcuts. This helps in making sure you are not reinventing the wheel. New software developers should always try understanding how things work on a fundamental level. If the problem is new to everyone then you are as smart as the person across you — so don’t shy away from that in fear of failure. Most importantly, keep in mind who you are creating your software for — the User. Your work is fundamental in creating the User experience!
Read more of User Experience and Technology
…by Abhinav
Abhinav is a Software Developer who loves technology and harnessing it to make life better for everyone. He tries to learn as much as he can from people around him. His interests also lie in many fields outside the technical realm. Reach him at @Ab_inav on twitter
How can you solve your users’ problems?
At UXArmy, we focus on solving user problems, meeting their needs, and creating great experiences. We conceal technical nuances from users by doing the tedious work for them and eliminating complexity from the user interface. We continue to build awesome products and services for online user testing. The best is yet to come.
