Lessons from building software: developers' moment of truth
By Kennedy Kirui
Published 31 Oct 2015
Share this Article
The “Moment of Truth” was a popular American TV show where contestants the host asked the participants 21 personal questions under a polygraph test for the chance to win cash. To make it interesting the host asked these questions in front of the participant's most intimate group of people.It could be your spouse, girlfriend/boyfriend, mother, boss or a close relative. Safe to say most outcomes weren't pleasant. So what does software have to do with this? For a developer what phase in software development would be considered as "the moment of truth"?
In a utopian world software developers would build software for themselves. If they are the users the software would work perfectly. Unfortunately, apart from software tools like IDEs and programming languages applications designedfor users who are not software developers. There is always a divide between how developers think and how the users think. Your level of interaction with the end-user while building software depends a lot on the design approach you use. Assuming you use a human-centred design approach you will probably interact with your end-user a lot before you launch the software. Typically with the team at iHub Consulting we use the following steps:
Sketches on paper depicting how the application flows. You then present the sketches to the end-user and they ‘click’ through each interface.
Clickable wireframes using tools like Pidoco and InvisionApp. This allows feedback from a larger group
Visual mock ups of the key interfaces
First prototype that a user can actually interact with
Four to five iterations based on user feedback before the product launches
This looks fairly simple and straight forward. At each stage you are getting user feedback and as a result by the time you launch you should have something that works flawlessly. Unfortunately, we have realised it is never that easy. Steps 1 to 3 are fairly smooth.
As a developer your"moment of truth"is when you present your first prototype to theuser. They always seem to do all the 'wrong' things. It contradicts the progress made from the first three steps. Tasks that seemed fairly easy become challenging for the user yet you involved them all along. All of a sudden the user doesn't even understand how to carry out a task they requested for.
Why is this the case? Visualising how an application will work is very different from actually interacting with an application. Should we then skip to the 3rd phase right from the beginning? I don't think so. Insights gathered from the first three steps greatly cut the amount of time spent making changes on the prototype. What more can you do to reducesituations like this? A few tips:
With the team leave the comfort of your office
Get the team to meet the users as early as possible in the project. Does it mean dragging them along on your field trips? So it be! If they can empathisewith the end users they will be more sensitive to their needs. Don't let them interact with the user in an office setting. Get them to see the end users in their natural environment. Many times we delegate thisto the UXer in the team. Try to get as many team members as possible to interact with the users from the onset.
Get the first prototype out ASAP!
Many times we try to design the system end to end before we present it to the user. The result is that you will have to make a lot of changes before the application is usable. Most applications have different sets of users. A reporting tool for example has two main facets to it: a data collection element and an analysis part. Focus on getting the data collection element part first and release prototypes to test this. Once you donemove on to the analysis section.
There is a lot more that you can do to improve the ease in which users adopt your software. There are tonnes of resources online that you can use to improve. Invest more time in this aspect of development and you will realise that you are releasing applications that are usable. We did a video for one of the projects at Consulting that captures this process. You can check it out below: