Watching users fail is key to building a good product
Just 40 hours of engineering work to go live with a state-of-the-art smartphone application? It’s only possible if you have the right framework and if you forget perfectionism in favor of real user feedback. At Spreadshirt, we want it to be easy for our users to buy, sell, create and share ideas on over 200 products on our ecommerce platform. Whether they use a desktop, tablet or smartphone, we want our users to have a great experience.
Back in 2014 we had created a t-shirt designer for tablets, to reflect the rise of the touch screen. It worked on smartphones, but that was a rare use case back then. This web app has been perfected through many iterations. But the mobile times changed. And exactly as we had already envisioned in 2016 smartphone traffic was up 22 percent and tablet traffic was down at less than 10 percent. We needed a new design tool to focus on the experience for our visitors from smartphones and find out what their specific needs and issues were. Watching users fail holds the greatest learnings when you develop complex applications, such as our smartphone t-shirt designer.
Traditional user testing (not live) is often very artificial because the user gets tasks, but they don’t really want to create a product, so the responses are not real. We wanted to drive some real user traffic to the smartphone t-shirt designer, and watch our users fail in order to get the UX right for a wider audience. After 40 hours of agile development we released the smartphone t-shirt designer on our platform.
The first real user traffic was sent after just 80 hours of engineering work, as part of an A/B test which is now running in Germany and the USA. First results show 30 percent more clicks on the add-to-basket button compared to the version developed for tablet back in the day. The worldwide roll-out is planned for the end of the quarter.
Divide and conquer is the key to solve, understand and maintain large applications. Building and testing functional units (components) and putting those components together to create a larger component, or finally an application, is what Adobe did in the past with Flex on the Flash platform and Microsoft with Silverlight. The declarative approach of using and building components is great and the data binding helps to keep the model and view in sync. But those browser plugin-based applications suck and back in the day, when tablets were entering the market and Steve Jobs sealed the end of the Flash with his "thoughts on flash," we started to move away from this technology to building RIAs with open web standards such as JavaScript, HTML and CSS.
In 2012, when Internet Explorer 6 was still one of most used browsers, we started developing a declarative JS MVC Frameworks (rAppid:js) at Spreadshirt, to reuse code as components with standard web technologies. At this time, AngularJS was in an early stage, React did not exist and native web components were only dreamt of.
Developers become developers, because we hate to repeat ourselves. With rAppid:js combined with modern web technologies, we can easily reuse code and can kick out rich internet applications (RIAs) to real users and validate our ideas as quickly as possible. We just put the components together differently and adjust the UX, which gives us time to play with hot technologies like voice recognition.
Because of this process, the smartphone version of the t-shirt designer shares 90 percent of its source code with the tablet version, but has a different look and feel. All the buttons are aligned to bottom of screen, including navigation, to make it easy to get around using your thumb. When reusing components along applications the maintenance effort is not as great as having a distinct code base -- fixing a bug within a component once and it’s fixed in all the applications using the component. Another advantage of sharing the same code is that new features are developed once and are available in all the other applications using the component with the next release.
Nearly all components that build up the t-shirt designer are open sourced at GitHub with the intention that other developers out there would use it to create new applications. Most of our partners have great ideas around printing something on a shirt, but do not have the required skills in programming to directly interact with the components. So we made it easy for them to embed the t-shirt designer (as one big component) within their web site with only 2 lines of JavaScript. We also provide a JS API to control the application during runtime, so you can easily change the product, put a text on it or save to our API.
Reusing code like this makes it easier and faster for us to improve the user experience when our user testing reveals problems; like this highly frustrating one:
We know that our users are spend around 30 minutes to two hours at Spreadshirt to create a product they love. This is a lot, especially considering the quick, multitasking- oriented smartphone world. Our customers are clearly getting involved in designing their t-shirts. However, smartphones are nothing if not distracting, and they have limited RAM. There’s always a new tweet, WhatsApp message or even a phone call.
We discovered that deep links were ruining our users’ experience. If they moved away from the t-shirt they were working on, the browser would reload the page after the interruption and based on the passed deeplinks all the design work would be lost. How frustrating! This had a severe impact on converting smartphone designs to sales too. Because we watch real user activity, we can see them fail and fix bugs like the deep link problem very quickly. Now when a user comes back to the designer, it restarts where they left it.
We had this vision for a thumb-friendly, smartphone t-shirt designer four years ago, but our users weren’t ready for it. By building our own, component-based framework, we’ve been able to keep one step ahead of our users and easily create new features when they want them. It means that our users get the same excellent experience from any device, and it’s better for the development team too. Spreading it with Spreadshirt is possible because we’re not afraid to watch our users fail…and then fix it!
Published under license from ITProPortal.com, a Future plc Publication. All rights reserved.
Photo Credit: pathdoc / Shutterstock.com