While researching user experience design techniques, I stumbled upon some nifty whiteboard magnets for prototyping called GuiMags as well as a complementing book called The Unplugged.
GuiMags look like the nicest way to prototype something before going to HTML and CSS. Labor intensive forms of prototyping don’t seem to add much value, and paper and traditional whiteboard prototyping only works until you’ve changed your mind about something and have to throw your work in the trash or erase half the board.
Although I decided to postpone a magnet purchase until I am doing design again, I was able to get my hands on the book. Its premise: we limit ourselves by the technologies we use. Instead of thinking outside the box, we’re often thinking and functioning in it. A large part of this thinking inside the box is how we develop software.
Although, everyone interested in the topic should pick up the book, here are a few of my takeaways:
- Every major form of art that involves technology (music, film, video games, graphic design) starts outside technology. Artists do not limit themselves by their technology but by the limits of their own minds. As a software engineer, you often limit yourself by the technology you use day-to-day.
- Spend as much time as you can iterating on concept and design before going to implementation.
- Design the software front-end not the back-end first.
- Just like there are code freezes, freeze the product when it has passed the design phase.
- It is often wise to outsource the implementation.
- This serves as a peer review of the design before it goes to implementation. Software developers traditionally think about the back-end first.
- Different cultures have different strengths: “England and Western Europe are great at design, Ukraine and Macedonia have amazing and prompt developers who can think for themselves, the Netherlands always emails back the same day, India is extremely polite, etc.”
- Work can be done while you are sleeping. “This can cut the development time in half.”
- Because you already know what you want and won’t be constantly changing the design, contractors will want to work with you even if you pay less.
- Only be satisfied with five-star developers.
- Pay more than you agree to pay.
- Do one-week sprints. Longer sprints end up getting delayed, with excuses.
With the last (sub)point in mind, I think this methodology is well-suited for an agile development process.
There is a lot to gain from reading the book, so make sure to grab a copy for yourself.
I recently heard David Allen’s commentary on Twitter. He’s an experimental user and has some good thoughts on its utility. One thing he said particularly stood out to me as a nice heuristic when determining the bounds of my commitments to others and myself:
Am I going to too many cocktail parties this week? Or should I be going to more cocktail parties this week given what I’m doing?
The answer to those two questions, especially the second one, helps one discern whether or not to even go to cocktail parties…period. If you can’t answer “yes, I should be going to more cocktail parties…but for reasons X and Y, I can’t,” it’s time to reevaluate why you’re even going.
Each time a potential commitment arises, ask “what am I doing in life right now?” If it has changed since the last time you took on such a commitment, reconsider whether or not you should take it on again. If you shouldn’t, don’t.
The wonderful documentary The Truth According to Wikipedia explains the problem behind useless information overload.
Facebook is great, but getting a gazillion Facebook email notifications can be annoying. It should have the option of a daily summary email that consists of all notifications for the day. The user interface would be the same but would also have a little daily summary checkbox option on the notifications settings page for those who want only one Facebook email per day.
I’m blocking Facebook notifications until it’s implemented.
You can join the cause by joining my “Facebook Needs a Daily Summary Email Notification Option” Facebook group.
Update: Today I got my weekly LinkedIn Network Updates email. Somebody’s doing it right.
A few years ago my dad, Bo Lotinsky, got me hooked on David Allen’s Getting Things Done. I’ve enjoyed a lot of conversations over the years with him about implementing GTD and even got to go with him to one of David’s seminars in Washington, DC. It was one of those memorable father-son bonding times.
I’ve been following Mark Hurst’s blog for awhile now and bought my dad his popular book Bit Literacy. (People send my dad way too many emails.) After weeks of listening to my dad rave about it, I finally got a chance to scan and read it myself. Everyone must read this book. Although a lot of the ideas and techniques can be picked up elsewhere, there are a few that will have a huge impact on how I handle the bits in my life:
Chapter 4: Managing Incoming E-mail and Chapter 5: Managing Todos
- We have a natural inclination to spend time managing todos rather than actually accomplishing them.
- Get your inbox count to 0 (yes, zero) email messages per day. (Also known as Inbox Zero.)
- Todos must be tracked in an external program or service. (I personally like Backpack.)
- Track follow-ups to emails sent to others externally. (This is why Mark built Gootodo.)
Chapter 6: The Media Diet
- Regularly prune RSS feeds.
- If it’s not helpful for what you do in life or provide a high level of satisfaction or enjoyment, don’t read, subscribe, or pay attention to it. Distance yourself from it.
Chapter 12: Other Essentials
- Learn to use the Dvorak keyboard layout instead of QWERTY. You don’t need new hardwar–all major OSes supposedly have it baked-in.
- Utilize a bit lever to save time typing common phrases and sentences. Bit levers are much like Microsoft Word’s AutoComplete, but work anywhere you can enter text.
The book is filled with lots of bit management goodness, so check it out.
A couple weeks ago, Patrick and I got ourselves into a mental rut. For a few days, Patrick was slaving away on server configurations. I was trying to figure out how we were going to charge credit cards on a monthly basis without storing customers’ credit card information. I started to get in trouble when attempting to merge two unaccepted patches for the Active Merchant Ruby library into something workable. Patrick and I like just about nothing worse than configuring servers and trying to fix unacceptable code. It was eating away at our morale; we could feel it; and it was slowing us down.
One night I wrote an email to Patrick explaining my despair and suggested we work together for a few days. Within minutes Patrick replied admitting that he was just about to write the exact same email.
The following day we pair-programmed our way through the Authorize.Net Automated Recurring Billing patch for Active Merchant. Not only did we see a task drop off our to-do list, we got the morale boost we needed to go back to individual work.
Although I largely agree with developer isolation as described by Fog Creek Software and 37signals, you just need to work together sometimes.
Our first two customers are South Street Steaks and Aqui Brazilian Coffee respectively. As you can see, the sites will eventually need new designs; however, both establishments helped us develop a solid system, have been great beta-testers, and most importantly, they love SandwichBoard.
Today I walked Carminha Simmons of Aqui through SandwichBoard. She added a news article, event, and web page herself during the training. While she used the system, I took notes on anything she didn’t understand, things she got stuck on, and features that broke. When I got back to my home office in the afternoon, I went through my list and fixed the majority of the issues or UI flaws I saw before dinner.
I had direct contact with the customer and saw her every mouse click and facial expression. I was able to discuss with her how to fix things she didn’t understand. I didn’t have to go through a committee or get permission to fix what we thought was broken. All we have to do now is run a command to update our system live in a matter of minutes. Try doing that when working in an organization divided into job functions and heavy processes.