Creating the next generation of e-commerce cloud software and empowering everyone to sell online.
I lead the UX design of a major product improvement at ePages, enabling customers to create a modern responsive online shop quickly and easily.
- Leading the whole concept and UX work, from sketches, wireframes and designs to working prototypes and styleguides.
- Contributing to strategy, planning the development and testing the product.
Do you think that everybody can sell online easily? What does it take to create a good-looking, modern online shop? Would your mum be able to do that?
E-commerce is a growing market since years and as of now, it doesn’t seem to stop. However, with the web and everything around it evolving at high speed, the expectations of a regular online shopper have grown significantly over the last couple of years.
Running a successful online shop becomes increasingly difficult, especially if you are a small business and can not afford hiring an agency to build everything for you. On the other side, you do not have all the necessary skills to do it yourself, neither do you have the time for that.
ePages enables SMBs to sell online without the hassle by providing an easy to use SaaS product. Founded in 1983, there are more than 140.000 shops running on ePages in 75 countries. One of the main goals was always to make it as easy as possible for retailers to sell online.
Starting situation and goals
The main target group of ePages does not have technical expertise and they are no (web) designers. What they do have, though, is passion for their idea, passion for the product they want to sell or already sell through other channels.
These people want to create a good-looking, modern online shop to showcase their products in the best possible way. Given their skills, they need an easy, intuitive way to do that.
Validating the assumptions
Getting in touch with users directly is a bit tricky at ePages, because the company does not sell directly, but rather white-labelled via partners (mostly hosting providers like 1&1 and Strato). That means, the customers using our software usually do not know anything about ePages (and the customer relationship does not exist with us either).
Luckily, we do have a pool of existing users to talk to (some of them even allowed us to visit them) and we also set up a rapid usability testing process (in-house and external) to be able to quickly test new ideas and iterations on a regular basis.
Looking at existing usability tests from the past as well as user feedback and other input, we could validate our main assumptions: Setting up an online shop takes some time if you want to do it right. Streamlining this phase as much as possible while providing sophisticated editing tools could greatly increase user engagement and bring even more users from setting up their shop to selling their products as fast as possible.
The target group
Due to the size and variety of the SMB market, we have quite a few different personas at ePages. However, since we planned to rebuild major parts of the software, we knew that we would need to focus on a smaller audience first if we wanted to ship early.
We decided to first focus on the users with the most basic needs—people who want to sell a few products online, in one country, one language and one currency. People who don’t know what an ERP system is or what HTML and CSS means. That is usually the starting situation of somebody who thinks about selling online. From there, the user can evolve and scale the business by selling more products, providing additional services or selling in multiple countries. Our solution was already build to scale with the shop, so it was important for us not to exclude certain use cases with the changes we were going to make.
The main problems we wanted to solve are how users set up their shop and add content like products, pages, texts and images. This should be as easy as possible, especially for users who have a very low level of technical expertise. Furthermore, the storefront for their customers should be good-looking and responsive out of the box and whatever they were going to do should not change that.
We started sketching with pen and paper and then transformed the best ideas to mockups. In some cases, we could already do usability testing with mockups and get fast feedback on our ideas.
In one of the first iterations of the administration, we moved the whole category management part in the “Content” menu. However, looking at the mockups, we were not sure if users would expect to find it there.
In order to test our assumptions, we did a rapid usability test and asked participants to find a place where they could add a category to their shop. The test, done with mockups, showed an alarmingly low success rate of 13%.
Besides that, most participants expected to create categories at the “Products” section which could clearly be seen by looking at the heat-maps.
As a result, we changed the menu structure moving the category management to the “Products” section. This also seems to be a more logical choice as we could now use the whole “Content” section for non e-commerce content only.
The main challenge was to design one consistent user flow since technically, we were going to end up with some kind of hybrid product: A new editing component build into the existing administration of the shop software. We had to make some compromises in order to keep everything as consistent as possible.
Testing and learnings
During the course of the project, we did a lot of usability testing to validate ideas and iterate on new implementations. We also adopted our testing process from only using our in-house usability lab to adding rapid usability tests.
One of the things we tested early on were two different approaches for how users could add content elements like text and images to a page. One approach showed “+” symbols on the page and the user had to click them in order to see a selection of content elements. The other approach displayed the available elements next to the site and the user could insert them via drag and drop.
We tested the two approaches against each other, making sure we had every core persona present in the test. In the end, the two approaches performed almost equally well. The main issue we saw was that at that point in time it was only possible to work in one column. However, we planned to extend the editor to allow the creation of multi-column layouts and with the first approach, that would cause a lot more “+” symbols to show on the page, cluttering it and making it look less like the “real thing”.
Besides that, it was not really convenient for users having to click a “+” symbol just to see the selection of available elements. All in all, we decided to go for the second approach and show the elements directly next to the page the user was editing.
In that case, we could use the current development state(s) to test—a luxury you do not always have. In other cases, I was creating HTML prototypes to test a concept, for example how we would position elements on the product detail page in the storefront and how this page would work responsively.
One of the most important findings from that test was to change the order of certain elements (product description, ratings, share functionality) as some of the participants had problems finding it easily. This test showed again that it can be worth to invest some time into a working prototype as it would be difficult to test with static mockups.
The finish line
As with most other, real-world projects, the “first version” is determined by many things. Working in an agile context, it was pretty clear that we would try to release as early as possible.
Besides that, the developers were using new technologies like Docker and Node.js which we did not use in a production environment before, so they were keen on getting technical feedback on that as soon as possible, too.
After a short beta phase, ePages Now is now publicly available as part of the ePages product line.