Interactive Prototyping in the Scientific Publishing field: a Customer Case
Jack Bellis is Sr. Information Architect at Elsevier, one of the world’s largest scientific and technology publishers. He works as an interaction designer of scientific and medical apps for researchers and clinicians, such as job discovery, chemical synthesis, engineering research, material selection. As an interaction designer, he gets into visual design as well as in more technical angles such as web and app prototyping, “the sweet spot for interaction design”, and he chose Justinmind as his prototyping tool. Let’s see how he got to this decision and how he’s getting on with it!
Looking to fill the communication gap between the business world and the software design world
Jack has to deal with a specific profile of people, to whom he has to explain his designs. They are mainly doctors, scientific researchers, and product management. He has to negotiate with them the design they think will be successful. However, within such a highly technical scientific environment, one of the biggest challenges is to communicate how the software he is designing is going to be. Communication in the software world is indeed challenging for a lot of people, no matter how close or far they work from each other. Business world doesn’t speak the same language as the software world. It always ends up with the cliché “I don’t know what I want, but I know what it is when I see it’s not what you made”.
The other big issue for Jack is to convey the level of interaction of a product. A good part of the UX design world is about low fidelity wireframes, sketches, mockups, paper prototypes. For sure, one has to use the right tool for any given job but, according to Jack, interaction is at the core of a lot of products these days and to ask people to imagine that level of interaction is not realistic. He gave the example of database fields, increasingly coming in as a business requirement for discovery tools, which is what Elsevier mostly produces. A static text document is not of much use to show clients the exact behavior of what an interaction designer suggests, call it the user experience. An unexpected number of people need to have some of these things worked out to a certain degree. Discussing whether they want one or two columns, or if it’s a free text entry or a controlled vocabulary entry don’t even come to people’s mind if they are not seeing an interactive wireframe, Jack explains.
Efficient interactive prototyping brings to light requirements definition
Jack started using a prototyping software, and specifically Justinmind, about 4 years ago. After an analysis of web prototyping tools on the market, he quickly narrowed it down to Justinmind and a couple of “competitors”. It soon became clear that Justinmind was the winner. The modern interface led him to have more confidence in it; the orderly layout and the more orderly user interface made Justinmind a more efficient tool when compared to others. With the passing of time, Jack noticed more and more little nuances, such as the possibility of doing things anywhere, as he wanted to, and with multiple techniques. “For instance, I could click on the widget, then click on the canvas and put the widget into the canvas, but I could also drag it from the toolbox to the storyboard”. And many other features grew on him, through the use of the app, like the adaptive layouts, the dynamic panels on the canvas, the possibility to change things with mass actions. A real time saver, according to Jack, which led to a big difference in productivity.
“Mass actions; complete return on your investment time; things are where you expect them to be: it makes you feel like everything you do gets results”.
He found in Masters the best reuse technique of Justinmind and makes of everything a master as soon as he uses it a second time. The huge benefit of using Masters is that changes are applied globally across the prototypes. He also makes a big use of widgets, and everything on dynamic panels. As Jack confirms, web and app prototypes are a huge help because they let you see processes you wouldn’t picture beforehand. And the speed and explicitness of Justinmind make it a real winner at this. You can create something real very quickly, and the result is clickable, definitely something more than bare page changing.
“Requirements definition has always been a problem in software, and making it come to light with interactive prototyping really made a difference to a lot of people”.
With Justinmind it’s possible to get high-fidelity prototypes that reproduce all the requirements, simulating end-to-end flows. The requirements management features included in Justinmind, such as versioning requirements, integration with 3rd party tools, and requirements categorization, just make it all better and they are only some of the many features of the app. Another benefit of building prototypes is workflow validation, absolutely core to it according to Jack.
“Web prototyping tools absolutely help with product definition”.
High-fidelity web prototypes conveys the dynamic aspects of the design, leaving little space to misinterpretation. When Jack was not using Justinmind, specification documents were the only documents developers were using for their work, and this presented them with many issues at the end of the project. Even pixel perfect renderings couldn’t convey the dynamic aspects of the design. Result: at the end it was not what you expected it to be. “With prototyping tools you have more of an idea of what you have to expect”, Jack says.
A set of features that Jack uses extensively in his job are the data features. When he works with projects where the data is the ultimate thing, as it happens with discovery tools, he needs a product exactly like Justinmind, that allows you to populate the data masters (and by extent data grids and simulated queries) with database data.
Thus, web prototypes can be filled with plenty of records coming from an already existing data base. The forms simulation and validation features allow to build content driven forms and simulate live form filling and input submission, as well as error messages, leaving nothing to imagination. For scientific users it is in fact extremely difficult to imagine data: “When you’re not really proving anything because of the interactions and you’re only proving something because of the richness of the results or the manipulations of the results it’s very difficult to get users of those tools to use their imagination about the result. It doesn’t work to say ‘this is just sample data’. Twenty fake records are not the right substitute”, Jack says. Definitely a point for Justinmind, which makes hi-fi simulations possible. And things keeps getting better and better with updates and new releases of Justinmind prototyper.
It’s really the case to say it: Prototype Faster, Communicate better.
Once Jack has some user testing done and some results, the web prototypes are sent to developers. When asked if developers do find it useful to have access to the prototypes, he answered he doesn’t really get a lot of feedback but rather less questions from them since they’ve been using Justinmind. And we can all guess with him that no news is good news.
To become a Justinmind expert, Jack made an extensive use of our tutorial videos. “If I didn’t watch each one of your videos, I did watch 9 out of 10 of them”. Have a look yourself at our support section and give it a try!
Originally published at blog.justinmind.com.
