Fintech work – insights and learning
This post contains various insights and useful things I learned during the twenty years I spent designing fintech products. However, before I get too serious… This cartoon is a classic example of my fintech design nerd sense of humor!
Realistic Data
Most of the population does not think visually, and are usually thrilled when you put their abstract ideas into a design. Ironically, financial professionals will give you very abstract concepts to illustrate, but are rarely able to react to your designs unless they are presented in a somewhat concrete way. I have found that the best way to approach Fintech prototyping and mock-ups is to always illustrate real business ideas and to use realistic data sets.
There are two reasons why Fintech prototypes should reference real business ideas. The first reason is that stakeholders need you to take the financial concept out of their mind or PPT presentation and put it in a product context. Even though it’s just pretend links and dummy pie charts (as shown below) the stakeholders are seeing their idea in the language of a product. The second reason is that Fintech prototypes facilitate business thinking. We like to hive off the design process, but I find that if we let the ideas flow and let the stakeholders participate in envisioning, we get a better product. Additionally, this prototype/business idea hybrid is great for buy-in. Since everyone got to participate in the early stages of development, they are less likely to feel contrary about the product later down the line.
Financial professionals not only think in numbers, but they can’t think without numbers. When you show a mock-up to a financial professional they immediately look at the data not the design. That said, I only show believable data sets to customers. First I make sure that the words sound right. Dummy client names need to sound plausible, and any financial terms need to be the real thing, no made up asset classes. Most importantly, I make sure that the calculated values are correct. This is because the instant a financial person sees a discrepancy, no matter how hard they try to ignore it, it distracts them and they can’t focus on the task at hand – giving feedback on a design.
Prototyping
Cover your ears, and don’t mention this to the design police. I am aware that this is a very uncool thing to admit to, but I have found Excel to be the most accurate way to mock-up designs for reporting content. With Excel I can mimic the front end result, while at the same time present tabular data that is mathematically correct. This technique allows me to efficiently iterate with customers to get the design and specification approved before we move to front end production. Excel is not pretty, but it saves time and money, and results in happy customers.
Follow through
Follow data behavior through the entire development cycle because it is critical to a successful user experience. Even though you may have passed off a specified design to development, don’t let go of its outcome. Pay attention during QA and make sure the data is behaving as intended because that is critical for a successful user experience. Don’t hope that QA will find discrepancies in data behavior; you need to look for them, because you know what to look for. Advocate the best outcome for the end consumer at all points in the development cycle. Data behavior is a block and tackle thing, you have to keep refining it as you design, one pulley round at a time.
Domain Immersion
Take the time to learn the domain of the people using your products, so you can really design for them. No matter how you slice it, Fintech is an industry driven by specific financial domains. Management conversations will almost always reference domain, because it is key to business strategy. If you don’t have at least a little domain understanding you really can’t follow along and make productive contributions. Looking at high level business strategy through a design lens can bring unique insights to your business. Don’t cause your business to miss out, just because you can’t follow along.
Use your professional compass to learn the domain and contribute to business strategy. You will be surprised how helpful domain conversations can be in furthering your design agenda. First off, if you know something about the domain you will have a much easier time starting conversations. Whether you are talking to a colleague, customer, acquaintance or a stranger in an airport it is good to be prepared for domain conversation should it arise. You never know who might have that great insight that will solve a problem, or that poignant story that gets you thinking about a new product direction.
Research
When I sit down to have a discovery conversation with an investment professional about their area of expertise I say specifically this, “I don’t know how that works, can you explain it to me?” Or even if I know a great deal about the topic, but want to check my assumptions I say, “I am familiar with how it works, but perhaps you could explain your understanding”.
If you ask someone to explain something to you they will inherently give you a clear considered answer. The subtext of the word explain is “would you be so kind as to teach me”. If you ask someone to “tell you what they know about a subject” you are asking them for a different thing. By using the word “know” you are inadvertently testing their knowledge. Testing of knowledge is not an easy conversation route with investment professionals. If you are trying to have a discovery conversation it won’t go well if you have put the user in a defensive mindset. By using the “I don’t know, can you explain it?” tactic you allay any threat of competition. The result will be that you have a much easier time gathering requirements and successfully accessing needs.
It is also good to know when to use the “buddy system”. Say you need to design daily analysis tools for bond traders. Fixed Income is very complicated, so make sure that you bring an analyst with you to the discovery session. Prep the analyst beforehand about what language to use to ensure the conversation flows, and the trader is kept in the proper mindset to convey his or her requirements.
If you go in alone, your lack of domain understanding will prohibit you from getting anything out of it. You won’t know what questions to ask, absorb what the trader is telling you, or have any idea about which parts to follow up on. Instead of wasting your time and the trader’s time, ask for help from an analyst so that the session is productive. If the trader feels the session was productive, he or she may offer a follow up interview to answer targeted questions. You want to set yourself up for this because you will need additional feedback to correctly design the tools.
Details
We are all very busy making “big design” happen, but as they say “the devil is in the details”. The details inform us of where we are, and what needs to be done to move forward. It is essential to find time to do the “deep work” required to required get things done, and properly apply your craft. The task can be prototyping, drawing icons, or drafting emails, regardless of what task it is, do it with focus and intent.
