Multiple actions on a single search bar

Question

Can a search bar have multiple actions that the user can take on it?

Context: I'm designing a system for a bike shop to manage the maintenance of all their bikes. Currently the mechanics fill out generic paper sheets by hand and once a month the manager manually adds them all to a google doc. The new system would let mechanic print out a custom paper sheet, then go into this app and update it themselves.

Problem: So the mechanic has two actions they need to do once they've entered a bike's number: print out the sheet, and log the repair. Is it acceptable to do two action buttons underneath a single search? I'm imagining it a bit like the Google Homepage, where you can do both 'search' and 'I'm feeling lucky'. If you hit enter, it would default to logging the repair.

Is there any UX pattern this is breaking? Is it intuitive?

Constraints: Mechanics may print out a sheet and then not come back to the site until much later. Mechanics generally won't need to print out multiple sheets at once. Mechanics can't leave the repair page open as it is on one shared computer for multiple mechanics. All the bikes have a 3 digit number. Every search will return exactly one page (i.e., I can't search '23' and get '23, '231, 234'.)

Answer 1

I would avoid displaying those buttons until the search process resolves. Google's a bad example since the result doesn't require an action if it's not what you wanted.

The two buttons you propose don't account for sad path cases like:

1. That ID number doesn't exist
2. The entered ID number esists but wasn't the intended record (eg I transposed numbers or fat fingered something)
3. The entered ID exists but isn't valid (eg its been completed and archived)

If you put the buttons on the screen before the search returns results, you're creating a process where you need to validate the action again anyway.

---

I suggest an autocomplete or type ahead style search that displays records in an ever shrinking list. Then add the "action" buttons to each returned record. Its not really additional effort for the user and it solves a lot of UX issues that you'd need to catch otherwise.

Answer 2

I assume you had spent some time with the mechanics observing their actions and interviewed them for some tips on the system. This is very valuable input.

But aside from this, think about the following user journey:

• the mechanic types in 3 digits of the bike number - now the basic info on the bike can be obtained - display it and it will serve as validation whether the number was entered correctly - the mechanic can check on the type of the bike, colour and other characteristics and clicks on "Select bike" or similar
• selecting a bike opens a new tab (more tabs simultaneously possible, I'll explain it later on) with the bike info, large button "Print bike sheet" and some input fields to log on the repairs. "Save" button and "Done"/"Close" are optional, depending on how you're planning to log the repairs
• now the mechanic can either print the sheet and close the tab, or have it open and log the repairs as they go.

More tabs opened simultaneously allow every mechanic quickly access the sheets/info of the bike they are working on - you mentioned there is one PC for more mechanics. Imagine each time one of them wants to log some repairs, they need to type the bike number time and again, just because a colleague was logging his work in the meantime. Only make sure that the tabs are marked unambiguously (e.g. with bike picture, name and model, colour or even mechanic's name) so the mechanic knows they are on the correct tab in the blink of an eye. You don't want to end up with repair data of one bike logged on another one.