Pipeline Stories: Doing The Right Thing

Dimitri and I do a fair amount of travelling, visiting customer sites and working on projects. The companies we visit range in size from small biotech companies with 50 employees to large sites with 300 or more. These companies are all at different points in a project management maturity journey. At some point though, every company realises that they can’t afford 3 hour meetings where no decisions were made, no action items were assigned, and half the attendees couldn’t find the email with the attached pre-reading document.

At this point, organizations usually begin to impose some rules:

  • Communicate the objectives of the meeting
  • No meetings without agendas
  • Limit the attendees to the minimum number required to make a decision
  • No status update meetings (use email)
  • Do meeting prep outside the meeting — no surprises
  • Document the meeting, attendees, action items, decisions to the rest of the team
  • Follow-up at the next meeting, or earlier if necessary

Most of these best practices are familiar to Project Managers through the PMIs guidelines for effective meetings. But it requires a high-level of discipline, and if you have days where your diary is filled with meetings, then finding the time to achieve this level of discipline can be challenging.

Make It Easier To Do The Right Thing

To make it easier, we added Project Meeting support to Pipeline. We listened to customers and realised that they use a variety of tools to set-up meetings, handle invitations, allocate meeting rooms, and setup teleconference bridge details and so forth. So our first goal was not to re-invent those tools, attempt to obsolete them, or integrate with them all. But rather to provide a single place where all the artifacts of the meeting could reside.

If you use Outlook to manage your meetings, then when you create the meeting, you simply add a link to your project’s meeting page in your Outlook calendar entry — just as you might add a Google Hangout link, or a Webex link.

Add agenda items for your meeting. Each item has a Note field associated with it that lets you capture notes for a specific agenda item.

Add the attendees for the meeting. Each attendee has an associated profile that you can use to help better understand the attendees. This means that even if you’re meeting virtually with colleagues that you’ve never interacted with before in person, you’ll feel better prepared, and have icebreaker topics for a conversation.

In the meeting description, let people know the purpose of the meeting. If there are decisions to be made, add them to the Decisions section of the meeting.

Add all of the documents that you want people to review. You can either add a link from your document management system, or if you don’t have one, use PIpeline’s built-in cloud file system. It uses a secure Google Drive that’s only accessible by your company. Check the “Pre-Reading” tick box to let the attendees know that they need to prepare for the meeting by doing the pre-reading.

During the meeting, work your way through the agenda items. Use the Notes feature to capture information on the agenda item. If, during the course of the meeting, you diverge from the agenda, add a Discussion Item and capture the information.

Identify action items during the meeting and assign them as you go. They’ll show up immediately in the project tasks page, and in the task list of the person to whom they’re assigned. If you identify any risks or issues during the meeting, you can quickly capture them. They’re automatically added to your project so you can follow up on them later.

Remember, meetings are a team effort, and this means everyone on the team can capture and share meeting information in real-time using Pipeline’s real-time database. Everyone on the team is engaged in the meeting process, the onus doesn’t just fall on one person to take notes, and manage action items.

And since Pipeline is a mobile-first web application it means that you don’t have to have your laptop with you to participate in the meeting. You can easily add Pipeline to your phone or tablet, by browsing to the site and tapping “Add To Home Screen”.

Moreover, the tangible benefits to the team are shorter, more focused meetings where team members have everything they need to prepare for a meeting. No more being blindsided by meeting prep information buried in an email. Everything that you need for the meeting is in one place and attached to your meeting notification.

Need Help Getting Started?

To find out more about what Pipeline, and what we can do for your research organisation, contact us.

Posted in Drug Discovery, Informatics, Project Management | Tagged , , | Leave a comment

Pipeline Stories: No More Gantt Charts

Pipeline is Aspen Biosciences premiere application for managing drug discovery projects. It started as a simple dashboard for visualising the drug discovery pipeline, and has grown into what some project scientists characterise as “JIRA for Pharmaceutical Projects”. That growth has been driven largely by conversations with scientists who’ve found themselves in the position of having to manage drug discovery projects and needing a tool that was both lightweight and user-friendly.

In the previous series of blog posts, we talked about Design Thinking and how it can be used to create research-oriented software to support drug discovery. In this series of blog posts, we’ll take a look at some of the stories that scientists shared with us, and show you how we translated those stories into new functionality for Pipeline.

No More Gantt Charts
Not too long ago, Dimitri (Aspen’s Chief of Business Development) and I were in the Bay Area to talk to a customer about a project that they had in mind. The company had just had a successful IPO, based in large part on the strength of their lead candidates in the area of fibrosis and cancer. They had moved into new facilities and were executing on their plan to bring a drug into clinical trials.

We sat down with their CIO to learn more about their project. During the course of the conversation though, we learned that they actually had another project in mind for us.

“I’m curious about your Pipeline product,” he said.

“The genesis for the product came as a result of a project we were working on for the site head of a local pharmaceutical company. She had two spreadsheets that the company used to manage drug discovery & development projects, and she wanted a way to combine the project data and visualise the results as single unified pipeline. Every quarter she would hold an All-Hands meeting, and she needed a means of visually communicating the progress the site was making, and recognising the contributions of local colleagues.”

“Since then we’ve completely re-implemented the project using Google’s real-time database known as Firebase. We’ve added target information from sources like EntrezGene, PubMed, UniProt, and the Protein Data Bank. It’s built from the ground up to support mobile, tablets and desktop because we realise that project managers are constantly moving and we need to meet them where they are.”

We did a quick demo for him and started to dig in deeper into their specific needs. “During a meeting with some of the company directors,” he began, ”they were looking for a way of showing project progress. They wanted to know the status of projects and to be able to track tasks. We have a staff of project managers who are using Microsoft Project and the problem is that it’s difficult for them to update. They have to get status update information for each of the tasks and then update the project. So there’s a lot of walking around involved.”

“We want a more participatory approach to project tracking. An approach that lets our scientists track their tasks, and notify their colleagues when a task is complete. This should make it easier for project managers to have a real-time view for the current status of their projects. This frees them up to focus on tasks like managing risks and issues, and planning sprints.”

“But what the directors are really after is a way of seeing when a project’s in trouble, and when it needs help, and they can’t do it from Gantt charts. In fact, one of them said to me, ‘don’t show me another Gantt chart. Just tell me if there’s a problem and what needs to be done to fix it.’”

The Pipeline view is the main entry point designed to meet the needs of the directors you were talking about. It shows them at a glance each of the current projects that you’re working on and where they are in your pipeline. Each project is represented by a single tile that contains the name of the project, the therapeutic class (small molecule, antibody, antisense, CAR-T, etc), and the status of the project (indicated by a green, yellow or red bar). The color of the tile indicates the therapeutic area for the project. When you hover over the project, a brief description appears.

All of the settings, like therapeutic areas, therapeutic classes and indications, (including the icons and colors) are completely customisable. Although Pipeline ships with a standard drug discovery workflow, even that is customisable. So if the focus of your company is cell-based therapeutics, you can change the workflow to meet your needs.

Click on the project to see more detail. So if you want to find out why a particular project is yellow, you can view the project Status Description field to find a more complete answer to your question.

To help spread the workload, Pipeline includes task management tools that make it easy for scientists and project managers to track progress on their tasks. Users can log work against tasks. As tasks are completed, notifications appear in the Activity Feed. Common task sets can be created and used to initialise your project plan with a minimum amount of work.

A task view helps the bench scientist understand what’s on their plate and helps answer common questions like “what do I need to accomplish this week”. Pipeline has both a cross-cutting view that shows the user all tasks assigned to them across all projects, and a project specific view, that shows all tasks for a given project.

Need Help Getting Started?
To help you quickly transition to Pipeline, we also provide an on-boarding service to get your projects, targets, documents and tasks into Pipeline and to train your staff. To find out more about Pipeline, and what we can do for your research organisation, contact us.

Posted in Drug Discovery, genomics, Informatics, Project Management | Tagged , , , | Leave a comment

Pipeline Stories: A Scientist Walks Into A Bar

Pipeline is Aspen Biosciences premiere application for managing drug discovery projects. It started as a simple dashboard for visualising the drug discovery pipeline, and has grown into what some project scientists characterise as “JIRA for Pharmaceutical Projects”. That growth has been driven largely by conversations with scientists who’ve found themselves in the position of having to manage drug discovery projects and needing a tool that was both lightweight and user-friendly.

In the previous series of blog posts, we talked about Design Thinking and how it can be used to create research-oriented software to support drug discovery. In this series of blog posts, we’ll take a look at some of the stories that scientists shared with us, and show you examples of how we translated conversations into new functionality for Pipeline.

A Scientist Walks Into A Bar

Here in San Diego we are blessed with a number of organisations designed to help the entrepreneurial scientist translate their ideas into businesses. One of these organisations is the San Diego Entrepreneur Exchange (SDEE). Every month they host a Happy Hour meeting at a local microbrewery. It’s a great way to unwind, and network, and for us it’s a great way to meet scientists and listen to their stories.

Photo from the recent Portfolio & Project Manager’s Meetup

At one such gathering a few years ago, I ran into a Director of Discovery Biology at a small drug discovery company (let’s call her Jane — not her real name, gender or title). I introduced myself, and mentioned that I write software for drug discovery and since I’ve always been interested in the process and tools that companies use to select their targets I wanted to learn more about how they selected targets at her company.

Jane’s company, is a small drug discovery company with about 50 scientists on staff that had been in business for over 14 years and had successfully partnered with larger companies to get their drugs to market before finally being acquired. Even after the acquisition though, the company still continue to function as though it were a small biotech. So I was interested to hear how they managed the target selection process in this blended environment.

I began by asking her how the target selection process had changed over the years. “What tools are you using now to manage the drug target selection process?”

“A few years ago we bought a license for a product by a local company. [I’ve omitted the name to protect the innocent]. The product has changed hands over the years and it’s become almost a kitchen sink application.”

“One of the things they tout, is that ‘we do all the homework for you, so you don’t have to. We go to all the conferences. We research all of the targets and the pathways, we curate all of this information for you and save you all that time and money. And for all of that we charge $50,000 a year’.”

“And while I appreciate the amount of work that goes into curating all of that information, it’s a little disingenuous to imply that we can simply delegate that work to them and hope that they’ve done it properly. We still need to research those targets ourselves, we do a deep dive into the target and the indication. We look at disease biology, we look at clinically relevant variants, we look at a half-dozen pathway databases. We look at specialist databases like COSMIC and TCGA (The Cancer Genome Atlas) for specific cancer indications. We look to see what drugs are in development for the target. We do literature searches in PubMed and read lots of articles. We go to conferences, we create internal target profiles, and presentations. But $50K is still pretty steep for something that only one person might use 2-3 times a year, and for work that we’re going to do anyway. $50K would keep us in reagents for a few months. We could buy another microscope — something we’d use every day.”

“So what were you doing before? How were you organising the information,” I asked.

“We used PowerPoint and SharePoint for a while. We’d create a presentation template to help us pull the information together. You still have to go to all of the sites, review the information and curate it. But at least the information was curated in a single consistent format. ”

“What made you switch from SharePoint,” I asked.

“With SharePoint, only one person at a time could work on the target profile. We have a number of people in our group and we needed to divide the work between us. But splitting the work up between the members of the team had its consequences as well. When we were first getting started, we realised that we weren’t doing consistent searches in PubMed. Now we teach target reviewers to do searches consistently. They can still create their own custom searches, but we want to make sure that there’s at least a minimal set of searches being done, and that the search criteria are consistent from project-to-project. ”

“But the real problem with SharePoint was that it didn’t understand biology. We wanted to know the Gene Ontology terms for the target. We want to know about the domains that the target has. We want to know which pathways a target plays a role in. We wanted to be able to look across our portfolio at our projects see if there were similarities between projects that we’d already worked on.”

“And now? With your new application? Do you feel that those issues were addressed” I asked.

“To be honest it feels like we’ve traded one set of problems for another. We see these curated views, that aren’t editable. We can’t emphasize that this subset of the available information is pertinent to our project, and this other set isn’t. We need a better alternative.”

Translating The Conversation Into Code

One of the key requirements that Jane shared with us was the need to provide a single point of entry for a project. There needed to be a way to import target-related data from multiple sources to create a single curated view of the target. To do this, we implemented a search tool that lets the user easily import data from UniProt, PharmGKB, EntrezGene, PubMed, Protein Data Bank, ChEMBL and many other sources with a single query.

Documents and Presentations
In Jane’s company they use Google Docs to collaborate on documents, presentations and spreadsheets. They made the switch to Google Docs after a particularly tense day when a team of researchers were trying to prepare a presentation highlighting results from their latest project. The problem was they were attempting to collaborate on the same presentation by sending copies of it back and forth by email. Versions of the document were getting muddled, slides which had been added, disappeared in the next version, back and forth it went and tensions began to rise.

Cloud-based office applications like Google Docs and Office 365 have become more ubiquitous in pharmaceutical companies over the years but in many cases users aren’t made aware that they can actually simultaneously edit a document. At Aspen, Dimitri and I use this feature to collaborate on proposals and presentations while chatting with colleagues in San Francisco or Boston.

In both Google Docs and Office 365, users store the URL for the document in Pipeline so that they can easily get to the information they need. Document-level security is managed by either Google or Microsoft.

In scenarios where a document is authored by a single user, the document can be uploaded into a private Google Drive that is part of Pipeline’s backend infrastructure. In cases where the customer uses a document management system for sharing, signing and managing document workflows, users can publish the URL for the document in Pipeline along with document metadata such as a title, description and tags used to classify the document.

Pathways, PubMed and More
A significant portion of Jane’s time is spent in portfolio management. In many companies with large drug development organisations, the focus of portfolio management is financial, competitive and logistical. In drug discovery, the focus of portfolio management is primarily scientific and can be boiled down to two questions – what is the role of this target with respect to the indication, and how amenable is it to therapeutic intervention.

To answer these questions requires information from a variety of different sources to be integrated.

  • EntrezGene is an NCBI database of genes and their sequences, sequence annotations and functions.
  • ChEMBL is a database of targets and drugs created by the EMBL. Information from this database tells researchers about the drugs currently available or in development for a given target
  • GeneRIF – these References Into Function provided by NCBI’s EntrezGene database, are a collection of papers that describe the role of a gene with respect to a variety of different indications.
  • UniProt – is a database that contains information about proteins and their functions.
  • OMIM – is the Online Medelian Inheritance In Man database contains information about genes and their roles in various indications.
  • Protein Data Bank (PDB) – is a database of protein structural information that provides researchers with 3D models for drug targets.
  • Gene Ontology information which describes the biological function, molecular function, and cellular localisation of genes and their protein products.
  • PharmGKB is the Pharmacogenomics Knowledge Base which contains information about the target and how existing variations affect the efficacy of known drugs
  • PubMed – is a massive database of millions of academic papers
  • Pathway information from sources like KEGG, Pathway Commons, WikiPathways and the NCI’s Pathway Interaction Database are used to help researchers understand the role of the target with regard to biological networks.

By providing all of this information in a single place that was easily curateable by project scientists, Jane’s team was able to create the kind of collaborative working environment that she had been looking for. And the Pipeline Stats View let her look at projects across her entire portfolio for areas of commonality that they might be able to exploit.

Need Help Getting Started
To find out more about what Pipeline, and what we can do for your research organisation, contact us.

Posted in Drug Discovery, Informatics, Project Management | Tagged , , , , | Leave a comment

Translating Design Thinking Into Solutions

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.

Need Help Getting Started?
Contact us to learn how we can help you translate your Design Sprints into working software.

Posted in Bioinformatics, Informatics | Tagged , , , , , | Leave a comment

Design Thinking In Drug Discovery

In the previous blog post, I showed the importance of good UX design to research organizations; and how the Design Thinking process created at Google Ventures helps users, designers and developers quickly narrow down a list of potential solutions, and focus on the best solutions. In this post, we’ll take a look at how the Pistoia Alliance’s UX for Life Science (UXLS) working group is applying these methodologies to solve research-related problems.

The UXLS working group draws its members from pharmaceutical companies like AstraZeneca, Amgen, Bayer and GSK in addition to numerous technology vendors. And these members have contributed case studies, templates and best practices from their own projects to create the UX for Life Sciences Toolkit. The toolkit was a finalist for this year’s Bio IT World Innovation Best Practice award.


UX for Life Sciences
At the heart of the Design Thinking methodology (and UX for Life Sciences for that matter) is this iterative three-step approach for problem solving that in many ways resembles agile and lean development (albeit without the code). Define the problem (via user research), prototype a solution, evaluate the solution with users and repeat. With each iteration you narrow your focus on the problem and get closer to achieving an optimal solution.

Within each of these activities the toolkit provides a host of best practices and templates geared towards helping life science companies apply Design Thinking principles in their projects.

User Research

Task Modeling – a process for understanding the tasks that the user is trying to accomplish. Similar to Alistair Cockburn’s Use Case modeling methodology.

Personas – a process for identifying different types of users, and identifying differences or similarities with the way in which they interact with a system/execute a process. For example, you might look at how a biologist performs a literature search during target selection and compare that to how a chemist performs a literature search to better understand the chemistry space for the target.

Contextual Inquiry – using direct observation of scientists as they work to better understand the business process and identify needs and opportunities for improvement.

User Interviews – using conversations with scientists to better understand the goals, process, and needs of scientists.

Jobs To Be Done – an approach to identifying high priority opportunities for improvement.

UI Design

Card Sorting – A process for getting direct feedback from users, designing user interfaces, prioritising opportunities, and understanding the user’s perspective.

Prototyping – a process for rapidly and economically turning ideas into prototype user interfaces.


System Usability Scale – metrics used to measure the usability of a product or service based on user feedback.

UX Metrics Using HEART – a set of metrics developed by Google for evaluating the usability of prototypes.

Need Help Getting Started?
Contact us to learn more about getting started with Design Thinking and UX for Life Sciences.

Posted in Bioinformatics, Informatics | Tagged , , , | Leave a comment

Why UX Matters In Drug Discovery

In commercial software development, the most successful applications are often the ones where the vendor has invested the time and effort to design an engaging user experience. That user experience transcends the widgets you put on the screen, and encompasses critical success factors like:

  • Reduced cycle time – reducing the amount of time required to advance a discovery project from target identification through to pre-clinical testing.
  • Fit-to-function – how well does the application fit the requirement
  • Fit-to-flow – how well does the application fit the workflow that we use. Do we need to spend time entering data into multiple systems?
  • Ease-of-use – how easy is it for scientists to start using the application
  • Reduced training time – how much time is required to be fully conversant with the application, keeping in mind that the lab may have GLP training requirements for software.
  • Reduced rework – reduce the number of times that an internally developed application must be reworked to suit the needs of the scientists.
  • User satisfaction – increase user satisfaction and decrease frustration
  • Increased bench time – decrease the amount of time spent entering data, and increase the amount of time spent at the bench.
  • Aesthetics – studies of computer-human interaction have found that an aesthetically pleasing user interface can reduce work-place stress. Sometimes the user experience can be so compelling that scientists are willing to overlook the fact that the application doesn’t actually cover a significant portion of their workflow.
  • User interface consistency – by making the user interfaces for internal applications consistent with one-another, you can reduce training time.

The flip-side of these metrics reflect the ways in which a poorly designed UX can affect productivity and even retention. The applications that scientists use every day are often seen are a reflection of how seriously the company values science and scientists. A poorly designed user experience can result in duplicate work, lots of manual entry work, or manual transformation of data from one form into another in order to get the data into another system.

The 1990s Called And They Want Their UI Back
Millennials have certain expectations about the software they use, based in part on the social media and mobile applications they use every day.

  • They expect it to be easy to use.
  • They expect it to be as familiar to them as the other mobile applications they use.
  • They expect to be able to use it on a range of devices (known as responsive design).
  • They expect to be performant. They want interact with it without having to go through multiple page loads.
  • They expect it to notify them when a lab process has completed (a robot has finished replating samples, or a sequencer has finished its run).
  • And they expect to be able to interact with the system while wearing having personal-protective equipment like goggles and gloves.

UX In Pharmaceutical Companies
In pharmaceutical companies, we have traditionally seen User Experience (UX) practices applied in customer-facing web applications not internally developed research applications. The traditional business rationale for putting additional effort into UX is that a well-designed web or mobile patient-engagement application can result in increased patient compliance with medications, improved customer satisfaction, and increased sales, in addition to simply making patients aware that new treatments for their indication exist. Taken as a whole, these metrics constitute measures of “customer-solution fit”. And while they have a direct bearing on profitability, but also have an important bearing on how the company is perceived by both patients and potential future employees.

Beyond web applications though, we’re now seeing UX and Design Thinking practices applied in everything from clinical trial design to manufacturing and packaging. The ultimate goal of these practices though is to provide a more patient-centric focus.

As we’ll see later on in the article, these UX practices are beginning to filter down to pharmaceutical research organizations in some new and interesting ways. We’re translating the expectations of research communities into applications that fit the way they work.

How seriously do pharmaceutical companies take UX Design?
Seriously enough that companies likes GSK, Novartis, Amgen, Roche, Merck and AstraZeneca all have Centers of Excellence or Communities of Practice for UX Design. In addition, these companies are working together through the Pistoia Alliance to develop a common pre-competitive toolkit for UX design through a program called UX for Life Sciences.

The toolkit contains processes, templates, case studies, and best practices for creating new compelling user experiences, and improving the user experience in existing scientific software. And although we might use this in the context of software development, the same processes have been used by the group to solve problems in logistics, laboratory design, material handling/inventory, and lab operations.

The group borrows from the Design Thinking practices first developed at Google Ventures and taught at Stanford’s d.School (one of the country’s most prestigious design schools).

Design Thinking
The Design Thinking process in use at Google, Adobe, Mayo Clinic, Kaiser Permanente, Pfizer, Novartis, Roche/Genentech and many other companies follow is a 5-step exercise which brings together subject matter experts, UX design, and development experts into a single room to focus on solving a challenging business problems. And although there are a number of implementations of Design Thinking practices, these companies have chosen Stanford’s d.School approach in-part because it’s so well documented, and training videos are available on YouTube.

Design Thinking helps us use what we know about our customers and business processes to design new and compelling solutions that fit their needs. The 5 steps of the process are:

Empathise – Learn about your business process and participants to the point that you understand their priorities, biases and problems.

Define – Define the problem to be solved.

Ideate – Identify as many potential solutions as possible that solve the problem. Sketch what those solutions might look like, and storyboard how a user might interact with them.

Prototype – Create a crude prototype solution using simple tools like Keynote or PowerPoint.

Test – Have the users evaluate the prototypes and provide feedback

Then continue to iterate on the last two steps until you have a prototype that best fits the need. At some point during these iterations, you’ll transition from a Keynote/PowerPoint prototype to code.

The explainer videos below gives you a brief/long overview of the process.

Design Sprints
One of the most common implementations of Design Thinking is a process called the Design Sprint. Similar to development sprints that you see in agile software development organizations, a Design Sprint is a 5-day, time-boxed process for quickly developing and evaluating prototypes that resonate with the end-user. A typical Design Sprint looks like this:

Day 1

  • Start At The End – Identify the business goal(s) that you’re trying to achieve.
  • Map – map the process. For example, if your goal is to develop a more efficient process to create antibodies (and the software needed to achieve it), then your map would include the people, process steps and technologies currently in use to make that happen. This map provides a common reference point and vocabulary for all of the participants in the process. You can also use this part of the exercise to identify the parts of the process that are slow, user intensive, or just plain broken.
  • User Interviews – At this point, subject-matter experts help you flesh out the details behind the steps in the process. Everyone in the meeting will be focused on taking notes, and asking questions.
  • Choosing A Design Target – After mapping out the process, the team selects a single target user and event that will become the focus for the rest of the design sprint.

Day 2

  • Remix and improve – identify features in existing solutions that you like, and demo them for the rest of the team, and collect the best features on a whiteboard.
  • Sketch – Using the some of the previously demonstrated features as “grist for the mill”, the team members begin sketching new solution ideas.

Day 3

  • Decide – Review the sketches and select the solution(s) that best solve the problem.
  • Rumble – If you have multiple solutions, then the best way to compare them is to prototype both of them during Day 4, and review the results on Day 5.
  • Storyboard – Storyboard each of the solutions. Each storyboard walks the user through the business process/scientific process that you want to support.

Day 4

  • Prototype – prototype the storyboards using Keynote or PowerPoint.

Day 5

  • Evaluation – review the resulting solutions with subject-matter experts.

You’ll also find this podcast (entitled “Design Thinking For Clinical Trials“) useful for seeing how Design Thinking has been applied to design more patient-centric clinical trials.


More Reading


Need Help Getting Started?
Contact us to learn more about how you can apply Design Thinking in your research organization.

Posted in Bioinformatics, Drug Development, Informatics | Tagged , , , | Leave a comment

Pharma Webcasts

In the previous blog posting I listed some of the podcasts that make it easier to stay on top of the changes that drive the pharmaceutical industry.

plenaryThere are a number of conferences and societies that provide webcasts of their sessions, in addition to podcast content. These are really useful when you can’t make it to a conference, or can’t make it to 3 sessions scheduled at the same time, or can’t make it to the conference at all. The webcasts are also useful for Lunch and Learn sessions. You can book a conference room, and get together with a number of colleagues at lunch to watch the sessions over a period of several weeks. This has the added benefit of stimulating some interesting conversations and creating a sense of teamwork.


The AACR provides an extensive library of the sessions given at it’s conferences. Many of the sessions are free and don’t require membership in the organization. In addition, the organization’s YouTube channel has interviews with selected speakers from their conferences.


Similarly, the ASCO YouTube channel has a number of interviews with selected speaker as well as previews of the upcoming annual meeting, and brief explainers of some of the major programs like CancerLinQ.


ASH provides a library of audio and video content from their conference.

Bio IT World

Bio IT World provides a selection of talks from their annual conference on their YouTube Channel. In addition to these talks, there are short interviews with Best In Show winners in a variety of categories.

Cambridge Healthtech Institute

The Cambridge Healthtech Institute (CHI) puts on a number of conferences (including Bio IT World, PEGS, Peptalk, Oligonucleotide and Peptide Therapeutics, Biomarkers and Immuno-Oncology World, Next Generation Dx and more. The CHI YouTube channel has many of their talks as well as interviews some of the key speakers from each of their conferences


ESMO’s YouTube channel contains a series of short interviews with leading oncologists in addition to conference highlights.

Posted in Uncategorized | Leave a comment