Fidelity Full View: almost Intuit quality

I had been a Mint user for years, until Intuit purchased the group and added their characteristic bureaucracy and “we don’t really care” customer service stamp to the operation. One of the final blows was when, shortly after the acquisition, Mint suddenly reclassified HELOCs as credit cards. A large number of people, including me, posted separate threads on their support site complaining about the change. Their answer, over the next two years, was essentially “gosh, there’s just nothing we can do to fix that, it’s just too hard.” Two and a half years later, from what I understand, Intuit first fixed the problem then, days later, broke things even more badly to the point that now even mortgages are classified as credit cards. Sweet, Intuit.

In the middle of this I discovered that my bank, Fidelity Investments, offered a web app called Full View, that offered most of the same functionality I’d liked in Mint, and in fact uses the same aggregator, Yodlee. Account aggregation, budgeting, transaction classification – all good. The Fidelity app wasn’t (and still isn’t) even close to Mint in terms of usability or gloss, but it worked.

That was the case until a few weeks ago, when Fidelity, with much fanfare, released the new version of Full View. (cue Fraü Blücher’s horses in the background).

What a damn mess.

First off, they’ve clearly gone the portal route, cobbling together a lot of prefab widgets at the cost of a pleasing, well-integrated user experience. This is a classic example of the user experience delivered when an IT group researches solutions and then uses the results to determine what users want (translation: what IT wants to build, including all the little gadgets and bits of coolness that appeal to geeks but mostly get in the way of normal users). That would be bad enough but manageable if those widgets actually worked. And they don’t work all that well. IT is not the same as development: I would never want a member of a development team maintaining servers – nor would I ever want an IT engineer developing an application, much less designing a UX.

Let’s start with data handling, because I get too pissed of talking about all the 404 errors that get thrown transitioning from the dashboard to subordinate views and back to speak of it at length. Sufficed to say: OMG. Entering data, modifying the name of a transaction’s vendor for example, is pretty basic stuff. Anyone out of high school understands the concept. But with Full View, I’ve had to re-enter changes over and over, across sessions, across days, because the changes get lost. This isn’t just bad session handling (that’s pervasive across the new version) but somehow they’ve managed to corrupt the data after it should have been stored persistently in the database. You’d have to go out of your way and write code to do that. They did – although I don’t think it had anything to do with intention.

Then let’s talk about character set handling, things like punctuation in a title, for example “Gold’s Gym”. On their Transactions page, this appears to be handled correctly, but in their dashboard view making this change results in “Gold's Gym”. Their customer service folks offered the solution of “well, you should just use the Transactions page for that,” a secondary page that takes forever to load. I haven’t encountered this sort of crap for probably ten years – at least not from a professional group. And forget autocomplete or any sort of elegant categorization.

Other features like adding a note to a transaction, or splitting a transaction, have been moved from the main page exclusively to this subordinate Transactions page, an “improvement” as described by Fidelity Customer Service. UX FAIL.

And in the days of HTML5, H.264, Canvas, all the vector tools available, all of Full View’s data visualization appears to be based on Flash. Seriously?

Finally, the data displayed in Full View, even when “refreshed”, lag the main Portfolio page by around a full day. When I called this out to Fidelity, the response was sort of “oh well, that’s a really hard problem to solve.” Which puts them right in the Intuit category of competence. This is a bank that, on one web site, displays two views of your financial data, one that is up-to-date and one that is from yesterday. And claims there is no way to resolve that.

At the company I work for, producing a user experience that is delightful is one of our cardinal goals. We frequently use the term “delight” in our proposals, even in our contracts.  With the pre-Intuit Mint, there was a fair amount of delight in using the app, in the nimble UI, in the data visualizations.

There is no delight in Fidelity’s Full View: it’s a portal-oriented, forms-based UI that looks, and behaves, like something from the 90’s, and functionally appears to be built by a team stuck in that decade – the lack of stability, the demonstrable lack of code re-use, the almost complete lack of aesthetics, is downright discouraging. The UX blunders, the coding errors, the clear misses in session and data handling border on spectacular. Fidelity’s customer service is, at least in their interactions with me, in full-on “circle the wagons” mode, denying that there is actually a problem, that the app is performing just fine. In other words, they’re basically useless.

This is four weeks after they launched the new version. Which doesn’t bode well for anything getting fixed real soon.

 

UX design and Agile: an awkward interface

Agile is a hot term in the industry. So are terms like object oriented and web 2.0. And like those other terms, agileis frequently misunderstood or misused. Or it becomes a hammer in search of nails.In this article, design to refers to methods employed when creating a User eXperience, or UX. Things like concept development, interaction design and visual design. Engineeringmeans standard activities like architecture, development, testing and continuous integration – things that make up the activity of turning a UX design into a real user interface that a person can touch, or click, or swipe.I started out thinking mostly about design, engineering and process, but ended up considering the relationships between different processes and risk. Risks like running over time and over budget, or ending up with a product that doesn’t really express the key nuances of the UX design.

Getting agile

Agile methodology, fundamentally, assumes the ability to encapsulate work into small tasks – the agility comes from the high degree of granularity and the ability to reassess progress and change direction after a smallish amount of time. Agile methodology further assumes that these tasks can be prioritized. And, generally, it assumes that teams can compartmentalize the work into sprints, usually one to three weeks in duration.

In practice, tasks are extracted from user stories and sized via the use of story points, a point being an arbitrary unit, a convention that describes the ability of the team to consume work. For example, an item might be assigned the value of 10 story points, or a team may decide that they can consume 150 story points per sprint (their velocity). Once identified, the tasks are prioritized, then placed in the backlog, the queue from which new work is assigned.

An important point: an agile team pulls a sprint’s worth of work from the backlog at the beginning of a sprint – but any work arriving after a sprint has started is prioritized, placed on the backlog, and considered at the beginning of the next sprint. In short, no new work is added to a sprint once the sprint has started. This allows a team to develop accurate metrics around their ability to do the work, reduces randomization of team members, and generally preserves sanity. Risk is mitigated by the ability to assess progress in short intervals, to make course corrections quickly, and to reprioritize tasks as required.

UX design: holistic by nature

The mention of design often conjures up a process that is more fluid, more nimble, than engineering. But that fluidity can actually prevent design from lending itself to agile methods: designing a UX is essentially an holistic process, where any change in an interaction model may need to be integrated across all parts of a user story, or even the larger context of an epic, or collection of user stories. A large number of tasks may be identified within an epic – but it may not be appropriate to transfer those tasks to the engineering team until the entire epic is completely designed and frozen.  This can apply to visual design as well, where changes in branding, style or design language can have impacts across many parts of a design.

Indeed, that condition might extend to an entire collection of epics, or an entire application, or an entire suite of applications. The risk here is that assessment of progress against scope and schedule may only be possible after large amounts of work have been completed.

Keeping the loops small

While still contained within the design process, changes can be resolved within the design team. Once handed off to the engineering team, however, surfaced changes frequently need to be fed back to the design team for resolution:

The larger the loop, the more expensive the change, and the bigger the risk. And the loops are unpredictable, adding even more risk.

Waterfall as an alternative

Another development methodology, “waterfall”, requires that work items transition from one group to the next through a gate of sorts, where the implication is that the work being transferred is “cooked”, or “frozen”, or complete, essentially freezing risk as well. This process is usually seen as traditional, old school, rigid, antithetical to the freedom and flexibility of the agile method.

All that’s true.

Hybridization

At the same time, there may be places where a gated handoff is beneficial in the sense that it keeps the loops smaller.  The holistic design process would lead to a frozen body of work that is passed through a waterfall-like gate to an engineering team using agile methods: a hybrid process.

The three-legged stool

Three parameters affect a project in general: scope, schedule and budget. Fixing more than one of these increases risk dramatically, yet by far the most common case is a project where budget and schedule are fixed, while scope remains bit fuzzy when work starts. Running on a fixed timeline with a fixed budget means a defined amount of person-hours is available; if scope increases, working hours in the schedule increase outside of budget, and margin falls. In an agile environment, scope changes are usually handled in the backlog prioritization, the assumption being that if scope increases sufficiently, some lower-priority tasks may not get completed. That’s a difficult concept to communicate to a client.

There’s no such thing as a free lunch

Everything in design, and in engineering, is a matter of compromise. The hybrid process described here assumes that UX design work reaches a predetermined complete state before the engineering process begins on that part of the design. This may mean that the design for the entire project should be completed first. It means that some design resources will need to be retained during the engineering phase, as changes will inevitably be required, to preserve the UX fidelity of the final product. It means the schedule for the project will probably be longer. In practice, however, the overall timeline usually suffers more from those large, unpredictable loops called out above. And in the end, correctly sizing a project, mitigating the risk and executing within project parameters are the factors that lead to success.