Peer to Peer Magazine

P E E R T O P E E R : I L T A ' S Q U A R T E R L Y M A G A Z I N E | S P R I N G 2 0 1 9 19 Direct involvement of SMEs is critical in early analysis stages. For example, in response to growing data privacy regulations, Perkins Coie built an application to help users determine if they are subject to certain regulations and to provide general steps organizations should consider. SMEs mapped out all possible fact patterns and connected them to conclusions and explanatory content that the user receives. This was translated into if/then logic for design of the application. Additionally, including potential users early can inform product direction. While building a custom product for a client, Perkins Coie attorneys, technologists, and project managers met regularly with a subset of the eventual users to walk through how they would interact with the product and how it would impact their own internal processes. Combining these observations with SME knowledge led to a more user-centric product. It also helped to socialize the product and facilitate organic user adoption. Many legal products will have to design around varying degrees of uncertainty. While attorneys are commonly applying legal analysis to a single set of facts, when packaging legal analysis, you have to design results for all possible fact patterns. It's not uncommon to encounter parts of analyses or particular fact patterns that are out of the ordinary or even peculiar, but nevertheless they have to be mapped to some result. Moreover, much legislation and case law contains ambiguity that will remain ambiguous unless and until clarified by a regulatory agency, legislature or a court. For example, new paid sick leave legislation will often contain ambiguities that have to be clarified by the relevant agencies. However, Littler needs to keep the paid sick leave information in relevant apps current while waiting on agency guidance. Providing more information about the uncertainty as well as acknowledging that the area of law is unclear (and/or recommending consultation with an attorney) is sometimes the best option in these instances. Building early proofs of concept (POCs) or prototypes can provide something tangible to help elicit feedback from users and shore up uncertainty. POCs and prototypes are not fully fleshed out products and need not even involve your ultimate choice of technolo; rather, they should address core functionality or test specific assumptions. For example, in developing applications for ComplianceHR we tested some legal analyses by producing a visual decision tree, or creating preliminary algorithms (and testing them in Excel, for example), and walking through fact patterns with SMEs. POCs can also be beneficial for uncovering gaps in processes/logic, exposing dependencies and identifying limitations with tools/applications. While designing and gathering feedback, it's important to prioritize functionality and continuously identify which functionality is critical for initial launch (the minimum viable product or MVP) and which functionality can wait for a later iteration. Particularly with legal products, an MVP should be as conservative as possible; user/stakeholder needs often shift after using the product and unused functionality impacts how soon the product can become profitable (not to mention technolo products are notorious for implementing costly, unused functionality). "Stack ranking" (creating a strict, ordered list from most important to least important functionality in a backlog) is a useful way to allow stakeholders to choose between pieces of functionality when it's otherwise difficult to convey the true cost, complexity and value. After you've launched the product, you can re-evaluate the backlog priorities, taking into account direct user feedback, application metrics and other data. Once you have designed and developed the MVP, you'll also need to plan for several levels of testing. Your design and requirements documentation serves as a useful guide for testing and acceptance criteria. After you've polished the product with several levels of testing, consider planning end-user testing as it may identify easy areas for improvement (see Rocket Surgery Made Easy by Steve Krug for a pragmatic guide on usability testing). Furthermore, just as in earlier stages, feedback should go into your backlog to determine if it is necessary for launch. Sustainment and Support As mentioned above, you should be planning support from the beginning. Some considerations to keep in mind: • What levels/types of support will the product require? • Who do the users contact with questions/issues? How is this tracked and responded to? Is there an escalation process for technical issues? Legal issues? • Is there legal content within the product that needs to be kept up-to-date? What's the process for this? • Are there technical pieces that have to be maintained and/ or repaired? Who is the point person for this? Who manages third-party issues? F E AT U R E S U S E D I N C U S T O M A P P S 2 0 % O F T E N 3 0 % I N F R E Q U E N T LY 5 0 % H A R D LY E V E R https://www. standishgroup.com/ sample_research_files/ Modernization.pdf

• Cover