+1 vote
91 views
Post and review answers and feedback to answers in the comments section of this post.
asked in Product Design by (559 points)
edited by | 91 views

1 Answer

0 votes

To clarify – we are being building an app for a defined customer segment – truck dispatchers – and truck dispatchers are the ones working behind the scenes assigning cargo to trucks and ensuring routes, safety and cargo-specific protocol is adhered to, to ensure the cargo reaches it’s destination on time.

Interviewer confirms.

What is the goal we are trying to achieve? Enter a new market, test a new type of segment for later expansion, compliment our product suite?

Interviewer confirms asks me to decide – I’d pick we’re entering a new market with high potential.

It’s important to understand more about our customer and their needs at this stage:
A dispatcher needs
1 – information on truck availability
2 – to know the cargo requests pending at any given point in time
3 – to know where a cargo-carrying truck is at any given point in time
4 – to know the best routes from point A to point B
5 – to check all the paperwork for a cargo is in order
6 – to communicate with the driver in case of emergency

1,2,3 and 6 would seem to me like the primary needs of a truck dispatcher – if we’re short on time, resources, we can get to 6 later. 4 is a simple maps integration and 5 is a nice to have and may potentially not be the job of a dispatcher.

Given the prioritised needs, and the nature of the communication involved – there will need to be two versions of the app – one for the driver and one for the dispatcher. I’m going to assume the app for the drivers has already been designed and list out solutions for the dispatcher’s app:
1 – A real-time list of available drivers and their current location
2 – A tab to show cargo-in-transit, changing their colors based on their proximity to the destination (red far, amber halfway, green close)
3 – A tab to show incoming cargo pick-up requests from companies/third-party partners
4 – A feature to assign trucks to particular shipments
4 – An action button to prioritise pick-ups based on premium payments (certain cargo shippers may have requested fast-service at an additional cost)
5 – A simple app-to-app communication system with the option to switch to cellular calls (should drivers lose internet connectivity)
6 – A feature to indicate any incidents – red light jumping, accidents, paperwork missing

In the interest of time, and the resource constraints, I’d like to prioritise some of the features based on customers needs, dependencies – certain features have external dependencies that will delay implementation.

Feature 1 – meets the need of truck of availability
Feature 2 – without the colors (that’s unnecessary at this stage) meets the need of knowing where the trucks are
Feature 3,4 – meets the need of knowing incoming cargo truck requests and assigning them to trucks
Feature 6 – meets the need of communicating directly

I would go with these. I would also perhaps eliminate feature 6 and replace it with a simple click to dial feature (assuming the driver’s numbers are stored in the database with their profile).

To summarize – we’ve designed an app for truck dispatchers to be able to track trucks with cargo, incoming truck requests, find available truck drivers and communicate with them.

answered by (13 points)
0
Hi Nikhita

Thank you for submitting your answer. You follow the right steps to answer the question. The needs are clear. The features are also good. I have a couple feedback for you:

– I think your goal should have been more user focused. Example would be “enable dispatcher to stay connected to the dispatching services at anytime from anywhere”

– given that the dispatchers most likely have access to a web portal today, you can think about some of the problems that are not met with a web service using a desktop computer (e.g. urgent communications, checking status on the go, etc). I think these are very important needs / problems you can highlight. Basically, you want to clarify if the mobile app is replacing the web app or complementing it and then start listing out the needs / use cases

– I think resources and implementation cost should be considered as an evaluation criteria for the features and not needs. You don’t know the features (solutions) when you’re listing the needs yet. There might be an easy way to meet a need with a feature. So I suggest considering implementation cost as one of the criteria for evaluating features
0
Thank you – I appreciate the feedback and will incorporate it in practice.

Please log in or register to answer this question.

Privacy - Cookies - Terms - Contact