A Client s Guide To M O D E R N S O F T W A R E
Init() As software developers we see our fair share of software atrocities. Systems we re hired to fix, systems we need to integrate with or build upon, and I m ashamed to say, some systems we may have had a hand in creating. When we come across offending software we all ask the same question: How did this happen?. I believe the failure often lies with looking too closely at individual functions and not noticing the bigger picture, until it s too late. This document is intended to help Clients and Product Owners by highlighting some of the key problematic areas I ve witnessed. I would like to think this might be useful or at least enjoyable to developers too. LimeNinja 11.1%
No Manual, No Training User experience (UX) has been around for a decade, yet often software developers are unaware of many of the principles involved. When timescales are tight, a developer will focus on making the product work, not on making it usable. Modern software shouldn t need an instruction manual or training. If the end user requires either, the UX is bad. On public systems this will cost you active users; on internal systems this will cost you in productivity and training. Imagine if Facebook, Amazon or YouTube required you to read a manual before use. These are all complex systems yet incredibly simple to use. LimeNinja 22.2%
Error Messages Errors should be avoided wherever possible, but unfortunately some are inevitable. On these occasions information on how the system works, what inputs it s expecting etc should be gleaned from helpful, clear messaging. Example If you have an upload field that only accepts video s. Showing an ERROR NUMBER AG415 or whatever your developers may understand is not helpful to the end user. However a message like PDF is an unsupported file type, please upload a video file can guide them in the right direction. Solution Make sure informative error messages are part of your acceptance criteria and regularly do your own testing with real end users. LimeNinja 33.3%
Time Wasting Another area of UX that is often overlooked is load times. It s too easy for developers to create functions that work - even though they make multiple database connections and run some really inefficient code to parse the results. If the page takes 30 seconds to load then who cares? If the client doesn t mention it, then it s not wrong right? Example I recently heard of an internal system which had pages which take up to 8 minutes to load! Think about that, so if only 20 employees needed to access this page 2-3 times a day you are essentially losing a whole person s salary to this single page! Solution When you are writing your scope make a 10 second load time part of your acceptance criteria, you will almost certainly get the extra development cost back in savings several times over. LimeNinja 44.4%
It s Not All About IE Enterprise clients will often require web based software to work on a specific version of IE (Internet Explorer). This is normally due to a current internal system which only runs on one browser. Modern software should run perfectly on all modern browsers at any screen size, and the user experience should be the same on all of them. Example On public systems you may witness 40% or possibly more of your traffic coming from mobile bowsers. For internal systems also working to this standard will allow your employees to be more productive while off-site. Solution Your acceptance criteria should highlight the minimum version of IE your software needs to run on but also require it to be responsive and supported on all the latest versions of all major browsers (IE, Chrome, FireFox, Mac and ios Safari). LimeNinja 55.6%
It s Alive A database is a living thing. Every time someone interacts it changes. However the UI (user interface) hasn t traditionally been alive. In the past a user would load a static page and if they wanted an update they would need to refresh the page. Modern software should apply updates to the UI as they happen. Let s say you show the number of times a popular file has been downloaded in the UI, as more downloads happen this number should automatically update. If done right these small updates could actually save bandwidth and provide a really slick feel. Don t stop with just simple numbers either you can do this with graphs, comments, users anything! Whether it s a public system or internal it s these touches that increase engagement. LimeNinja 66.7%
Salt & Hash We all should be taking security seriously, clients and developers. At the very least all software which stores passwords or holds any personal information at all needs to be protected with an SSL certificate. All passwords should be salted and hashed as standard. Note If you don t know what these terms mean, ask one of your developers. If they don t know what they mean - you may have a problem! Example One system we were recently asked to work on stored passwords in plain text. In addition the software didn t utilise an SSL certificate and required the user s credentials in each API call. Solution Please make sure your software is protected with an SSL certificate and ask your developer if passwords are salted and hashed. Consider hiring a PEN (penetration) tester. LimeNinja 77.8%
Think Lego Software should be built as modular and extendable as possible. With this mindset you & your developement team should try to break your project down into smaller blocks, each with its own single responsibility. Example Hard coding all text directly into the code when a system only requires support for a single language. It s easy to think there is a time saving here but there is not. Firstly, the only way the client can check all the text in the system is to navigate to them all. Secondly, a single change may need to be done in several deeply embedded areas. Lastly, the software can longer be easily extended in future without substantial cost. Solution Tell your developers the software may need to be translated or built upon in the future. LimeNinja 88.9%
Return; Author I could go on but I think that s enough for this document. Hopefully I ve given you enough to think about. If you found it at all useful please share this document as-is wherever you like. I would also appreciate any feedback and if enough of you like this I will try to write a part two. Paul co-foundered a software development house called LimeNinja. He occasionally writes articles online so if you enjoyed this please follow him on LinkedIn: tinyurl.com/followpaul If you have any questions or feedback you can contact Paul using: 07727 100 898 paul@limeninja.com uk.linkedin.com/in/paulsapnik Or LimeNinja using: 0800 086 8767 lime.ninja @limeninjas yo@limeninja.com linkedin.com/company/limeninja 100%