Interaction designer Jack Bellis tells us how Justinmind helps him prototype mobile apps at Elsevier, one of the world’s largest scientific publishers
Today we’re looking at how interactive prototyping can help in the scientific publishing field with Jack Bellis, Senior Information Architect at Elsevier, one of the world’s largest scientific and technology publishers.
In his role as interaction designer of scientific and medical apps, Jack builds mobile apps to help researchers and clinicians with tasks such as job discovery, chemical synthesis, engineering research, material selection.
Jack’s focus is on bringing interactivity to visual design. But he found that he wasn’t getting his point across with lo-fi wireframes and textual specifications docs full of requirements. The doctors and researchers he works with didn’t understand his mobile app designs or wireframes. Jack needed to find “the sweet spot of interaction design”, and fast!
Mind the app development communication gap
Jack has to explain his designs to doctors, scientific researchers, and product managers. The success of a mobile app design depends as much on the target user as it does on the interaction designer, after all.
But within such a highly technical scientific environment, one of Jack’s biggest challenges is communicating how the mobile app is going to work. Miscommunication in software development cycles is a danger even for software-savvy teams. Working with non-software stakeholders can make it even harder to convey app interaction, functionality and features. Jack faced the old cliché: “I don’t know what I want, but I’ll know it when it see it.”
Mobile app interaction design challenges
The other big issue for Jack was to convey the level of interaction of a product. Sure low fidelity wireframes, sketches, mockups and paper prototypes all have their place in the mobile app design and development cycle. But interaction is at the core of many products these days, according to Jack.
A static text document cannot show clients the exact behavior or experience of an app design. Discussing whether they want one or two columns, or if it’s a free text entry or a controlled vocabulary entry… these things don’t even come into people’s minds if they don’t see an interactive prototype, Jack explains.
Trying to push a medical app into production armed with just textual specs caused problems. And even pixel perfect wireframes couldn’t convey the dynamic aspects of Jack’s designs.
Building better apps, cutting communication problems
About 4 years ago, Jack decided he needed to move away from static wireframes and documentation; he needed to put the interaction in Interaction Designer. After a quick analysis of the web prototyping tool market, he gave Justinmind a try.
Initially attracted by the intuitive interface, Jack found a lot to love in the prototyping tool. “For instance, I can click on a widget, then click on the canvas and put the widget into the canvas. But I can also drag it from the toolbox to the storyboard.” Other features grew on him, like the adaptive layouts, dynamic panels, and 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 are a 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’s also a big fan of Justinmind’s Masters, finding them to be a nifty time-saver for repeated actions. With Masters changes are applied globally across prototypes, so you can create an interactive app prototype super quickly. Jack found that clinicians and researchers could finally understand his designs and see the bigger picture. No more miscommunications.
Requirements management just got integrated
Jack waved goodbye to textual requiremetns documentation once he started using Justinmind. His high-fidelity prototypes reproduce all requirements right there in the prototyping tool (check out the Requirements tab in the interface). There’s also a complete version history available and requirements categorization, so every one stays organized.
Plus Justinmind is integrated with tools such as Jira, Doors and Microsoft TFS. Teams can update requirements in one tool and see those changes reflected in the other tool in just one click. Add a requirement to an element on the UI canvas in Justinmind, import to Jira and you’ll see the requirement right there in your items, along with a handy image.
“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.”
Prototyping a mobile app with real data
A set of Justinmind features that Jack uses extensively in his job are the data-driven prototyping features. When he works with projects where the data is crucial, such as with discovery tools, he needs a product that allows you to populate and prototypes with real user data.
Using data masters, Justinmind app prototypes can be filled with records imported from an existing database. Jack can then play around with data grids, lists and even selection widgets to show his real users data any way he wants. From confirmation pop-ups to error messages and searchable lists, real data can be used to achieve full interactivity in Justinmnind. You can even create complex logic by writing conditions into your data-driven prototype.
“It doesn’t work to say ‘this is just sample data’. Twenty fake records are not the right substitute”
Prototype mobile apps faster, communicate better
Once Jack has some user testing done and some results, the app prototypes are sent to developers. He’s noticed that since he started using Justinmind, the development team have fewer questions for him. That means that Jack can get on with designing interactions and medics can get on with using his apps.