Understanding the challenges & product landscape
This series is a running journal I kept over a 10 month period while designing a financial technology (FinTech) application for a major US financial institution. (**FYI designs are protected under NDA**)
The product’s goal is to enable financial compliance analysts to discover and mitigate employee malfeasance. Analysts often have legal backgrounds or more often are former traders themselves. This domain knowledge of what terms traders use and topics they discuss is the best tool banks have currently.
This series will cover the following aspects of the product design:
- Part 1: Understanding the challenges and existing product landscape
- Part 2: Picking a design language framework
- Part 3: Agile sprints, User stories, & Atomic design
- Part 4: User Research
The financial industry is suffering from an out of control wildfire of fraudulent activity that has cost financial institutions billions in fines from regulatory agencies. Wall street needs software that will assist them in being able to discover and mitigate employee malfeasance on an enterprise-level scale asap.
Product Roadmap Strategy
As with most other products a kickoff meeting was conducted over a 3 day period. This was the stakeholder’s chance to set the agenda and establish the overall direction for the product. Features considered critical path included Information Leakage Detection, Collusion Detection, Trader Profiles, and Email Communications Analysis.
The meetings were on track until day 2 when one of the project managers began to draw on his iPad a wireframe of how he foresaw the product looking. I quickly chimed in to say,
Until we complete some initial research, discussing the layout of the app is a complete waste of time
The reaction by most in the room was split. Half the room agreed and understood many steps were being skipped. While the other half were shocked and dismayed that anyone would stand up and say no to a project manager.
I continued by sharing the vision that this would not just be a product that picked up where competitors had left off. But that it would be a completely new person-centric, not alert based, machine learning driven compliance product.
As a user experience designer I feel it’s important to establish at the beginning of a project who is responsible for what tasks. If anyone, most often an over zealous project manager, tries to do your job for you it's on YOU to speak up and explain why it isn't. Having the guts to defend design (or sometimes over defend) is, in my opinion, one of the more lacking characteristics of less experienced UX designers.
There is also a fine line with this. Push back too hard you’ll offend the stakeholder. Do too little and you risk being run over and have every design decision questioned. It’s up to you to evaluate the balance needed here based on your relationship with the stakeholder to successfully work together without surrendering your ability to be creative and try new things.
Existing Product Landscape
With my background in US federal consulting it was oddly comforting to see that both government and financial industries suffer from similar issues. It’s changing slowly, with groups like the US Digital Service, but user experience is still an afterthought.
When I was on a call not long after the kickoff meeting one of the stakeholders was talking about another product and simply stated,
Just get the infrastructure up and we’ll slap a UI on it.
It was clear from this point that I had my work cut out for me when it came to educating the stakeholders about all the effort that goes into designing a truly amazing user experience.
This lack of empathy towards users in an enterprise setting is understandable to a degree. There is no real incentive for companies to dedicate time and money when the employees are required to use the software to perform their job.
Spreadsheets have been bastardized for years in situations where a database would be the better solution. What became a simple ledger evolved into pivot charts. I pledged to myself at the start of this project that I would work as hard as I could to avoid spreadsheets.
Below is an example of CA Technologies Dataminder. It uses regexes made of simple “dumb” rulesets to identify possibly bad behavior. But as traders evolve their slang so does the work of the analyst to modify these rules to continue to discover malfeasance.
Since the rules are term based the recall is incredibly low and analyst spend much more time managing the rules and eliminating false positives than they do reviewing for potentially bad behavior.
User Interview Impediments
It was a struggle to get the stakeholders to understand the value of contextual user interviews and the data it would yield. Obtaining this data would go a long way in guaranteeing the user experience was designed to meet both the business and user needs. Until now the stakeholders, not the users, had total control over all user experience design decisions. It was clear this would be the first major battle and one I was determined to win.
Stakeholders, not the users, had total control over all user experience design
The Blind Designer
My initial requests to speak directly with users was met with bewilderment and disbelief. I was told by one project manager,
The user's time is very valuable to this firm. If you’d like to know anything I can tell you. What would you like to know?
It was very clear he was gatekeeping. It was also clear that he had no concept of user research as he told me, “How does amazon know to make changes to their site? They don’t call my grandmother and ask her what she thinks, they just build it.” This is of course a ludicrous statement as Amazon has amazing user research teams in Washington state and London, UK.
I left that meeting with no resolution and no access to users. So with no research to help me define the problem I would be trying to solve, I was stuck in a awkward position.
In a situation like this I often use the following metaphor:
Imagine you hired an interior decorator for your home. Throughout the entire process, where you select and install furniture, wallpaper, paint, etc. you never have a single meeting with the designer. There is no opportunity for them to obtain an understanding of your taste and style. Without this interaction the likelihood that you’ll be happy with the results probably won’t be very high.
It was clear I was just going to have to gather what information I could from stakeholders knowing that it would carry bias and not be entirely accurate. Their area of focus was to concentrate on speed and reducing the amount of mouse clicks. When I finally got to interview the users this turned out not to be anywhere on the main list of user needs.
Picking a design language
I had just completed a side project using Material Design by Google in an effort to try it out. Given that the existing UI of the client side project was a mix of Bootstrap and Material Design I assumed I could easily get away with going full-on material.
By establishing a design language framework at the beginning it allows the designers and the developers to operate in the same world. It helps in conveying user interface best practices and the rules for the given design world. Having a foundational agreement on this allows designers and developers to focus on design questions that matter and not on things like the shape of a button.
I followed the client’s publicly available theme and built my color pallette around that. There are a few tools out there that can help you create this for you but there are two I’m particularly fond of;
Given that I’d chosen Material Design as my design language I went along with the default Roboto font. It has a clean modern feel that I could also get away with in an enterprise environment.
Again, In an effort not to reinvent the wheel I often find relevant metaphorical meanings for the icons I use within the product. Most of them can be found in the base set offered by Google.
Agile sprints, user stories, & atomic design
Speed. More to the point... Velocity. It’s a way to continually discover ways to work faster and more efficiently whilst also removing wasted effort at the same time. It also has a game element to it. Each task or User Story, is assigned a number that represents the level of effort it would take to complete that task. Numbers are assign on the fibonacci numbers. Depending on the length of your sprint (most companies run 1/2 week sprints) 1 person could complete X number of points. In a 2 week sprint I was averaging ~60 points.
When the next sprint planning session occurred, a meeting where the stories are collected and assigned, you would see if you could add 5 more points this sprint. You are constantly pushing how many pts you can complete. When a team attacks this growing sprint backlog it’s known as swarming.
Ideally when you estimate stories you want them to all be 1 pt. 1 roughly equals 1 day of effort. Anything larger and you should break them down into smaller more specific stories. If I don’t I hear the voice of Mark Fischer in my head yelling…
1 point!… 1 story!…1 day!
My focus is always on what design would make the user story true. This allows for ultimate creative freedom while still adhering to feature requirements through Acceptance Criteria. User Stories go a long way to ensuring the quality and consistency of the designs are always high while also being fast.
User Story Mapping
The user story is the main instrument used in the agile design process. They provide a multitude of understanding around Feature Value, Prioritization, and Effort.
I follow the user story structure of
As a <role>, I want <feature> so that <reason>
User story mapping is the foundation for sharing overall understanding and setting expectations on what can realistically be achieved in a sprint. Or as Jeff Patton says,
User Story Mapping is a dead simple idea. Talk about user’s journey through your product building a simple model that tells your user’s story as you do. But it turns out this simple idea makes working with user stories in agile development a lot easier.
If User Story Mapping is new to you you should read Jeff’s book first! It’s really well done and covers all aspects around the process of creating story maps.
User Story Mapping: Discover the Whole Story, Build the Right Product
Buy User Story Mapping: Discover the Whole Story, Build the Right Product on Amazon.com ✓ FREE SHIPPING on qualified…www.google.com
Product User Story Map
Around 12 people participated in building the initial map. Using the whiteboard space (8' tall x 12' wide) people were told about the identified roles and were asked to write stories. There had been a few workshops prior to the sessions just around how to write stories for those that didn’t have much experience w/ it. We really wanted everyone’s point of view to be considered and heard.
…my focus is always on what design would make the user story true
I typically start w/ this exercise for most projects AFTER presenting the findings of contextual user interviews. But in this case I had no research data yet so I had to invite stakeholders into the session to lend context and information about what they knew about the users.
The stories pertained to enabling the users to process the alerts at a quicker rate and more efficiently .Many of the assumptions made during this exercise actually ended up being disproved by user research.
The user epics and stories identified from the mapping session are fed into a kanban board. I followed a 2 week sprint schedule.
Side Note: I’m almost done the GV design sprint book and will be changing to 1 week sprints.
Kanban boards in conjunction with the screenful.me tracking provides a large window into the design process at any given moment. I find that this allows for ultimate agility when deadlines change, and they always do.
Daily scrum huddles informed the rest of the team on what I actually accomplished yesterday and what I planned to accomplish today.
Project Board Columns
For those Agile junkies out there here is my kanban stages:
- Use Story Mapping Backlog
- Whiteboard Backlog
- White Sprint Backlog
- Design Backlog
- Design Sprint Backlog
- Design Critique
- Activity Trail Icon [If one needed to be created]
- Zeplin Backlog [To be pushed to Dev]
- Prototype Backlog
Evaluating Progress & Effort
Using the Labels feature in Trello and a powerup built-in third party app called Screenful.me I’m able to automaticlly create realt time burndown charts, cumulative flow, and understand team velocity. I assign cards w/ the appropriate labels, which represent Epics. Those labels drive the flow chart below.
To determine effort you add a“(#)” at the beginning of the card title to assign an estimation. Screenful will understand this and update accordingly.
Screenful.me also has a “radiator” mode where it automatically pages through the screens. It’s great to just leave on a screen in a open area in the office to offer a view of what is being worked on and when it might be complete.
Project Atomic Library
These are the smaller bits. For me this means toasts [call to actions], Category icons, General icons, Audit icons, and logos;
Comprised of many atoms, Molecules represent the next step in constructing interchangeable components. Typical convention is to read left to right and follow the flow/changes in the component.
If you aren’t already you should be using Zeplin. This product enables me to develop very quickly by removing the tedious tasks of creating redline comps or writing CSS for style specifcs like Hex #’s for colors.
Zeplin instantly provides the frontend development team w/ up to date:
- CSS Stylesheet incl. color pallette
- Asset Images
- Object placement/spacing measurements
Utilizing the Zeplin Sketch plugin and Sketch Runner pushing updates takes only a few minutes. The more detailed your designs the longer it tends to take to upload. You also can only do 1 page in Sketch at a time but unlimited count of artboards on that page at once.
Getting access to interview users in an enterprise environment is a tall order. It ended up taking me over 4 months from the kickoff meeting till my first interview. I had to give numerous presentations and attend 1:1 meetings with key stakeholders to convey the value of contextual user interviews. This may seem like an unusual request if they’ve never heard of UCD (User centered design).
Subscribing to UCD ensures that user happiness and acceptance of the product is high. Instead of forcing the user to conform to a product workflow, It’s much easier to match the product workflow to the user.
I employed the following tactics to spread the gospel of User Experience Design:
- Schedule multiple meet and greets w/ potential users, project managers, product owners
- Educate project managers all the way to sub C level bosses
- Create educational presentations about user experience research and best practices
- Perform mock user interviews w/ project managers so they go through the experience
Learn, Understand, Design, Learn again
I interviewed 8 users in total spread out over the course of a few weeks. I conducted a ~1hr interviews utilizing ethnographic principles to extract data about the user's responsibilities, frustrations, processes and interactions. This information was instrumental in shaping what has turned out to be an amazing user experience.
User Interview Framework
It’s a good idea to have a well constructed high-level strategic plan on what aspects of the user's responsibilities/process you want to learn about.
I created a Trello card for each interviewee. I can have a great view to track and drive the research progress. This is also a great place for anyone else on the team to review raw interview data.
How you conduct your user interviews is entirely up to you and should be customized to the specific industry and audience you are interviewing.
I often follow a loose improvisational style. You have to follow where the user takes you and select the correct question to ask at the right time. I guarantee you no interview ever goes exactly like the previous one. Users prioritize differently so you have the be flexible but keep on a topic but also allow opportunities to ask the 5 whys. Contextual interviews have often been described as an art unto itself.
User Interview Pillars
There are a few tactics I utilize during an interview:
- Ask Open Ended Questions, I can't stress this enough…
- Why? Why? Why? Why? Why?
- Don’t be afraid to go off script
- Be mindful of time [It’s ok to let them talk but try to stay on topic]
- Listen for emotions/topics repeated multiple times
- ASK OPEN ENDED QUESTIONS (it’s ok not to know exactly what you'll learn. That's why you’re conducting the interview in the first place!)
For the first analysis I decided to be completely and unforgivingly transparent. I was going to leave every piece of data extracted from the interview for all to see.
I tend to write outlines and draw workflow diagrams. The outlines are the basis for my information architecture. The users often describe a process and I simply illustrate it. This could take some time as I rewind over and over to make sure I understand. A 2 hour interview can take ~2–3 days just to analyze.
Analysis Focus Areas
There are a few aspects of the interview I make sure to understand. These include emotion, repetition, examples, and overall themes.
I deconstruct the interview in front of a 8' high by 12' wide whiteboard wall. My interviews follow a general pattern so each question maps to a outline heading.
Users will often return to things that either really make them happy or annoy them to no end.
Users give examples of things they do like from other applications. I believe it’s an aspect of my job as the user experience designer to distill what technique the references software is doing well and include it into whatever I design.
A user interview can often be like watching an episode of Game of Thrones. There are 4 or 5 different story lines all going on and the interviewee will often call back as they unpack their mind about what it is that they actually do everyday. Writing all those data points on a giant whiteboard wall helps me uncover commonalities. These end up as epics in user as story mapping cards.
Armed w/ interview information I finally felt like I had my head around some of the challenges the analysts were facing. I was able to become one of them much in the way method actors become their characters (PS I’m writing a full length article around this topic).
The current software is a rules-based system yet our product would be driven by Artificial Intelligence through the use of techniques like NLP and Deep Learning. This data established our acceptance criteria:
- Analysts would need a channel in which to provide feedback to the data science models
- Actions taken by the model need to differentiate from user actions
- Comments should be tied to a potential violation not the whole alert itself
- Contextual information is needed to provide additional data to assist the analysts when they make a ruling on the legality of the communication.
- Utilize screen space on enterprise issued monitors running 1920 x 1080 resolution
Understanding the workflow of how a task it completed allows you to understand the factors that will influence the information architecture of a given view. It also gives you insight into the features being used in secondary software. If you can include these features in your designs then there is a greater chance for a high user adoption rate.
Quantitative vs Qualitative
Post the Alpha 1.1 release (actually the 3rd iteration of the design started 4 months earlier) I learned the breakpoint I’d chosen was not in fact the default resolution for the users. They used twin widescreen dell flat panel monitors at 1920 resolution. It was like turning a corner and discovering heaven. Think of all the screen real estate!