Problem: You’re working on a large, complicated machine made of multiple parts and functions. Something goes wrong. The machine shuts down, or it starts shaking, or a part starts making a whirring noise — something you identify as out of the ordinary. You have a manual on location, as well as an online version. You start searching for what may be wrong, but the manual isn’t labeled effectively or is not comprehensively indexed.

Solution: Barcodes are placed on each segment of the machine. Using a scanner device with access to an online manual, you scan the problem area, and the device auto-searches and locates the appropriate section of the manual.

Rough representations of a human and a tablet device.

Presenting... a human being with a tablet device (with scanning functionality and an onboard manual, or access to an online manual).

Human is confused at a complex-looking machine.

The user encounters a confusing machine, or the machine is acting in a confusing manner. ("Help!")

Human using a tablet device to scan a barcode on a machine.

The user scans a barcode (here, a QR code) physically applied to or near the problematic part of the machine.

Example machine manual page on a tablet device.

The tablet device goes to the appropriate section of the manual, based on that scanned barcode.

That’s it!

And if that part or section of that machine is used in other machines, similar barcodes may be printed on those machines. Also, sections of the manual may be updated without needing to re-apply barcodes.

The overriding goal or objective here is this: Users do not need to guess where to look in the manual to find help, and an onsite manual is not needed. However, the company would need to create an electronic version of the manual. That’s the hitch.

Problem: You have a process that varies widely, depending on what the project entails (i.e. a 100-page website vs. a Facebook Page). However, when you propose a solution to a client, you still do not have the hours required per task fully detailed.

Solution: A clear hierarchy of your process. A discrete but non-sequential list of steps that adjust based on what the client agrees to pay for, and what is deemed appropriate for the project. A task tree!

Example task tree for a website user experience design process.

First, the user creates a task tree with all of the possible steps in a particular project. Here, that project is a website design.

Now that the tree is created, the project manager or designer can pick elements (or “leaves,” if you want to continue the metaphor) from it and complete a project scheme.

An example task tree with elements selected and a list of suggested deliverables outlined.

The selected tasks are highlighted, and a list of suggested deliverables is created. From here, the amount of hours required for the project could be estimated.

It’s not robust, and it’s definitely a very rough concept. But the simplicity of being able to just pick and choose tasks from a complete and transparent selection and have a solid list of required project deliverables propagate… now that would be useful.

This could even be morphed into an application. Once a user selects all of the steps in the process, the system could auto-build a document template, from which the project team could complete and deliver to the client.

Problem: Imagine you’re using your app of choice, or you’re sifting through bookmarks folders in your browser of choice, or you’re working your way through the file menu or dock of your OS of choice. You’ve gone one folder in (“Bookmarks”), two folders in (“General Bookmarks”), three folders (“Fun”), four (“Movies”), five (“Comedy”), and you’re just about to click on a link to your favorite funny movie (“Jingle All The Way”)… then your mouse slips, left, down, wherever.

You just lost your filepath. It’s not a big deal, but if you use a computer like I do, you navigate filepaths dozens of times daily — more, if you’re an organization freak.


If I accidentally slide left...

The example menu path is diminished as the user slides left.

Dang it! Now I have to go back through and find my menu selection again.

Solution: One click locks a step in the filepath, a unit of hierarchy. An icon shows that this step or unit is actually locked, and there is a visual indicator of some sort that it is unlockable at any moment.

Something like this:

Locked menu demonstration - menu not quite full.

The user has just started navigating through the menu...

Demonstrating a locked menu - expanded.

...and the user desires the menu should stay put while he/she decides which option to select.

Demonstrating the locked menu - locking the menu.

So, the user clicks on the open lock icon...

Demonstrating the locked menu - menu locked.

...and the menu is locked at that position. The user may click the closed lock icon to undo this.

And that’s it! Just a simple icon change and some undoubtedly complex coding to make navigating menu paths somewhat easier.

I really feel like there could be a better way of indicating locked and unlocked menus, but the point I’m trying to make here is that for complicated paths, it would be helpful to prevent one’s own slip-ups with the mouse or trackpad by locking a section of the path.

Follow

Get every new post delivered to your Inbox.