What the user needs

“… the standard search for the reports, this should be quicker than usual, we can reuse the search functionality we removed earlier…” Nearing completion of the marketing preferences system, this suggestion came up during the discussion for the inevitable reporting requirements.

It occurred to me that the reason for removal of the search functionality – searching for marketing preferences by first/last name etc – would be relevant to the reporting as well. Just as no one would be interested in searching for marketing preferences of users with some first/last name, there should be no need to put together reports for such conditions.

All the marketing department would like to know is data relevant to the campaigns they put out i.e. the total numbers of people who signed up or said no for a particular channel (email/post/sms/phone) would suffice. So a few text boxes or select lists to allow the selections and printing out the number with the conditions would do the trick. The marketing department agreed and the work took a few days instead of weeks.

The Scrum process tends to get people set in a ‘mode’, for want of a better word. Stories generated by a single person (Product Owner or Analyst), maybe looked at by one/two other people (senior dev or architect), are fed into the gristmill for the breakdown, estimation et al. Quite often what are missed, as above, are the actual needs of the users. The things they may not be able to tell you since they don’t know what’s possible.

Its quite possible the reporting system mentioned above would’ve been built like all others and the users would’ve accepted it since they wouldn’t have known better. Weeks would’ve been spent writing code, testing & sorting out the inevitable bugs, likely to be more in a more complex interface.

The best way to avoid such wastage is to be in sync with the users. As many of the team as possible should know them as well as possible. Sit with them when they work, chat with them regularly and have them with you in as many stand ups/meetings as possible.

Unless the team members, or at least some of them, can recall relevant details easily and can lay out the processes, business and the code side, from memory, they wouldn’t be knowledgable enough to bring up the options their users haven’t thought of, nor would they have the confidence to do so.


Active async feedbacks

“So…” began Simon, my manager, sitting upright in the chair he’d pulled up as I was planning to get up & head home, “I was thinking from the viewpoint of an elderly person”.

“Like yourself” I quipped. Julian, the developer at his desk nearby, cracked a smile.

“In time, and with luck, sure”, Simon countered. “It’ll be a bit daunting for someone like my mum, who’s not tech savvy, to…” he moved on to comments about the screen shots I’d put on messenger earlier. By the time we’d finished, the design for the work I was doing had changed a bit. Earlier during the day, I’d answered queries about the screenshots and the related workflow on messenger.

Async, short for asynchronous, means not occurring at the same time. This post suggests interacting with stakeholders & team members actively when they can spare the time to validate work being done/designed during a sprint.

While collection of feedback using shared/online docs is quite normal, using it to validate & especially work out the next step/s on work being done at the time is relatively rare in my experience. The above dialogue was in aid of a new piece of work implemented using a JavaScript library not used before by our company & the UX expert’s influence was a bit limited – we’d to go with what the library offered. So it made sense to let everyone know at the earliest the  shape of things to come.

But even for normal workflows, where the design is decided in advance, it can be useful to request feedback while doing the work. Various factors come to fore during development – how the flow works in practice (seen first on developer’s machine), the actual layout of things, tech issues encountered etc. – which may necessitate change.

Plus, it’ll bring home the design to everyone who cares to look at the screenshots. Shockingly, not everyone fully reads or comprehends the design docs. This way the customer is not in dark till the UAT.

A good messenger/chat app (we use Slack) is all that’s needed to keep things moving while waiting for everyone to chip in, if they’d like to. Quite often it’s one or two  stakeholders who have an interest or relevant input, while others just need to be kept in the loop. Different developers seeking feedback for their work can keep this process as distributed as possible.

The time spent by the developers for this sort of activities will most likely be less or similar to that spent in the usual way of things – formal meetings et al. In any case, the benefits of a two way dialogue with the decision makers cannot be overstated. Keeping them abreast of things, knowing anything they’ve discovered since the last time their input was collected, keeping them updated about how things are progressing etc, all bring true agility to a piece of work and help in shaping & putting together the right product.

On the flip side, you may get cornered at the end of the day by someone for a prolonged discussion – don’t say I didn’t warn you 😄.