{"id":8061910,"date":"2020-06-01T14:04:16","date_gmt":"2020-06-01T21:04:16","guid":{"rendered":"https:\/\/test-agilealliance.pantheonsite.io\/?post_type=aa_experience_report&#038;p=8061910"},"modified":"2023-12-04T13:21:21","modified_gmt":"2023-12-04T21:21:21","slug":"your-security-team-needs-design","status":"publish","type":"aa_experience_report","link":"https:\/\/agilealliance.org\/resources\/experience-reports\/your-security-team-needs-design\/","title":{"rendered":"Your security team needs design"},"content":{"rendered":"\n<figure class=\"wp-block-embed is-type-video is-provider-vimeo wp-block-embed-vimeo wp-embed-aspect-16-9 wp-has-aspect-ratio\"><div class=\"wp-block-embed__wrapper\">\n<iframe src=\"https:\/\/player.vimeo.com\/video\/440873915?h=5bdcde128a&amp;dnt=1&amp;app_id=122963\" width=\"800\" height=\"450\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture\" allowfullscreen><\/iframe>\n<\/div><\/figure>\n\n\n<p>When rolling out a new security product, engaging the services of an experience designer is not often front of mind. This is a story about why it probably should be, and for us, will be in future.<\/p>\n<h2>1.\u00a0\u00a0\u00a0\u00a0 Introduction<\/h2>\n<p>As a designer I\u2019ve mostly worked on designing software, campaigns or screen flows. I often look at things around me and think that \u2018this can be better\u2019. Anything from how a shop is laid out to garbage bins and customer support. I believe that anything can and is designed, just by more or less intent. Design has many definitions and one of my favourite ones comes from Jared Spool and is \u201cDesign is the intentional rendering of intent\u201d<em>\u00a0<\/em>(Spool, 2013) and this \u201cintention\u201d can be applied to anything we see around us. I recently had the chance to put this idea to the test at the software company ThoughtWorks. When I was asked to help with what should have been a simple security problem.<\/p>\n<p>As a security professional, responsible for access and authorisation at ThoughtWorks, I spend a lot of time being very worried. The potential impact of a data breach is unthinkable, organisational reputations built up over decades, can be utterly destroyed in minutes. The most frightening part is that many security incidents are not the result of sophisticated hacking, they happen because someone was in a hurry and simply made a careless mistake.<\/p>\n<p>Password managers are a common solution to this problem, and for various reasons, we assumed they were widely used at ThoughtWorks. However, analysis completed in 2018 challenged these assumptions.\u00a0This meant that it was\u00a0imperative to make the idea of using a password manager more attractive to ThoughtWorkers.<\/p>\n<p>This story outlines how a cross skilled team in a couple of weeks used design thinking methods to redesign and implement a new process for rolling out a password manager. As an unexpected bonus the team also changed some mindsets about what design can do and how powerful the design thinking tools can be.<\/p>\n<h2>2.\u00a0\u00a0\u00a0\u00a0 Background<\/h2>\n<p>To start this story, we have to go back a bit in time and first take a look at the world from the perspective of the Identity Team, who are responsible for password security at ThoughtWorks.<\/p>\n<p>The average business user has up to 191 passwords to manage. Approaches like Single Sign On (SSO)\u00a0(Single Sign On, 2020) can help to reduce this load, but at the same time, having only one password to access multiple resources, increases the criticality of that password being both strong and unique. Many organisations including ThoughtWorks address this by specifying complexity requirements and cycle times for corporate passwords. However, the 2018 National Institute for Standards and Technology (NIST) (Paul A. Grassi) guidelines argue for a different approach (Stocker, 2017). NIST proposes that complexity requirements and short cycle times for passwords should be replaced with greatly increased requirements for password length, much longer, or no cycle times and support for approaches such as diceware to generate passphrases.<\/p>\n<p>Following the release of the 2018 NIST special publication, we were keen to update our password requirements to meet the new guidelines by removing complexity, increasing the minimum password length and reducing cycle time. Since we had always had a policy which provided employees with the ability to reimburse the purchase of a password manager of their choice, we assumed that password manager use was common, and that requiring a much longer password would be no impost.<\/p>\n<p>We wanted to find out, so we conducted an internal poll in mid 2018 to help us understand the attitude towards password managers in the organisation. The self selected survey, showed a fairly high usage with an 80% uptake in the Americas, Europe and the Asia Pacific, region and a much lower number only 40 to 60% in India and China. The most common reason given for not using password managers is that it\u2019s not seen as needed. Other examples of reasons to not use a password manager were usability issues, cost of the software, or that people relied on memory. Yikes! Another problem we uncovered was that although we had a global policy supporting the reimbursement of costs for a password manager, it was not well understood. Further, the policy was inconsistently communicated from region to region, we did not make any recommendations about which product people should purchase, or which expense code should be used, making it difficult to really understand how much we were spending. We were not sending the message we wanted to send to ThoughtWorkers, and this was potentially putting us at risk.<\/p>\n<p>It was clear we needed a different approach. We initiated a conversation with several password manager vendors and it quickly became evident that it would be more cost effective to use our purchasing power to provide all staff and their families with a password manager at no cost and invest our effort in encouraging them to use it. We would simultaneously remove the existing lack of clarity around policy and expense codes and improve the overall security posture of ThoughtWorkers and their families. We spent considerable time developing a set of instructions and communications artefacts, and with great fanfare, we went live.<\/p>\n<p>Our process required people to register with our corporate password manager product, in order to redeem their free product. Almost straight away, many people ran into problems doing this resulting in an avalanche of support tickets taking valuable time away from the Identity Team. Many people unintentionally started using the corporate account which led to licensing issues with the account. One person who did this accidentally and unintentionally shared their passwords in a place where other people in the organisation could access them. Something needed to be done straight away. So the Identity team called for help from our experience design community, thinking that they might help us tweak our communications and instructional artefacts.<\/p>\n<h2>3.\u00a0\u00a0\u00a0\u00a0 Enter the Designers<\/h2>\n<h3>3.1\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Human centred security?<\/h3>\n<p>To start chipping away at the problems we needed to use a different set of tools and processes than what was usually found in the engineering toolbox. At ThoughtWorks we commonly use design thinking methodologies and human centred design practices for our clients and to solve this problem we decided to use the methods on ourselves. We used the common Double Diamond Framework from the British Design Council (The British Design Council) and the hexagons of Design Thinking by Stanford d.School, (D.School Stanford, 2020) describing the different stages of the design process.<\/p>\n<h3>3.2\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 The full story<\/h3>\n<p>To solve this problem we first of all needed a team. A call was given to the organisation and three people put their hands up to help. I was one of the volunteers and together with two more individuals we started. The team had varying experiences with design practices but what they all had in common was:<\/p>\n<ul>\n<li><strong>Purpose<\/strong>. Having a clear reason to work together. This was created by having clear understanding of what the problems were and how this impacted both the business and the customer (in this case the employees of the organisation).<\/li>\n<li><strong>Mastery<\/strong>. Not all of the team members were experts, but we had enough expertise to be able to perform the task at hand.<\/li>\n<li><strong>Autonomy<\/strong>. The ability to decide for themselves how the problem should be solved.<\/li>\n<\/ul>\n<p>This kind of way to structure teams for motivation is very well articulated by Daniel Pink in his book\u00a0<em>Drive<\/em>.<\/p>\n<p>We used the Design Thinking process as defined by Stanford Design school:\u00a0<strong>empathise, define, ideate, prototype\u00a0<\/strong>and<strong>\u00a0test<\/strong>\u00a0as a framework for our process together with Hypothesis Driven problem solving. These methodologies are not necessarily new, but the purpose of this story is how we made it work in a real-world example.<\/p>\n<p>Throughout the work which lasted about three weeks we followed a few unspoken principles. These principles are all inspired by\u00a0lean practices which can be found in many places. One is\u00a0<em>Lean UX<\/em>\u00a0(Gothelf, 2013) who states that teams need to \u201cfocus on the actual experience being designed, rather than deliverables\u201d. The second one is\u00a0<em>Lean Thinking<\/em>\u00a0(Womack, 2003), where the core idea is to \u201cmaximise customer value while minimising waste\u201d. I say unspoken because we didn\u2019t create these principles together or made them visible in any way. It\u2019s when I look back at the work, they become clear. There is no one place where the following exact principles can be found, however it roughly describes how the team was structured and the core values of how we organised the work.<\/p>\n<p><strong>Focus on root cause.<\/strong>\u00a0Solve for the true reason for the problem over band-aiding the symptoms.<\/p>\n<p><strong>\u201cWinning the lottery\u201d<\/strong>\u00a0Documenting is important however only do the amount that supports the case of a team member suddenly leaving because they\u2019ve \u201cwon the lottery\u201d. Very often in a consultant world we can at any time get staffed on a client or get pulled into last minute proposals. We were therefore working on the basis of \u201cif one of us wins the lottery\u201d and is out the door the next second. All of our documentation and our process reflected this bare minimum to support decision-making and enough context without creating big reports.<\/p>\n<p><strong>Anyone can do any task<\/strong>, with help from the expert. We aren\u2019t limited by who is available or not available.<\/p>\n<p><strong>Go and see.<\/strong>\u00a0Experience it yourself and feel the pain of your customer is the most valuable insight. Going to where the customer is to watch and listen to them to fully understand their problems was central to what we were doing.<\/p>\n<p><strong>Visualise the work.\u00a0<\/strong>Make the work we were doing visible to everyone involved at all times.<\/p>\n<p><strong>Remove the unnecessary.<\/strong>\u00a0Simplify until you can\u2019t simplify anymore.<\/p>\n<h2>4.\u00a0\u00a0\u00a0\u00a0 our approach<\/h2>\n<h3>4.1\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Empathise with the current state<\/h3>\n<p>To get as close as we could to what our customer was experiencing, in order to fully understand where the problems and symptoms were located. Only solving the symptoms would possibly make the situation worse so we really needed to understand what our users were going through.<\/p>\n<p>We did an \u201cexpert walkthrough\u201d of the existing process with a User Experience Designer making notes of possible points of confusion. We then performed one-on-one interviews with people in Australia, during which we measured the time it took them to finish the setup and any point where they were struggling or needed help.<\/p>\n<p>We visualised all this information in a User Journey map for the different user types. We captured actions they took and any observations the test facilitators were making during the interview. After four interviews we started to see patterns emerging. For example, clicking on links that took people down the wrong path.<\/p>\n<h3>4.2\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Define the problem space<\/h3>\n<p>After having mapped out the user journeys we found we could simplify our five user types down to one with a slight variation.\u00a0When we moved on to writing problem statements we used the framing question of \u201cWhat is wrong with what?\u201d and prompts like: \u201cLack of\u2026\u201d \u201cNot enough\u2026\u201d, \u201cToo much\u2026\u201d.<\/p>\n<p>At this point we started to \u201csketch out\u201d problems and plotted them according to what was inside our control and outside our control. This was our \u201cwhat our circle of concern\/influence\u201d actually looked like. This model is used in personal development and wellbeing circles and has for example been used by Franklin Covey in his\u00a0<em>7 Habits of Highly Successful People<\/em>\u00a0(Covey, 2011). This model became useful for us to understand our constraints for the problems our users were experiencing. Some root causes were out of our influence for example the vendor existing set up process.<\/p>\n<h3>4.3\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Ideate on how to solve the problems<\/h3>\n<p>We did a quick brainstorming activity on a white board to figure out what small thing we could do to test our hypotheses. We ended up with 5x amount of ideas written as hypotheses statements in the format \u201cWe believe that by \u2026. We can solve\u2026. we know this is true when \u2026..\u201d. The focus here was to do something small over big changes.<\/p>\n<p>We now felt we had a pretty good handle on the root cause of some of the problems. For example, all of the users we tested experienced a critical failure towards the end of the process that led them down the wrong path, but the reason this was happening was actually because of confusion further up the stream in the flow.<\/p>\n<h3>4.4\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Prototyping and testing<\/h3>\n<p>We tested the ideas in a simple prototype. Avoiding any difficult or complex tools which could allow us to move fast but also to be able to hand over any material to other people which might join our team. Very often in a consultant world we can at any time get staffed on a client or get pulled into last minute proposals. We were therefore working on the basis of \u201cif one of us wins the lottery\u201d and is out the door the next second. All of our documentation and our process reflected this bare minimum to support decision making and enough context without creating big reports.<\/p>\n<h2>5.\u00a0\u00a0\u00a0\u00a0 The Results<\/h2>\n<p><strong>Problem 1<\/strong><\/p>\n<p>The \u201cproduct\u201d we were designing was a modest instruction. The instruction set we had started with was more like an IKEA instruction set to assemble a really complicated sofa, with multiple levels and a tree house. The seemingly simple process of installing a software program had become so difficult that it required an extensive amount of instructions. The setup process was complicated at best and depending on different factors this process became an impossible mission for most. Factors like what type of history you had with other password managers, which route you had chosen to follow online (email or website), if you were a patient or easily distracted person. If you were lucky you had an expert sitting next to you, guiding you through the process.<\/p>\n<p><strong>Solution 1<\/strong><\/p>\n<p><em>The first improvement we made was to reduce the number of instruction sets provided from seven to one.<\/em><\/p>\n<p><strong>Problem 2<\/strong><\/p>\n<p>We noticed that there was one particular part of the flow where everyone was making the same mistake, and the steps didn\u2019t fit the mental model of our users. The process would first ask them to set up an account, and then setup another account which was going to be their main account. This resulted in people thinking that they were done after they had set up their first account, leaving them with half a set up done. We thought we could design the flow to fit the mental model of the user rather than the other way around. We also thought that by putting this missed step earlier in the process, less people will miss it because of the distractions and fatigue.<\/p>\n<p><strong>Solution 2<\/strong><\/p>\n<p><em>Fit the flow to the mental model of the user rather than the other way around. We put the important step first rather than last.<\/em><\/p>\n<h3>5.1\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Measure of success<\/h3>\n<p>The solution was then tracked over a 3-month period and we saw some encouraging results, including,<\/p>\n<p>a decrease in critical mistakes for example users putting passwords in the wrong place. We saw reduced time to complete. The first group of people we tested completed (wrongly) the setup in about 40 mins, with the appropriate help from the testing facilitators. This was reduced to an average of 19 minutes\u2014the fastest being done in only seven minutes. There was an increase in sign-ups. This could indicate that more people are using password managers. We now have just under 3000 people using the password manager product, many of whom are first time users of this kind of product. And we saw a reduction in support tickets. This gave more time for the Identity Team to do other more important things.<\/p>\n<h2>6.\u00a0\u00a0\u00a0\u00a0 CHALLENGES WE FACED AND HOW WE OVERCAME THEM<\/h2>\n<p><em>Our customers were distributed across the world.<\/em>\u00a0We did many of our testing sessions over video call.\u00a0We were constrained by external providers.<\/p>\n<p><em>Having to work around an existing complicated procedure by the third party<\/em>. We identified the constraints and improved the process by improving the things that were in our control. Some of the changes we suggested to the provider were taken into their strategic roadmap of features, but we couldn\u2019t rely on them changing so we had to work with that.<\/p>\n<p><em>Humans being humans<\/em>. We needed to accommodate instructions to people being distracted, not reading details and making errors.<\/p>\n<p><em>Adapting to \u201cWinning the lottery\u201d effects.<\/em>\u00a0Documenting the minimum amount to get someone else up to speed on a day-by-day basis.\u00a0The whole design process took longer than expected. There are ways to make the process a bit more efficient. But people who had previously done the setup halfway which when re-launched had to be accommodated for.<\/p>\n<h2>7.\u00a0\u00a0\u00a0\u00a0 Lessons Learned<\/h2>\n<h3>7.1\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 The Designer\u2019s Perspective<\/h3>\n<p>This is my first-time coaching and learning from other people through a design process. I\u2019ve worked almost 10 years in interaction design, and this is the first time I\u2019ve helped others learn to do design methods, and I\u2019ve learned more about how to facilitate learning. For example, how to teach others to do user testing. Being able to let go and have people make mistakes is a good way of teaching. We had an intern on our team and by giving him a sense of purpose and some guidance and amazing things can happen. I learned to start with me facilitating a user testing session with my team members watching and then having that team member do one on their own and to let them make mistakes. The feedback I would give them was much more powerful than having talked through a theoretical session.<\/p>\n<p>Simplicity is hard. Knowing what to strip away and what to keep is an art and a science. Up until the very end we kept asking \u201cdo we need it?\u201d and kept removing words and text to keep simplify.\u00a0Having access to baseline data made this design sprint powerful.\u00a0I keep confirming my love for one-on-one interviews over surveys. There is a time and place for surveys, and they need to be really well designed to be useful.\u00a0Writing this article really pushes me to express unconscious knowledge I might have. It has forced me to reflect on the things I take for granted that other people might not.<\/p>\n<h3>7.2\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 The Security Professional\u2019s Perspective<\/h3>\n<p>We deal with security and security issues all day, every day. What seems obvious to us, is not obvious to everyone. My focus was on getting things technically correct, rather than on getting the outcome I wanted, I had also made a number of assumptions that turned out to be completely incorrect. Even in a technology company, not everyone is technical. People often don\u2019t think about security until something goes wrong. Clear communication is much harder than you realise.<\/p>\n<p>Working with the design team on this problem, has helped me to see how they could help us deliver our security message much more effectively, by really understanding things from the end user\u2019s perspective. It also reminded me of a key Agile principle, the simplicity and maximising the work not done, is both essential and an art.<\/p>\n<h2>8.\u00a0\u00a0\u00a0\u00a0 Conclusion<\/h2>\n<p>There are still significant amounts of people who don\u2019t use a password manager and don\u2019t see the benefit of using one. We have put a dent in some of the barriers of password manager usage by making one available through the company and making it easy to sign up but there is still obviously a lot to be done. This small project showed us that by really understanding our user and the limitations we had, we could design a flow that resulted in less mistakes and less support tickets. This project also shows the organisation that customer centric mindsets and processes really work, and we hope to keep challenging the design thinking process in the next challenge: engineering security practices.<\/p>\n<p><strong>References<\/strong><\/p>\n<p>Covey, F. (n.d.).\u00a0<em>The 7 Habits of Highly Effective People<\/em>. Retrieved from Franklincovey.com: https:\/\/www.franklincovey.com\/the-7-habits.html<\/p>\n<p>D.School Stanford. (2020).\u00a0<em>Get Started With Design Thinking<\/em>. Retrieved from https:\/\/dschool.stanford.edu\/resources\/getting-started-with-design-thinking<\/p>\n<p>Gothelf, J. (2013).\u00a0<em>Lean UX \u2013 Applying Lean Priciples to Improve User Experience.<\/em>\u00a0O\u2019Reilly Media.<\/p>\n<p>Paul A. Grassi, M. E. (n.d.). Digital Identity Guidelines.\u00a0<em>NIST Special Publication 800-63-3<\/em>. Los Altos, California, USA. Retrieved from NIST.gov: https:\/\/nvlpubs.nist.gov\/nistpubs\/SpecialPublications\/NIST.SP.800-63b.pdf<\/p>\n<p><em>Single Sign On<\/em>. (2020, May 20). Retrieved from Wikipedia: https:\/\/en.wikipedia.org\/wiki\/Single_sign-on<\/p>\n<p>Spool, J. (2013, December 30).\u00a0<em>UIE<\/em>. Retrieved from UIE.com: https:\/\/articles.uie.com\/design_rendering_intent\/<\/p>\n<p>Stocker, S. H. (2017, June 5).\u00a0<em>Dealing With NIST\u2019s about-face on Password Complexity<\/em>. Retrieved from Networked World: https:\/\/www.networkworld.com\/article\/3199607\/dealing-with-nists-about-face-on-password-complexity.html<\/p>\n<p>The British Design Council. (n.d.).\u00a0<em>What is the framework for innovation? Design Council\u2019s evolved Double Diamond.<\/em>\u00a0Retrieved from British Design Council: https:\/\/www.designcouncil.org.uk\/news-opinion\/what-framework-innovation-design-councils-evolved-double-diamond<\/p>\n<p>Womack, J. P. (2003).\u00a0<em>Lean Thinking.<\/em>\u00a0Free Press.<\/p>\n\n\n\n","protected":false},"excerpt":{"rendered":"<p>When rolling out a new security product, engaging the services of an experience designer is not often front of mind. This is a story about why it probably should be, [&hellip;]<\/p>\n","protected":false},"author":8033092,"featured_media":8062777,"parent":0,"menu_order":0,"comment_status":"open","ping_status":"closed","template":"","categories":[],"tags":[1556,1394,929,1554,1393,1564],"experience_report_cat":[],"content_source":[1355],"class_list":["post-8061910","aa_experience_report","type-aa_experience_report","status-publish","has-post-thumbnail","hentry","tag-designthinking","tag-experience-report","tag-security","tag-technicalpractices","tag-xp-2020-video","tag-xp2020_experiencereport","content_source-xp-2020"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_experience_report\/8061910","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_experience_report"}],"about":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/types\/aa_experience_report"}],"author":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/users\/8033092"}],"replies":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/comments?post=8061910"}],"version-history":[{"count":0,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_experience_report\/8061910\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media\/8062777"}],"wp:attachment":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media?parent=8061910"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/categories?post=8061910"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/tags?post=8061910"},{"taxonomy":"experience_report_cat","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/experience_report_cat?post=8061910"},{"taxonomy":"content_source","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/content_source?post=8061910"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}