Nothing is more critical in a business setting than time management. There are only so many hours in a day, and it’s important to make them count. This is easy (or easier, rather) to do when you have a defined set of tasks to accomplish, but what about when things are more ambiguous? Working within a deadline is great, but what if that’s not communicated? How do you prioritize?
The simple answer is to make the most recent task you were given top priority, but that’s not an effective way to make your decision! There are a few schools of thought on this issue, and since they all have merit, I’ll list them all:
- Create a list of your tasks, and organize it into three sections: high, medium and low priority. Within those sections, order the tasks by their importance and cross them off as you finish them.
- Order your task list by the potential impact on the company. Is anything mission-critical? Do that first. Ask yourself what has the greatest chance to positively affect revenue, and prioritize accordingly.
- Ask a superior! Talk to your boss and discuss the proper order of your task list. This is obviously the easiest route, but not everyone operates this way.
Things can compound when the pressure is on and the stakes are the highest. Make sure that you choose whichever method works best for you, and manage your time effectively — it’s one of the most important things you can do at work.
Being detailed is a helpful attribute when it comes to product design. Detailing each part of a screen will make your specification infinitely easier for your engineer to read. Mockups should always be as precise as possible to what you’d like built. As a colleague is fond of saying, every pixel should mean something; if it’s not working for you, get rid of it.
Let’s play a game. In the two screenshots below, try to find any differences (hint: there are three)…
- The Address 1 and Address 2 textboxes are each a pixel narrower than the other three fields in the column.
- The Address 1 and Address 2 labels are two pixels further to the right than the other labels on the screen.
- The state abbreviation is a pixel further up in its textbox than any of the other fields.
Did you catch them? If not, don’t worry – it doesn’t mean you’re not detail-oriented. In fact, you could have an above-average eye and still not see the differences. What separates a Product Design Legend, like the late Steve Jobs, from everyone else was his laser attention to detail. He knew that he might have to push back a few releases, but in the end, he would end up with a superior product.
Guys like him were never afraid to sweat the details.
When it comes to Product Design, it’s extremely difficult to build something in your head. Concepts are abstract and are easily confused when kept within the friendly confines of your mind. Even during a brainstorm, it is tough to channel every idea into a clear plan unless you have a house stenographer. That said, it’s important to be as visual as possible throughout the planning process.
Here are a few things I’ve found useful in designing a product from scratch:
- Whiteboarding: sketch out your ideas for everyone to see. List every idea you can think of. Wireframe screens and layouts and garner feedback from your team.
- Mockups: be as detailed as possible when creating a mockup. Photoshop is ideal, but in a pinch, MS Paint will do the job (it’s actually a very underrated tool for creative-type work). When you’re finished, you can add the mocks to your spec to show the developer what you’re thinking.
- Proof of Concept: start creating a few of the screens and show them to your group. Don’t do too much without getting feedback, or you may waste a bunch of time and effort on something that won’t work.
None of these has to be perfect, but rather as close as possible without straining yourself. It’s more about showing your team what you’re thinking so you can reach a consensus and deliver a clear, concise spec to your development team.
It’s a saying I’ve heard for many years now, and while I understand the logic, it recently presented itself to me in a management setting. One of my team members had spoken to me about a test she wanted to do. We had spoken previously about the logistics involved, and how it as a little unclear how we could accomplish it without breaking our application. When she approached me again about the test, I agreed that she should move forward, assuming it would take place in our test environment. It soon became clear that the test was carried out in production, when the boss came to me asking why the site was broken.
It was an easy fix, but came with an unknown amount of irrevocable damage. It is very easy to make assumptions about someone else’s task when you have a thousand tasks of your own going on, but when you’re managing people, this is a mistake. Take the time to check out what they’re doing and you’ll save everyone a lot of grief. You can’t expect what you don’t inspect.