One of our closest customers in Radii is CJ Fallon, a leading educational book publisher in Ireland. One of our major projects was to design, develop and ship one of the first digital eReaders on iPads. Today we’re on version 3.4 of this platform and it’s a rock solid product with over 8,000 daily active users. To support this we needed an equally robust administration system.
When the iPad was released in 2010, little did anyone know how quickly and widely it would be adapted. When CJ Fallon contacted us to help deliver their school books on iPad we were excited to be on board. Their concern on day one (and it remains the same today) is to deliver their content on digital platforms, while retaining IP of the books to prevent illegal distribution. Today we can distribute ebooks to native apps on iOS, Android, Windows and we have an HTML 5 App for the Chrome Web Store for laptops and desktops.
As each platform grew, so did the demand to support more and more features. We added the ability to include notes in v1.1 and we’re extremely proud of how we deliver syncing across multiple devices. We now support doodling, annotations, embedded multimedia content and the ability to take screenshots within the applications. As the requirements grew, so did the dependency on v1.0 of our administration system. Although it still handled licensing, user managment and distribution extremely well. The system required more intensive tasks such as reporting, shopping carts, embedded multimedia and CRM features to be added.
To design and build an enterprise application takes a large team and many weeks of planning and scoping. I was a key member in facilitating and running what I referred to as a ‘Sprint Zero’ workshops. In these workshops we would work with key stakeholders in defining and agreeing different aspects of the project scope. Organizing Sprint Zero’s are a collaborative way for the team to be introduced to the main deliverables of the project and to effectively layout the skeleton of the project.
One of the biggest benefits of these early design sprints is for the designer to deep dive in to the product and to understand the wider eco-system. It's important that all members of the team have a clear and deep understanding of what may impact your design decisions. Working closely with development can bring a new level of understanding, especially if there is a large focus on database design and data management. As a designer I have an ability and competence to comfortably engage and discuss technical requirements and constraints.
We decided to build the application using existing frameworks and technology that we had developed a proficiency in within Radii. Using Codeigniter for the backend and a Bootstrap frontend was the logical choice. We knew the libraries extremely well and had a set of modules that we could reuse. Choosing Bootstrap as the frontend was a comfortable constraint on how I could approach the design.
In the past I had used Balsamiq for wireframing but there were too many limitations for this larger project. I also wanted to be able to, as accurately as possible, replicate how the frontend would look and feel, so I could work with the customer service team in CJ Fallon to test and validate our designs. Finally I knew that a quick and clear handoff to development was critical to avoid any miscommunication.
At the time the best tool I could find was Moqups.com and I dived right in. Using my sketches and pen wireframes that I had agreed with development I began to build in Moqups. The ability to build using Bootstrap components and layouts are perfect for getting the layout and user interface aspects correct. Equally using cloud based tools can help you to collaborate and share with development in every aspect. For sprint demo’s you can run through the clickable prototypes to a good degree of accuracy.
As the project progressed and we were shipping features and meeting deadlines, there came a point where I realised it was taking 3 or 4 iterations on the user interface before the client was satisfied. In some cases the features were already shipped and it was starting to cause a buildup of re-work. Something had to change. I had already identified some weaknesses in using Moqups as a tool. Firstly, I couldn’t fully replicate the final UI so there was a gap in understanding how the functionality would work. Secondly, it lacked the ability to write conditional cases for hotspots or include pop-ups which meant overly complex wireframes were needed. This was impacting the time it took to create the wireframes and it was leading to issues in user testing.
At the time I had read a bit about Axure and was keen to see how I could bring it into a project. I took some down time to play around with Axure and test out the features. I was able to build complex screens with dynamic panels, dropdowns, fixed headers and much more. At the next sprint in our project, I put forward the idea to use Axure so we could see how it could fit in the project flow. With Axure I was able to build a close replica of the admin system. I could prototype a flow with the exact Bootstrap components and export to HTML. If needed, I could extend the HTML with custom CSS/JS. In this particular sprint we were working on a feature for Sales reps to be access certain reports on their iPads. With Axure I was able to build adaptive views to see how it would look on iPad, which was just what we needed to test out our final design.
Since taking up Axure, we have significantly reduced the number of iterations for client reviews. We have succeeded in pulling forward feedback that we were getting much later in the process. This achievement is down the higher fidelity prototypes achieved in Axure and the user testing in much smoother in general with less of a handoff needed.
There is however a tradeoff needed when you are dealing with views that handle large amounts of data. For some of the reporting views we need to build up dummy data and here you need to manage expectations around fidelity. This is also true of sharing Axure prototypes with user testers. Managing expectations and setting out the scope of the prototype is important at all stages.
Axure interactive prototypes have become a large part of my workflow since then and clients have responded really well to their introduction. I'm a flexible and adaptable designer who likes to learn and improve my own workflow, which means trying out new software regularly. It's always important to keep in mind that these tools are a method of communicating your design decisions. If you don't have the process to back up these decisions, then the tool is not where the problem starts. Using a combination of systems thinking, user research and colloborating with the wider team helped in this project to bring focus to my design decisions.
If you would like to know how I use prototyping on other projects or more about this project then don’t hesitate to get in touch.
CJ Fallon - eReader Platform
6 - 8 People
Wireframing, prototyping, user experience design, research, planning and scope definition