delivering new customer experiences using existing ... · transfer - rest provides simplicity and...

1 Old Software. New Experience.

Version 1.0

Delivering New Customer Experiences Using Existing Software Investments

In business applications, the core logic is often ‘fit for purpose’ - it works, it’s complex, and it has had years being refined. The place where business applications really show their age is in the ‘user experience’ - the ways in which employees, suppliers and customers interact with them every day. User experiences of today’s ‘apps’ are leaving corporate line of business applications further and further behind. Modern apps look great, they are easy to use, and they don’t require training or user manuals. The problem that businesses face today is that employees, suppliers and consumers compare today’s polished ‘apps’ with the company developed application - and their tolerance of poor ‘user experience’ diminishes by the day. So how can you deliver a fresh, compelling experience for employees, suppliers or consumers without having to rewrite everything? How do you go about developing a new user experience on existing code? This easy to follow white-paper is designed to help you get the information you need to get years more out of your business application investment, while at the same time having employees, suppliers and customers that love the experience of your digital brand.


Version 1.0

Two sides of the coin There are two issues to deal with when modernising the user experience of an existing business application: Determining how the old application will accommodate that new experience, and Designing a new experience of the existing application On one side, we want to design a fantastic experience, using modern user experience design principles. To re-imagine and simplify what those business processes are - making them easy and ‘self evident’: That is, no training, and no manuals. On the other, we have existing code and we don’t want to redevelop that logic. There could be decades of work and a major financial investment that went into refining that code. So how can we keep the benefits of the hard work and still reap the benefits of modern devices and create great user experiences? We want a new experience over the top of existing code. The way to do this is to use a design-first approach: We design the desired state with our user’s context as the foundation and then we focus on adapting that to the logic of the existing software system to suit that context. There may be times we need to make compromises later in the design process to deal with engineering constraints, but the solutions are always informed by a ‘user centric’ view, rather than an ‘engineering’ centred view focused on constraints. This approach creates positive conflict between engineering and design teams: challenging the engineering constraints collectively driven by the best possible outcome for the user. So how do we accommodate a new user experience with existing code?


Version 1.0

Accommodate a New User Experience With Existing Code Often business applications have been developed with the user interface as an integral part of it. The technical solution to getting a new user experience to work on an existing business application is to ‘decouple’ the screens you see in the web browser, terminal, or desktop application (often called the ‘front end’) from the logic that drives the flow of the screens and processing of information (often referred to as the ‘back end’ of an application). The industry standard for dealing with the decoupling of ‘front-end’ from ‘back-end’ is the use of a digital contract between both sides that states how each party will communicate with the other. This is known as an application programming interface or ‘API’. By designing the new user experience first and then working with the development team to build an API for the existing business system, that contract is informed by the future state of the system, rather than current state of the system.

PRO TIP: When to implement APIs The process of developing the API seems like it should be able to occur in parallel with the design of the ‘front-end’ however, without fail, the API will need to be reworked and there will be a lot of wasted time if you don’t wait for the designs to be done first. Design first. API second.

So how do you develop the API? Well, you can ‘roll your own’, or there are commercial solutions like Mulesoft, APIgee, and Mashery as well as open-source solutions like WSO2. These solutions serve slightly different needs, so it really makes sense to take the time to find the right solution for you. The key questions to ask when evaluating your API solution are: 1. Are you trying to bring together different business systems into a single experience?

The challenge with having multiple business systems is that they will probably be on different servers, using different technologies, with unique approaches to communication and security. Having a common API allows you to innovate on your core technologies - yet, if you choose to swap out


Version 1.0

one business system at some point in the future, as long your application can service the ‘API’, you don’t have a flow-on effect of having to change *everything* that was dependent on the system being replaced. Another benefit commercial API solutions have is pre-built connectors: essentially accelerating the connection of services by having all the integration work for common environments done for you already.

2. Do multiple business systems use different authentication mechanisms to access them?

Often you will find that there are multiple usernames and passwords that need to access different systems across the business. When you reimagine the perfect experience for employees, suppliers or customers, the last thing you want them to do is remember a bunch of different passwords. Most API platforms support the concept of federated authentication, allowing a central view of the user - with all their access roles and permissions - in one place.

PRO TIP: Implementing security correctly when you redesign a user experience One of the places developers struggle the most in developing APIs is with correctly implemented security. If you choose to go down the path of ‘roll your own’ API it makes a lot of sense to have the security implementation audited by a third party. There are existing ‘design patterns’ and ‘libraries’ for modern web and API security such as JWT (JSON Web Tokens) - when it comes to encryption, always bias towards using an existing design pattern, and use a well-supported and up to date implementation of such a design pattern.

3. Does your development team lack the experience to implement a ‘modern API’?

Modern API’s are very different from those of decades past. Modern APIs use a concept called REST. REST stands for REpresentational State Transfer - REST provides simplicity and efficiency over older approaches, however developers not familiar with real RESTful API design often make mistakes with REST that make using and supporting the API much harder and expensive. Good APIs are the foundations of systems with longevity.


Version 1.0

One day you may want to swap out that application that sits behind the API - however that API should not have to change, nor should all the hard work you have done in building a new experience over the top of it.

If you answered yes to any of these questions, it would probably be best to be using an open source or commercial solution that can provide a single API service for all the existing business solutions underneath. One of the big benefits to using the commercial solutions is the advanced tooling for implementing these API’s on top of existing business systems.

PRO TIP: Ensure APIs are designed to be terse and rate-limited APIs should only provide the minimum information that they need to. Promiscuous APIs give out information which is not being used by the user-interface, but could easily be used to exploit your application services. Promiscuous APIs are an anti-pattern of engineering APIs with least effort, and before having a completed prototype to design the API against. Using an interactive prototype to design a discriminate API is a great strategy. Secondly, API end-points should never allow repeated ‘brute force’ requests. Even authenticated end-points can be used to gather data in some way you did not expect. There are rate-limiting capabilities in most commercial API services. Should you choose to ‘roll your own’, ensure you include rate-limiting in all end-points. This layer of security needs to be applied on top of existing authentication mechanisms.


Version 1.0

Six Step Experience Re-design

So, if we know we can overcome the technical hurdles of extending the life of our existing business systems, how do you go about redesigning a user experience? Experience design never works when done in isolation. The underpinning approach to redesigning any experience is to understand the audience of that experience. For this we need to engage with them, deeply understand their context, and test our ideas with them to confirm they really do meet their objectives. This idea of real human engagement cannot be just a token gesture. Engagement is the essence of human-centred design. What engagement means is that sometimes we have it wrong - we did not see the real problem, or we didn’t understand the implications of our design idea. Whatever the gap was - we need to work with real people, work hard to really hear their needs, and find a balance between not solving their problem at all and iterating to an impossible perfection. We need to find a balance at every step of the process - and yet, we need to be brave enough to jump back to step one if we find we really missed something important.


Version 1.0

Step #1: mapping current reality - systems and people The first step of designing any experience is exploring and mapping the current reality. You need to map the terrain of the user - externally and internally. The questions below are just the beginning and they are all open-ended questions that can have deep enquiry. External Questions:

• How does the current ‘system’ work? (ie: the current manual and technical implementations)

• What are the objectives of the process or processes that make up the system?

• How well does the current system meet the objectives of the process?

• Are their special cases or exceptions? Why and how often do they occur?

• Do situations exist where a special case is uncaught?

Internal Questions:

• What are people doing when they are using the current system?

• How do people feel when using the current system?

• Do people need lots of training to use the existing system? Is the training required for an area of expertise (ie: medical analysis or creative output) or just for task completion?

Observe and record intent, expectations, actions and emotions. Emotions like frustration, apathy, cynicism and boredom are very important to observe as you watch users interact with existing systems, or performing existing processes. If your intended users are interacting with other people, it is especially important to map the emotion and behaviour of the intended user in different contexts: what happens when they speak to an unhappy customer? What happens when they speak to a customer in a rush? Does the current system or process get in their way or facilitate these situations?


Version 1.0

PRO TIP: Understanding is not passive observation If all stakeholders in the redesign process can experience the current process, it fundamentally changes the outcome. For example, it is a very different experience watching someone answer a phone versus physically being there and answering the phone yourself. It is very different watching someone use a system versus trying to use that same system yourself. Wherever you can, go past passive observation to deeply understand.


Version 1.0

Step #2: journey mapping with a focus on the critical path Once you start to understand the current reality, the key is to ‘map the terrain’ of that current reality. Use your visualisation skills to build a map the current experience. Map processes (and exceptions to those processes) and try to map the state of the user - emotionally and intellectually at every stage of that journey. The experience map is an efficient tool for doing this.

Figure 1: Example experience map

Key features of the experience map are as follows: The horizontal dimension of the map is the process broken into logical phases. I like to cluster exceptions next to their ‘trigger’ phases and put some kind of box around them to make them stand out from the rest of the process, but still be understandable in the context of the bigger process The vertical dimension should be the following sections from top to bottom:

● Journey map ● Feeling ● Doing ● Thinking ● Touch-points


Version 1.0

Here is an overview of how to use each section of the vertical dimensions:

Journey Map: this is a visual representation of the steps at this point. This looks something like a hybrid between a flowchart and information architecture. Feeling: should be a visual articulation of the emotional state of the user at this point of the experience - which is something like a graph. The curves that go positive represent positive emotions, and the curves dipping to the negative represent negative emotions. It is important to label these emotional swings with what emotion is being represented - for example, apathy is different to frustration, but they are both negative. Doing: is literally an audit of what the user is doing at each phase of the experience - it should be backed up by the journey map, but may have more detail on it. Thinking: generally, this would be text explaining the intellectual motivation or cognitive state of the person (user) at each phase of the process. Touch Points: is a list of one or more mediums that would be interacting with the user at that point of the experience. This is important for any non-trivial user experience since they are usually spanning multiple mediums. It is important to see experiences beyond a computer. This is especially the case with designing ‘mobile’ experiences.

Focus on mapping the data and understanding the context of the people for whom you are designing the experience. If designers spend time really understanding, they come up with great experience maps that contain well-articulated insights about the experience.


Version 1.0

Step #3: Casting the vision One you have a map of the current reality, and a deep understanding of the problem you’re trying to solve, it is important to spend time casting a vision of the solution. Vision casting is a creative thinking process which can be done individually or facilitated collectively.

PRO TIP: Great Visions Are Implementation Independent The key to effective vision casting is ‘implementation independence’. That is, a vision should not attempt to articulate implementation details, rather it should focus on solving the problem that was defined by mapping the current reality. Bad vision: We are going to implement an integrated customer service portal in Javascript that integrates directly into SalesForce using the Zapier integration tools. Good Vision: A single view of the customer that makes it easy to search for a customer while they are on the phone, and provides an efficient way of updating interactions with that customer once the interaction is complete.

There are many approaches that you can use when vision-casting, but a couple of go-to thinking tools to use for clarifying the vision of a new experience, especially when having to consider an existing software system, are:

1. If I was….

2. Focus on the critical path

3. Reframe the problem


Version 1.0

If I was…: Having spent time facing the same issues as the people using the systems you are aiming to redevelop, it makes sense for you - as a designer - to be able to think about your objectives as if you were the consumer. By taking on this mode of thinking, you change from ‘problem solver’ to ‘problem experiencer’ – and it can only be really achieved if you have spent time actually doing this through the ‘Current Reality’ phase. By making you focus on the ultimate outcome that the consumer of the experience was after, there is often an ‘aha’ moment where you see beyond the current implementation of the solution to really solving the consumer’s problem. Focus on the Critical Path: One of the biggest issues I see in the design of systems is defining what the critical path is. The critical path is the path that the majority of users of a system will go through - or have to go through to achieve some outcome. Often, I find there are so many extra steps included in the path to the outcome that are non-essential in some way. Even if a user does not need to fill in a form-field, the fact that it is present on the screen means they have had to expend cognitive energy to determine what it was and how they should behave with it. This expending of mental energy adds up over the course of using an application. By treating the user experience as a ‘fishbone’ instead of a direct line, that is branching off from the critical path for the 20% of users that actually need the exception to the rule, we simplify the experience. When Thinking.Studio were working on a project for a government owned power utility, we used this approach to simplify how employees obtained approval for expenditure (often called sub-delegations) down from a huge long multi-part form with over twenty fields to four simple steps for the majority of employees in the vast majority of circumstances. The best visualisation tool to use for ‘critical path’ focus is a variation of the ‘fishbone diagram’. Normally the fishbone is used for illustrating contributing factors in a root cause analysis. In our case, we want to use it in reverse – to illustrate the things that are not the critical path.


Version 1.0

Normally, the ‘backbone’ of a root case analysis fishbone would have the ‘event’ that occurred for which we are seeking the root causes. In our case we would attempt to put the ‘critical path’ as the backbone of the diagram. The lines that look like ‘fishbones’ for which this form of diagram is named is used for illustrating categories of the workflow you are illustrating that should not be in the ‘critical path’. By going through a few iterations of a workflow and pushing as much as possible into the bones, it informs us as to the most important aspects of the experience we are trying the envision. The example below illustrates a small section of the thinking we used on the above power utility example. The critical path is really just three steps – everything else is a side track which may or may not need to be asked of an employee. This insight laid the foundation of our vision in simplifying sub-delegations.

Figure 2: Example Critical Path Fishbone Diagram


Version 1.0

Reframe the Problem: The most abstract thinking tool - yet possibly the most powerful - is problem reframing. To reframe a problem requires some external ideas to help change the context of the understanding of the problem. A great example of this in action was a software platform we were redesigning. It was a back-office insurance platform which had lists and lists of different items on the screen employees used every day. Users felt confused when they used it, new users had no idea what was going on, and training was a huge cost to the organisation. The original design was focused on showing users ‘things’ and having them choose the thing to work on. We reframed the problem of how to design the screens by reframing our challenge to be on what was happening when the user was there looking at the screen, rather than the data. They needed to search for a person or policy. By reframing the problem, we transformed a screen full of lists into a clean single search box that users appreciate.

PRO TIP: Skill Up on Your Thinking Tools We don’t often think about how we think. Thinking tools are insights and ‘design patterns’ that can use to amplify your effectiveness when it comes to dealing with challenging problems. They are easy to learn, and you can practise and hone the ones you find most useful. Below are some great books on thinking tools to get you started.

Intuition Pumps and Other Tools for Thinking By Daniel C. Dennett

Innovation Thinking Methods for the Modern Entrepreneur By Osama A. Hashmi

Mindware: Tools for Smart Thinking By Richard Nisbett

The Power of Framing: Creating the Language of Leadership Gail T. Fairhurst


Version 1.0

Step #4: Building an information architecture The information architecture is the next level of detail after mapping the future state of the customer experience. The information architecture is a more detailed map of a system - kind of a hybrid between a site-map and flowchart, where interactions are the connections between the blocks that represent states of the user experience.

Figure 3: Example of an Information Architecture


Version 1.0

The information architecture should inform your prototype design, however once interactions start being designed, you may find that you feedback changes from the prototype back into the information architecture. The information architecture is a powerful tool for determining the scope of work in delivering a fully interactive prototype, however it should be treated as a ‘live’ document which is the map of the interactive prototypes. This approach keeps a big picture and a close-up view of the experience being designed, helping all stakeholders keep their perspective. The biggest challenge in developing a cohesive Information Architecture is understanding that you are not articulating the user interface when designing this map, rather you are articulating the structure of information delivery and triggers for that information to be provided. By thinking of Information Architecture in these terms, the connections between the pieces of information in an Information Architecture map represent user interactions or external events. The work of the interface designer is to take the pieces of information and the interactions and make them a cohesive experience that is intuitive, flows and feels polished. One of the most common errors when developers implement straight from an Information Architecture or, worse, data design document from a business analyst, is a ‘data centric’ set of screens that ignores the context or objectives of the person using the software for the sake of serving the map that came with the requirements. This approach to application design is the anti-pattern we are trying to avoid by redeveloping the user experience of the application.


Version 1.0

PRO TIP: Secure UX Design Great secure applications come from well-informed user experience (UX) design as much as it does from skilled front-end and back-end software engineers that understand security. Secure UX design follows some simple principles at the time of developing the information architecture which will then flow through to the user interface design and later, the implementation. Here are some of the key elements of secure that will help your users be more secure when using your application. Important actions should look set expectations and be distinct from one another Whenever a user is doing tasks that could have dramatic impact, like changing account settings, entering a password, or completing a transaction, the user interface should make clear what the user is expected to do, what will happen when they do it, and how they get through the process. Differentiation through use of colour and iconography is a very powerful way to do this. Show only the necessary information Showing only the necessary information reduces the cognitive load on the user and increases the likelihood that they will read prompts or security warnings. If you do need to show a warning, make it visually distinct from the rest of the user interface and use this kind of visual distinction very sparingly! Design for least privilege There is a body of research showing that 85% of users will passively ignore options they don’t understand or consider important, and leave them in their default state.1 An example of this is a ‘remember me’ checkbox on a login screen. By defaulting to unchecked, you are designing for least privilege. This should be the case everywhere a user needs to make a decision that could affect the security of their account.

Step #5: prototyping 1 https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4175622/ This academic research shows that having default checkboxes for important decisions such as organ donation can dramatically affect the rate of donations based on the default action (opt-in versus opt-out).

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4175622/


Version 1.0

Once you get to the stage of designing the prototype it may seem like it’s all just up to a ‘graphic designer’ to make things look good. This could not be further from the truth. While having an aesthetic is helpful, understanding the overall design and interaction ‘language’ is of vital importance. Now you have a map of the information and interactions that define the user experience through the Information Architecture, building an interactive prototype of the final solution is a great way to quickly understand if the team have solved the right problems effectively and created a solution people want to use. The key to effectively building an interactive prototype is to develop it in iterations, using levels of detail that increasingly demonstrate something looking more and more like a finished product. By developing a rough version of the interface first, you can block out key elements without being ‘totally committed’ to the design. The UX designer can lay down the fundamental un-styled elements on the page, they can be used, and their relative structure on the layout debated and altered without a large investment in time. Once completed, this prototype can be viewed and debated in a group setting which combines designers and other stakeholders. This is akin to a ‘design charrette’2 which is a collaborative session in which a group of designers draft a solution to a design problem. These rough designs can often be manipulated in real time while the team debate its merits and come up with alternate concepts on paper, whiteboard, or even multiple versions of the prototype on their computers. The second iteration should allow more clarity on the design aesthetic to appear in the user interfaces. The designer would use the feedback from the previous sessions to refine the layout, design elements, and text labels, to have the interface start to make sense to a potential user. This second iteration allows for something that approaches the level of detail users would need to really test the prototype in a meaningful way that you could use to learn from. There may be missing pieces of the interactions at this stage - especially when the interactions being envisaged are complex. This is not ready for an end-to-end test, rather it would be a way of introducing users to critical fragments of the experience being designed and understanding based on their behaviour if you have gaps in your understanding.

2 https://en.wikipedia.org/wiki/Charrette definition of a Charrette

https://en.wikipedia.org/wiki/Charrette


Version 1.0

PRO TIP: User Testing Should be Objective Based When you have a test-user in a lab about to use your prototype, don’t tell them how to do what you want them to do, or even break down an objective into stages – just focus on asking them to complete a single objective which your prototype is capable of fulfilling. You should pay close attention to the facial expressions and interactions of your test-user. Two cameras are great for this, one recording the user’s expressions and behaviour, while the other tracks their interaction on the device they are interacting with. Pay very close attention to the questions they ask, and even subtle sounds they make, as they proceed through the journey of achieving the objective, but don’t jump in to help them. If they are asking questions about what to click on, just encourage them to do their best and let them continue without your intervention at all costs.

Subsequent iterations are focused on ‘polish’ and clarity of the interactions.

- Connecting the different completed stages of the prototype together in a cohesive way so that there are no ‘dead-ends’

- Ensuring all text-labels are spelt correctly with terse high-impact wording

- Refining the user interactions, perfecting the animations, transitions and other complex elements so nothing in the prototype is ‘broken’

- In the case of very sophisticated user experiences, building multiple narratives or narrative variations into the prototype to demonstrate the application under different contexts, with a written sequence developed explaining how to sequence the ‘narratives’.

At the end of the second and subsequent iterations, there should be internal debate, as well as real-world user testing to validate design decisions as quickly as possible in the process. We recommend breaking the design process down into iterations for this reason alone. Errors in interpretation are rapidly compounded through the prototyping phase.


Version 1.0

The Prototyping Work-Flow Today, there are more and more UX design tools flooding the market. The key to effective interface design is not so much the tooling as it is the work-flow. It is important to have a flexible UX design tool, but it is even more important to know you can rapidly get the level of detail you want. Having an existing community that creates visual ‘frameworks’ is also very important to accelerate your progress and at the same time provide polish to the design process. As an example, we use a combination of AXURE RP, Nucleo Icons, and Photoshop as tools in our work-flow for building prototypes. However, just as important, we use AXURE libraries that provide the foundations for existing visual frameworks like Material UI3, Flat UI4 and ANT UX5.

Treat interfaces and Interactions like a language - know your dialect If designers think of interfaces as a language, then it helps to effectively inform their design decisions as they go through the process of bringing the interface to life in a prototype. Consider how great writers use language: they don’t spend time making up new words, they consider ingenious ways of expressing ideas through the use of existing words. A great writer is able to impart an idea with a sense of clarity without excessive verbiage. The same can be said for user interface design. Great interface designers are not rushing to make up new user interface metaphors, rather, they understand their audience and the visual representations they are used to seeing. They can speak to them effectively combining and adapting visual concepts they already understand, crafting them into an experience that is compelling. Interface design has evolved so much. The problem with the language of interface design is that we don’t have a dictionary. A place to go to look up the meaning of an interface element which contains the common definition. Instead, over the past decade we have evolved visual ‘dialects’ - the lineage of these dialects heralds back to the Macintosh Human Interface Guidelines which were first published in 19856. Today, we have human interface guidelines for Apple7, Google8, and

3 https://gumroad.com/l/Material-Extended 4 https://gumroad.com/l/FLATKIT-Extended 5 http://ux.ant.design/ 6 See this example from 1995 http://interface.free.fr/Archives/Apple_HIGuidelines.pdf 7 Apple Flat Design https://developer.apple.com/design/ 8 Material Design https://material.io/guidelines/

https://gumroad.com/l/Material-Extended

https://gumroad.com/l/FLATKIT-Extended

http://ux.ant.design/

http://interface.free.fr/Archives/Apple_HIGuidelines.pdf

https://developer.apple.com/design/

https://material.io/guidelines/


Version 1.0

Microsoft9, any of which we can use as foundations for our approach to web application design. It makes sense to use the appropriate design framework as the foundation for your dialect based on the target platform of your application where possible. Where this is not possible, today Google Material Design is a great alternative which feels at home on all desktop and mobile web experiences. Using an existing ‘dialect’ with the appropriate libraries within the prototyping tools saves countless hours and produces generally better results. Designers spend less time ‘reinventing the wheel’ and instead can refer to the design guidelines to help drive their decision-making process. At the same time, users see designs based on a ‘dialect’ they understand and can immediately pick up and use. The most important element that this ‘dialect’ of human interface guidelines provides is interaction precedents. Precedents are crucially important to interface design. The challenge every interface designer will face at some point, will be finding an interaction precedent for a complex interaction. When this happens, the first thing to do is understand how other user interfaces within your industry have tackled this problem. When trying to find precedents, it is also essential to consider analogies to the complex interaction you are trying to solve for. Users of your system might intuitively understand your complex interaction because of their experiences with the analogous idea. The most famous example of this is folders and files on a desktop: As users switched to GUI computers through the late 1980’s, the complex idea of file management and directories was greatly simplified by representing these elements as pieces of paper and folders on a desktop. The creative challenge for the designer is to adapt the analogy for the complex interaction into the desired ‘dialect’ so it still feels cohesive.

9 Microsoft Flat Design http://download.microsoft.com/download/2/4/A/24A81A29-77CF-4AA5-967E-64E42554F21B/UWP%20app%20design%20guidelines%20v1509.pdf

http://download.microsoft.com/download/2/4/A/24A81A29-77CF-4AA5-967E-64E42554F21B/UWP%20app%20design%20guidelines%20v1509.pdf

http://download.microsoft.com/download/2/4/A/24A81A29-77CF-4AA5-967E-64E42554F21B/UWP%20app%20design%20guidelines%20v1509.pdf


Version 1.0

Step #6: story writing and the agile process The final step of redesigning the experience on top of an existing application is to break the user interfaces and interactions down into small pieces that can be documented as agile ‘stories’ that can then be implemented by the front-end engineering team. There will be some work in scoping the new the API for the front-end which should include extra security for the API layer which will vary depending on your existing code-base. A great way to help define your API is to use the design-driven stories to determine the API-centric stories. Writing ‘stories’ seems simple – just use the agile story ‘prototype’, right? The Story prototype "As a [role] I want [feature] so I can [business benefit]" At the most basic level, defining a feature in a system with the context of the target audience and directly connected business benefit is a quantum leap forward from the assumed approach in traditional waterfall scoping, however below is some information that, when added to a ‘story’, makes the workflow vastly simpler to navigate during implementation. Story Context What set up the current story? What was the state of the system when this story is being told? The Story Context is the background on how you get to this screen or state of the system and possibly why you got here. This should be based on the two aspects of context: 1. What were their deeper motivations, or understanding in arriving to this story? 2. What section of the UI were they using to get to this place? Example Story Context: The user can get to the Health Log by clicking the button on the dashboard or the heart icon. The health log is a core part of the system for tracking user emotional state and can be opened from multiple different screens via the hearth icon.


Version 1.0

Story Design Requirements This section should have a reference to the user interface designs that have been developed through the prototype design phase. The user interface prototype is able to explain the layout, functionality and interactions of the user interface in a visual way that is easy to understand. Example Story Design Requirements:

The Dialog Box is triggered by clicking on the speech bubble at the top right

toolbar. Animation should be as per prototype.

https://projects.invisionapp.com/share/6J3KDI64X#/screens Story Copy Requirements The term copy refers to the text-labels used on the user interface. The prototype itself should be the ‘copy deck’ and should be leveraged as the ‘single source of truth’ for all visual elements of the application being developed. If you have a copywriter, they should be working with the designer to ensure the copy is always up to date in the prototype.

PRO TIP: Prototypes should be the single source of truth By using the interactive prototype as the single source of truth you are implying that the interactive prototype is a living document. All functional, cosmetic and copy changes to the application throughout the development process will need to be applied to the prototype, reviewed, and approved. This means interactive prototypes should be version controlled. When creating or updating stories in your agile project management tool for the development team to work on, identifying which version of the prototype is being used should be clearly stated in the story.


Version 1.0

Other Considerations Anything else the developer should know that would affect performance criteria. This is where we would put the ‘aspects’ that affect the system but are not a direct outcome. For example; must deal with permissions correctly and use existing permissions system. That is not a new feature but more a reminder that there is a dependency which needs to be accounted for in the development of the story. Example Other Considerations:

• First name field is required and needs to be at least 2 characters • Email should be a complete email address using standard email validation

formula

• Needs to satisfy OWASP-17 security guidelines (where there is a link to such guidelines - or they are explicitly described)

PRO TIP: Universal Definition of Done While the stories in the backlog should have their acceptance criteria defined, there are some acceptance criteria which should be articulated at the project level and should be applied to every story. This model allows for cross-cutting concerns that affect the software to be articulated once and referred to throughout the sprint cycles. Examples of universal criteria would be: Specific security requirements that affect every piece of code on a platform Design principles that should affect every user interface element Form-field validation criteria for every place data is provisioned by users The idea of universal DoD documents speaks to the driving principle of agile - namely, minimise documentation and focus on working software! If we can reduce the size of stories by universally referring to the DoD throughout the project we have clarity for the team and a consistent piece of software.


Version 1.0

Story Outcome (Acceptance Criteria): For this story to be accepted, what needs to be performed? Explain precisely what needs to be done - this should be the expectation from the user’s perspective and possibly technical as well. Acceptance should include both happy and unhappy paths that will be accounted for in the acceptance process. Example Acceptance Criteria:

• I will expect to enter my email address and password and click ‘log in.’

• If I forgot my password then I would expect to click ‘forgot password’ and go to a ‘forgot password' flow (see story #xxx for this)

• If the username and password are correct the user should see an icon and the main dashboard should load (see story #xxx)

• Implement the user interface as per designs in the Story Design Requirements

• Login screen should have labels and copy as per the copy requirements

• If the user enters an incorrect password, the UI should display a login error and request the user to log in again

• If I enter an email incorrectly then the field should be validated and I should see a message explaining that it is incorrect and highlight it

When documenting acceptance criteria it is supremely important to consider 'unhappy paths' - that is, if a story has the potential for an error to occur, what happens? Is there another story that accounts for it - or is it expected that this story should deal with every eventuality? If you can put unhappy paths into the universal definition of done, you will make the documentation of all your stories much simpler - however this may not always be possible. Examples of unhappy paths:

• Network connection dropout

• Third party service request returns an error

• Invalid information entered in a form-field

Applying global approaches to managing unhappy paths makes for a more consistent product with much less documentation, so it is highly recommended to attempt to get the universal definition of done to contain these wherever possible.


Version 1.0

Identifying Epics Epics are stories that are grouped together by feature. Sometimes, an epic may start as a story and because it has so many related tasks an epic is created that wraps up the stories together. Sometimes it may just be a matter of assigning a story to an existing epic. Once a new epic is created it should then have its associated story split in to constituent stories and they should be grouped within the epic. Splitting Up Stories A Story should never be more than three to four days of effort - and that story should have tasks created within it such that no task is ever longer than half a day. The challenge in doing this, is to then split up the stories in a logical way. Stories can be split using many strategies, however certain stories have 'patterns' that lend themselves to certain kinds of splitting strategies. Some of these patterns are:

• Independent elements within a single story - create stories that represent each element splitting by sub-role - split the story based on the more specific needs of the different roles that benefit from the story

• splitting by data depth - identifying layers of data or relationships of data that lend themselves to being broken up

• splitting by operational boundaries - for example CRUD – Create, read, update, delete

There are many more subtle patterns that great analysts develop an eye for over time - and thinking strategies that can be used to attain them.


Version 1.0

Conclusions Extending the life of existing business software is a compelling choice for many organisations that have invested heavily in technology that is not keeping up with the complex demands of consumers, employees or suppliers. Decoupling the user experience from the business systems allows the organisation to adapt to these changing needs at lower cost. The impact of these transformations cannot be underestimated. User’s perception of the brand can be fundamentally transformed for the better through rapid development of compelling digital experiences on the web, in mobile applications, and even embedded devices. Employee productivity and supplier engagement can be dramatically improved by streamlining applications to suit changing work processes and customer needs while also reducing training and support costs.

We hope that the strategies outlined in this whitepaper serve you well in transforming the user experience of your existing software.

delivering new customer experiences using existing ... · transfer - rest provides simplicity and...

Documents