Peer to Peer Magazine

18 based on a limited understanding of available tools, the overall cost of development or the ongoing obligations to maintain the solution. The stakeholder may also be biased about actual marketplace demand. With the risk of up-front cost (in time and money), it is imperative to truly understand the problem that the product would solve. Drilling down on the "why" of the solution and empathizing with your future user(s) and customers can help to define the actual need and broaden the universe of possible solutions. (consider a technique like "how/why laddering" or Design Thinking tools in the d.school bootcamp bootleg, such as Interview for Empathy.) While the viability of legal products will vary, certain characteristics lend themselves to packaging more than others. These characteristics include,for example, workflow/analyses that are similar from client-to-client, high-volume work, work with known pricing pressure, areas of law that are relatively established or with infrequent legal developments, and of course areas where clients have frequently voiced needs for alternative solutions. While there are ways to design around difficult areas (e.g. isolating the problem areas to simplify updates), the product is easier to design and more likely to succeed the more it meets these criteria. Fleshing out the context around the potential product (e.g. determining how the need fits into a broader workflow) can elucidate other possible users/stakeholders, alternative use cases and establish an overall vision for the product. Consider if the solution is scalable to or impacts other practice areas, industry groups or additional clients and, if so, how and when to engage these groups so that you receive meaningful input. Formally defining these foundational aspects of a solution (such as in a formal vision statement; use cases - generic descriptions of scenarios in which the product will be used; and/or personas - descriptions of different roles using the product, including why and how they will use the product) establishes a compass to help guide future product decisions. For example, during the development of the Navigator OT product for ComplianceHR (Littler's joint-venture with Neota Logic), we debated the importance (with respect to other features) of the ability to use the app to perform audits. We referred back to our use cases and personas and determined that the audit use was critical to the users. By contrast, with the Navigator IC product, we made the assumption that, if there was an obvious result early on, users would want to end the app early, which led to significant effort dedicated to the substance, design and implementation of this feature. However, once launched, we found that most users preferred to just gather all information at once (as opposed to getting a quick answer and potentially having to come back and rerun the app). Although this feature is still used, it's not as central of a feature as originally anticipated. Had we spent more time on user and use-case analysis (or prototyping and testing the feature with users, see below), we may have properly prioritized the feature lower on our list (and possibly included other features that didn't make the initial cut). One best practice that we have both learned is to start small. In contrast to large- scale technolo deployments, start with a small group of stakeholders and potential customers to test out viability and then add customers, stakeholders and features over time (iterated as many times as needed). This can reduce the initial risk, lead to a more cohesive product and develop a better understanding of the marketplace. Not only does this strate give you the freedom to partner with willing and excited stakeholders and customers, but it also provides a mechanism to help reduce uncertainty in development. Design and Development With the foundation established, you'll need to start breaking down the legal workflow/ analysis and develop a high-level design. Depending on the problem/solution, there are a number of tools to deploy: process mapping when addressing workflows and other process-oriented solutions; decision trees for mapping out legal analysis; and requirements-gathering methodologies to inform key functionality. Conceptualizing these workflows or analyses as a series of stand-alone pieces that can be assembled as a solution (as opposed to one monolithic solution) makes prioritization easier and decreases the maintenance burden. Breaking the design into stand-alone pieces helps enable planning certain pieces for later phases and/or clarifying areas where a "human solution" would be warranted. H O W T O I N T E R V I E W F O R E M P AT H Y: Ask why. Even when you think you know the answer. Never say "usually" when asking a question. Instead, ask about a specific occurrence. "Tell me about the last time you ____." Encourage stories. Stories reveal how users think about the world. Look for inconsistencies. What users say and do can be different. These inconsistencies often hide interesting insights. Pay attention to nonverbal cues. Be aware of body language and emotions. Don't be afraid of silence. When you allow for silence, you give users time to reflect on their answers—which may lead to deeper responses. Ask questions neutrally and don't suggest answers. "What do you think about buying gifts for your spouse?" is better than "Don't you think shopping is great?" https://bit.ly/2AFEBYD

• Cover