I’ve been advocating for customer-centric design as long as I’ve been designing solutions for customers. I still do this, because I have to. It’s remarkable to me that after decades of building high-tech solutions for customers, technologists still seem to build solutions in an IT vacuum and then get upset when customers don’t find them very functional.
Gold plating is a term used to describe developers who infer customer requirements and subsequently build features that the end users never requested — because the developers know better. Unfortunately, data scientists are carrying this tradition forward with analytic solutions. That said, I wouldn’t categorically dismiss any requirement that doesn’t come from a customer or end user. It may seem odd coming from such a strong advocate of customer-centric design, but there are aspects of a well-built solution that customers don’t know or appreciate.
When designing a big data analytic solution, make sure it includes a well-rounded set of requirements, including ones that the end user won’t directly know about or care about.
FLURPS is a great acronym that I learned as a young computer programmer, and it works great as a template for building well-rounded analytic solutions. FLURPS stands for: Functionality, Localizability, Usability, Reliability, Performance, Supportability. It seems like a lost acronym that I’d like to resurrect to help us design and build better solutions.
This funny-sounding acronym reminds me of a big, hairy puppet like Mr. Snuffleupagus — that’s why it has stuck in my mind for so many years. Let’s go through the different elements of FLURPS and how they can enhance your design.
Functionality remains the key component of design; it represents all the features the customer knows and wants. When building a requirements document, most analysts separate functional from non-functional requirements, which is a good practice. Furthermore, functional requirements should always take precedence over non-functional requirements. Never sacrifice functional requirements for non-functional requirements — you should satisfy non-functional requirements in addition to functional requirements.
Localizability handles geographical concerns such as language. Internationalization (or i18n, for those in the know) is closely related to localizability in that it architecturally provides the technical infrastructure to localize a solution. Knowing that your recommendation engine will be used globally, you may internationalize it by automatically sensing where your user is located, and then localize it by providing, for example, German-, Russian-, or Chinese-specific content. Bear in mind that good localizability extends beyond language translation and caters to cultural differences in functionality.
Usability deals with the customer experience. This is a pet peeve of mine — I’m tired of seeing analytic solutions that force the user into the mind of the developer. For instance, it’s very common to see use cases where a batch operation seems obvious, but the solution only allows single transaction processing. If I could possibly have hundreds of input variables to my predictive analytics engine, why should I have to create them one by one?
Although usability seems like it should fall into the functional category, it does not. Most customers don’t know how to design a usable solution; however, they know when it’s not usable. Putting a user experience expert on your team is a fantastic idea.
Reliability handles the stability of your application. Reliability is not something end users contemplate because they assume your solution will be stable; when it’s not, frustration can quickly escalate to extreme dissatisfaction.
You must build reliable solutions. How many times have you lost work because your system crashed? And by the way, a cute little icon telling you that the system crashed doesn’t help. Build requirements into your solution to recover from exceptional situations and gracefully exit only when all possible routes of recovery are lost. I once designed a web application that went through four or five levels of exception before it finally, gracefully quit — after saving all of the user’s work. The users never knew the application was going into its third and fourth level of exception, and that’s the way it should be.
Performance is a bigger deal than you might think. I recently trained a group of users on a new web-based system that would on occasion take several minutes for a submenu to appear — the industry standard is between two and three seconds. The performance of the system broadcasted the quality of the rest of the system, and it wasn’t positive.
I know performance issues can be difficult to track down, but that’s your problem, not the users. Make sure reasonable response times are documented in your requirements and thoroughly tested when the system is built.
Supportability is the last, but not the least important, component of a robust design. Whether you’re designing a product that will be used by customers or an internal system that will be used by employees, it’s vitally important that the operations group is in a good position to support the solution.
For analytic solutions, supportability often extends beyond requirements into organizational design. The instrumentation on an analytic solution is often sophisticated, so it’s important to staff the operations function with very knowledgeable technicians — maybe even other data scientists. When I’m putting together a development team, I often include at least one person from the support team; this way, they can influence the solution’s design from the perspective of someone who’s going to support it.
Building a great solution starts with the customer, but it doesn’t end there. Although your analytic solution should favor what the customer wants, there’s a significant area of design that the customer can’t know or want, but they definitely need. You should stay away from gold plating (i.e., injecting functional requirements) and instead use FLURPS to build well-rounded solutions that will keep you and your users happy.
FLURPS is a funny-sounding acronym, but bad design is no laughing matter.