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 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.
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.
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.
Companies like BBVA, Comcast, Google, ING, USA Today and others are using web components. In the pharmaceutical industry,
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.
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).
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.
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.
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.
Need Help Getting Started?
Contact us to learn how we can help you translate your Design Sprints into working software.