Take a step back to see the bigger picture. Ask why is this solution required, what problem is it solving, and is there an even better solution?
Consider the scenario, your client Reporto has an application that lists reports with statuses, and they tell you "We want to be able to filter these reports by status". Easy. Right?
You’d probably get a unique list of report statuses, create a nice bit of UI to show them, let the user click the ones they want, and show just the results that match those statuses. You’d probably really enjoy building it, the folks at Reporto get exactly what they asked for, tick tick, push it up, crack open a beer. Job done.
Well, actually, maybe the job isn’t done. The issue with working like this is that you risk completely missing the problem that their proposed filtering solution was intended to fix, and you risk adding a new feature to the site that most people didn’t really want or need.
So, what was the problem the client was having?
When development is so easy (and fun), and when the client asks for something that sounds simple and sensible, it’s sometimes difficult to slow things down and not follow your usual flow of opening Spotify, putting MC Hammer on, and firing up your editor.
You need to talk to them - get them on a call if you can - as you need to do some investigation before going any further.
Ask them things like:
- “Why do you need this feature?”
- “Can you describe some journeys through the application where someone will need to use it?”
- “What problem do you currently have that this solution is hoping to fix?”
Let’s expand the scenario with some possible answers from our client Reporto:
“Why do you need this feature?”
We sometimes need to be able to find reports which have certain statuses like ‘In review’ and ‘Failed review’.
—Steph, PM, Reporto
Interesting. There are (let’s say) 12 report statuses in Reporto, but Steph only mentioned 2, and both are related to reviewing a report.
“Can you describe some journeys through the application where someone will need to use it?”
It’s probably something I’ll do quite a lot. I’ll login, find all the reports which have failed their review and go through them one by one making corrections as needed.
—Ali, Editor, Reporto
Nice, we have a journey, which is essential to really understanding the wider picture of how a solution will fit into the applcation. What’s interesting here is how manual this process sounds for their editor Ali; we can probably do better.
Ali sounds like a worthy candidate for further questioning:
“What problem do you currently have that this solution is hoping to fix?”
We only make money from quality, published reports, and our reports are normally based on real-time data, so need to get them out fairly quickly and to a high standard. At the moment we find that unpublished reports can get stuck in the system and it’s a pain to find them, and detracts from time we should be spending writing new ones.
—Ali, Editor, Reporto
Right, there we go. A lack of visibility of these unpublished reports is costing Reporto money, and taking up the editor’s time. They need to find these reports quickly and get them finalised and published.
That call was a great success. Let’s write up what we’ve found.
Write down the problems as user stories
User stories are great ways to clearly outline problems that your clients have. They should be writen from one of the user’s perspectives and using their language where possible. User stories fit perfectly into our process here because they shouldn’t discuss the solution.
User stories normally follow a pattern like “As a ROLE, I want TO KNOW/DO SOMETHING, so that I CAN BENEFIT FROM IT”.
Here are some examples based on what we’ve learned:
- “As Reporto, we want to publish reports quickly and to a high quality, so that we can maximise how much money we make”
- “As an Editor, I want to review reports quickly and easily, so that I can focus more time writing new ones”
We should share these user stories with Reporto, they are a great “source of truth”. At Dragon Drop we use services like Trello for this.
Can we start talking about solutions now?
So we’ve got a clear picture of our problems, what’s next? Well we can now start talking about which solutions might solve these problems.
Clearly the editors aren’t getting the right level of support from the application to do their jobs. We can change that. With such a clear understanding of their problem a number of solution are normally available at this point, but let’s pick just a couple to discuss.
Editors need more tailored views
The first area I’d want to investigate is whether the homepage of the application for editors can be a list of reports that need reviewing or have failed review. This gives them a focused list of the reports which need their immediate attention, with clear actions to progress them.
The order of these reports could be based on their status, or how many days ago they were started, or when they were due - we should go back to Reporto and investigate this further. Publishing these reports could send the editor back to their homepage to tackle the next. These sorts of loops can help users to complete their journeys quicker and stay focused.
Editors shouldn’t have to login to see reports which need their attention
It feels a lot like editors should be notified when a report needs their input, rather than expecting them to remember to login and check. Depending on how quickly Reporto wants these reports to be published will affect exactly what sort of frequency/urgency your notifications might need - we should go back to Report and investigate this further - but let’s say we’re going to send the editors a daily email at 9am with the same list of reports that they’d find on their homepage. We could provide links in the email to navigate directly to the reports.
Make it so
You’ve come up with a couple of solutions that feel like they’re going make a big difference at Reporto. Time to run these back past the client to make sure they’re happy to proceed. You may want to share a couple of wireframes to help explain your vision.
But all being well you can finally open up your editor: It’s Hammer Time.
Closing thoughts
-
The solution Reporto originally requested wasn’t a bad one, but it only takes their application (and their business) one step further forwards. We should be striving to help our clients take great strides.
-
Did we come up with a solution that would ultimately cost Reporto more? In terms of the initial development cost yes, but good solutions save businesses time and money. Plus I would argue that the overall amount of development effort between the two proposed solutions isn’t actually that great - in some ways building a tailored view for a user role is easier than trying to squeeze a new UI component into an already cluttered view and making it work well for users will varying device and access requirements.
-
Be wary when asked to implement a solution, by anyone, even yourself! Even something as simple as “Can you add a back link to this page?” should be taken through the investigation process. Remember by taking the easy route you may be missing an opportunity to make a really valuable change.
At Dragon Drop, we’ve never worked with Reporto, but we have worked with numerous clients who have had very similar problems, and helped them to implement some truly transformative solutions. Get in touch today and see how we can help you with your next project.
— John Norris
Who are Dragon Drop?
Dragon Drop is a specialist web and app development agency. The team has extensive full-stack technical credentials and a strong focus on user experience.
The Dragon Drop founding team have over 40 years of web development and project experience. They have managed or developed over 100 significant ecommerce and web projects during their careers, including implementations for major UK high street retailers, financial services companies and government agencies.
Their approach to innovative solutions stems from perspectives gained as retailer, software supplier and web agency.