In the previous post, I described how Design Thinking was applied by the UX for Life Sciences working group at the Pistoia Alliance to design new software solutions. But once you’ve gone through the Design Thinking workshops, and produced the requisite reports, you still have to produce software. How do you cover that last mile and translate a paper-or PowerPoint prototype into a fully functional prototype with the least amount of effort?
There are three artifacts from the Design Thinking process that can help you get started. The design guide, the storyboard and the actual prototype itself. Let’s start with the design guide first because heretofore we haven’t really talked about it and it’s an important part of the process.
Design Guides
Design Guides typically provide developers with solutions to common design problems. How can I make a page layout that works for a mobile device, a tablet, and a desktop? Or how can I make a component that lets me invite users to a meeting? Should that component be a simple list of users, or should it be an autocomplete component that displays a “chip” containing the user’s picture and their name?
If you’re Google, you create the Material Design Guide to help developers solve these common problems. You spend years studying user interactions on a wide variety of devices. You use the Design Thinking methodology to develop software, and learn what differentiates a good user experience from a bad one. You then distill that research into the Material Design Guide.
And in order to make sure that developers start using it, you launch Material Design in front of thousands of developers at the annual Google IO developer conference. You teach developers how to implement material design concepts in their own software, and seed the development community with Material-compliant components for Android & web development.
The Material Design Guide itself is a specification that shows what a component should look like, and how the user expects to be able to interact with it. But the goal of the guide is to provide a developer with a road tested guide to creating user interfaces that will always appear consistent to a user. Why do this? Because developers are notoriously bad at creating user interfaces that are appealing to users. To be fair, a developers priorities are usually “make it work, first; make it pretty, second”.
And because “making it pretty” is always a lower priority, it sometimes falls off the To Do list. If you’re a user, this can leave you in a situation where you’re staring at the screen, unable figure out how to accomplish the task at hand. However, if the developer has followed the design guide, then everything you see on the screen should be familiar to you. You should have seen it a hundred times before in the applications on your phone or desktop.
How Does A Pharmaceutical Company’s Design Guide Differ From Material Design?
In pharmaceutical companies, marketing organizations have traditionally used Design Guides, similar to Material Design, to insure that external, customer-facing websites adhere to corporate graphic standards (i.e logos, icons, colors, and typography). In addition these guides often insure that drug information websites provide clear and consistent information to the customers and patients they serve. You might see guidance for representing drug label information, or usage recommendations (the types of patients this medicine is intended for), adverse event reporting, drug procurement assistance, etc. Since some of this information has regulatory requirements, and the guide must insure that a developer has all the information necessary to comply with the appropriate regulations. You can take a look at the Taltz website to get some idea of the types of information typically presented.
How can design guides help research organisations?
As we’ve seen previously, design guides can help research organizations minimize training requirements for software by insuring that internally developed software has a consistent look and feel to it. Design guides can be used to make developers aware of existing components that can address particular requirements, and specify CSS styling requirements. Moreover, as vendors begin adopting similar standards, the line between vendor supplied solutions, and internal software begins to blur.
All of these factors have a direct bearing on how the software is perceived by its users. Even at the prototyping stage, design guides can help insure that user interfaces are easy to understand and familiar. Design guides can include printable PDF templates for components which Design Thinking teams can use in their prototyping efforts. They can also include images of components that can be imported into Keynote or PowerPoint mockups.
Using Storyboards
Storyboards help us understand the flow of the application. They help us visualize what the user is trying to accomplish, and the steps that they go through to accomplish it. Since there may be a number of use cases that use the same screens, you may have multiple storyboards that describe these flows. Moreover, storyboards help us understand the upstream and downstream processes and the handoffs between them that have to be supported.
Let’s suppose for a moment that you’re implementing software that will help users analyze LC/MS data. You map out the process for how the data will be analyzed, how significant results are identified, how AUC calculations will be made, etc. You work with users to identify test cases, identify test data sets, and expected results. And you’re off to the races.
But you’ve forgotten to ask what comes before and after this process. What format does the data arrive in? Is raw instrument data used or is it pre-processed? What about afterwards? Is the data stored in the database? Do you need to archive the raw results that you started with, or just the analyzed results? Are the analyzed results to be stored in a database, or in a report? How will the data be used? By whom, and for what purpose?
With a complete storyboard however, the answers to these questions are readily apparent.
Using Prototypes
Prototypes help us understand how the user will be using the components present on the screen. They help us understand everything from the data that needs to appear on the screen to the permissions needed to see or interact with the components. The real value of a prototype is that it delays developer’s immediate inclination to start creating software when they don’t fully understand the problem. Creating a functioning prototype with working code and sample data will often take longer than the average 5 day design sprint, but it gives us a really good idea of what has to be built. It gives us an idea of the complexity of the software, the use cases to be supported, the roles that need to be defined, and the data types that we need to work with.
The prototype also insures that both the user and the developer have a common understanding of what’s expected of the software.
You can use the prototype to estimate the effort required, plan development sprints, and identify test cases and test data, In the end, you minimize the risks that come from misunderstandings.
Tip 1 – Use A Template
During the sketching stage of the Design Thinking process, you’ll find the JoyTong template useful for sketching user interfaces. This stainless steel template has common icons and fields needed to create a professional looking user interface with a minimum amount of work.
Tip 2 – Use Paper Templates
The UXLS group has a number of paper templates and guides that can help you get started.
Tip 3 – Use Prototyping Tools
During the prototyping stage of the Design Thinking process, there are a number of tools that can help you with your prototyping efforts. If your company users Google Docs, try the Balsamiq plugin, Draw.io, Gliffy or LucidCharts. These tools make it easy to prototype user interfaces in a collaborative fashion. Multiple users can work on the same user interface at the same time.
Reusability – The Last Mile
At some point in the prototype-test iterations that you’re making, when both the developer and the user are confident that the paper prototype accurately represents the necessary solution, you’ll pull the trigger and start writing code. This is the most expensive part of the process but there are ways that you can minimize development costs and provide flexible, reusable solutions.
Web Components
Over the last 5 years a new W3C standard for reusable components has emerged. Championed initially by Google, the standard has been widely adopted by browser vendors. Web components are a combination of an HTML template, CSS and Javascript. Google’s implementation of the standard (known as Polymer) has evolved rapidly over the years, but with the latest release, we see increasing support for the new standard in frameworks like React, Vue, and Angular. You can see a sample component here.
Companies like BBVA, Comcast, Google, ING, USA Today and others are using web components. In the pharmaceutical industry,
Web components are Javascript based, and make use of ES6 standards like classes, template literals, and module imports. They also use the Node Package Manager (npm) to manage dependencies. This means that tooling support for web components is already available in popular text editors like Visual Studio Code, Atom and Sublime. So you have code navigation, intellisense, templating, unit testing and debugging support.
At their core, web components provide 3 key pieces of functionality: templating, data binding and shadow DOM. The first two are pretty self explanatory, but the shadow DOM is a means of insuring that the scope of CSS styling for a component begins and ends with the boundary of the component. This means that you can’t accidently apply a CSS style on your website that corrupts the look of your component. That said, there are some perfectly reasonable use cases for applying styles across multiple components (i.e. theming) and there is currently a spec underway at the W3C to support theming.
The Polymer includes a command-line interface application called polymer-cli which includes a Node.js Express server, support for building, linting, and minification. The build command can generate highly optimised code that targets specific generations of browsers. So if you’re targeting browsers that understand the ES6 Javascript standard, you can tell your build file to generate the appropriate files. The polymer server is also capable of identifying browser and serving a code bundle appropriate for that particular browser.
Google’s Paper components implement the Material Design 1.0 specification, and the new Material Components (currently in development) support Material Design 2.0. But Google isn’t the only purveyor of Material-compliant components. There are many components that follow the specification created by third parties. The webcomponents.org site contains thousands of components from Google, Vaadin and individual developers which you can easily add to your project.
In addition, the biojs project has a catalogue of web components specifically designed for bioinformatics projects. These open source components developed by academic research institutions include PDB viewers, Cytoscape viewers, sequence annotation viewers and more. There are a couple of caveats with this project: (1) that the components aren’t guaranteed to be material compliant, and (2) the components aren’t necessarily compliant and interoperable with the latest version of Polymer.
The Polymer Starter Kit (which comes as part of the polymer-cli tool) provides you with starter projects that you can quickly adapt to suit your purposes. These templates include a store application, and a Progressive Web App (PWA). PWAs are a set of technologies that allow web applications to be installed on mobile devices and desktops. These technologies include ServiceWorker (an API for caching network requests), and the web manifest (which determines how an application will appear on a mobile device).
Since web components are a Javascript/HTML based standard, this means that you can incorporate them within your existing applications. Moreover, you can create a web application and serve it using any web server. The advantage to this is that the front-end of your web application can be served by an Apache server running in your data center or an NGINX server in the cloud. By separating the front and back-end of your application to create a microservices based architecture, you’re no longer tied to a specific monolithic stack, and thus no longer tied to the long upgrade cycles often imposed on research informatics teams.
REST Services
REST Services are a standard for invoking and communicating with backend services. REST stands for REpresentational State Transfer. These services can persist and query data, and are widely supported in 3rd party LIMS/ELN applications from vendors like Dotmatics, Benchling, Core Informatics and others. This makes it possible for you to combine internal functionality with functionality in vendor-based solutions to better support the needs of your scientists.
You can implement REST services in almost any stack/language: PHP, Java, Grails, Rails, Micronaut, Javascript (Node.js), and Python to name but a few. You can combine web components with REST services to create compelling user experiences.
Tools like Swagger allow you to expose REST service metadata in a manner that can be catalogued in order to improve re-use. There are Swagger annotations for Java, PHP, Rails and Grails that let you annotate a REST service to expose it’s metadata.
Microservices Architecture
With these two pieces in place, your organization can take advantage of a flexible microservices-based architecture that maximises re-use, minimises development time and provides scientists within your research organisation with the best user experience.
Read more of the UX for Life Sciences Series
Need Help Getting Started?
Contact us to learn how we can help you translate your Design Sprints into working software.