Yes, you should.
Even if a user story requires zero effort to implement, it’s still important to apply the same principles of user-centred design and evaluate the suitability of a solution against an identified activity and goal.
Some features of commercial off-the-shelf (COTS) products have been in development for over a decade and are considered very mature. That doesn’t mean they’ll be considered usable and useful for your market. It probably means those features are very sophisticated, support many edge cases and have no defects.
From one angle those are all desirable attributes. From another angle those attributes can be detrimental. You’ll be tempted to just bolt them onto your product without assessing them against how people might perceive and use them. You’ll be less likely to put them through the same rigorous testing that your own code is subjected to. And being ‘fully-featured’ can actually interefere with what otherwise could be a straightforward activity with additional decision points and complexity at the user interface.
Take jQuery File Upload as an example:
As far as a file upload plugin goes, this has everything and the kitchen sink:
- Browse to file on computer
- Upload a file
- Cancel or abort upload
- Upload multiple files
- Delete uploaded file
- Delete several uploaded files
- Select all files and delete them
- Display size of files before uploading
- Display and update upload speed in kilobits per second
- Display and update upload timer in hours, minutes and seconds
- Display and update progress indicator as a bar
- Display and update progress indicator as percentage to two decimal places
- Display and update progress bar as file size uploaded
- Cancel all file upload activity
- File names for selected and uploaded files
- Upload a file independently of all selected files
- Commence upload of a file independently of all selected files
- Cancel/abort upload of a file independently of all selected files
- Larger file sizes shown in MB instead of KB
That’s a lot of features! You couldn’t expect a bespoke software product to contain all those features and would be unlikely to write user stories that would result in all those attributes, unless multiple file upload was central to your application, as it is for Dropbox and Google Drive.
But for most websites and web apps I’ve been involved with that have a file upload component, the workflow is pretty simple. Typically a single file of a size small enough for such verbose progress details to be not just inappropriate but clutter.
Can we live with the button being labelled “Delete”? Does it make sense to have a bulk upload-capable plugin when the form being completed by the user only expects a single file? Are people going to figure out they need to close the dialog once they’ve finished by clicking the ‘x’ icon because there’s no ‘next’ or ‘done’ button? Will files ever be so large as to need an upload abort button?
The following diagram illustrates the difference between a solution-centric view of evaluating out-of-the-box (OOTB) features and a user- or problem-centric view.
The solution-centric view (left) would see user needs as a subset of the features provided by the ‘mature’ solution.
Where the solution-centric view sees bonus features and ‘value add’, the user-centric view sees avoidable complexity that increases the cognitive load on users for what should have been a simpler, less-featured and better-integrated solution that supports the activity, for example:
- User comes to online form expecting to upload a file
- User already has the file ready to upload
- User selects the file from computer
- User submits form, which uploads file
- User walks away
Does not require a “file manager” idiom. Does not need to see files upload in realtime. Does not need to monitor upload. Does not need to review filenames and file sizes. Does not need to remove uploaded file. Does not need to abort a file upload operation. Does not need to think about uploading files as a sub-form of the main form that you enter into and then exit from to return to your main form.
The latter view can only be arrived at by following the same process as for the rest of your software and describing the tasks, objectives and situations of actual system users without presupposing a solution.
COTS products are often a great way to implement a solution cheaply and quickly, taking advantage of years of research and development by other companies. You never want to set out to replicate mature platforms and content management systems like Sharepoint, Drupal and WordPress. But have you ever tried to explain the ‘power’ of Web Parts to a content author and have them respond “But I just want to …”
Don’t fall into the trap of solution-centric thinking where more features equals more value. It’s often the opposite where poor integration with users’ mental models and workflow, additional buttons, form fields, screens and decision points actually decrease productivity and perceived usability of the solution.
If you can use an existing solution or plugin to satisfy a user story and any disrepancies or trade-offs are worth it (even if it means an increased abandonment rate or lower level of user satisfaction) then great, go for it.
Don’t be like Beni in The Mummy and load up your camel with gold treasures. It didn’t end well for him.
Stay focused on what you came for. Lead with your stories and work the problem space before moving into the solution space. Then and only then look to see what is available to use or co-opt, and assess its suitability against the story and acceptance criteria.