I quickly realized after looking at this amazing collection of gaming consoles that color is needed. Take a look at these images (via Coudal Parnters) and tell me which ones stand out? Which ones seems inviting? Fun? Something that screams for you to touch?
Color is pretty much what is missing today in all electronics. Everyone, including Apple, wants to play it safe with the brushed silver, sleek black or cool white. Grow some and try the rest of the color wheel.
Need to store, sync and share across multiple computers? DropBox is the answer. I’ve been using for about 2+ months now and it’s fantastic. Drop dead simple and fast. It’s also free for the first 2 GBs.
“When is it going to be done?” is a reasonable question and we as software developers should try to come up with the best answer we can based on our experience and analysis. What we should not do, however, is treat our answer as solemn oath.
Unless you are doing the exact same project with the exact same team (highly unlikely), there is no way to precisely estimate when it will be completed. No amount of detailed project planning is going to predict the future.
I know it’s difficult with client work, but I wish more people could share their IA/design work. I really enjoy learning from real -life examples. Here are some samples from Whitney Hess, who designed the Boxee interface.
There is some debate as to whether product requirements and specifications documents are necessary steps in building a software application. But before giving my thoughts on whether they are useful or not, I need to explain how I define requirements versus specifications.
A requirements document is a short description of what the application is supposed to do and who is going to us it. I emphasis short because there are many requirements templates out there that ask writer to fill out all kinds of garbage such as assumptions, dependencies and constraints. I don’t know how anyone could answer these questions because 1) they are either asking you to predict the future or 2) perform some self-administered psychoanalysis.
A specifications document is defining how the application will actually function from a user’s and technical perspective. This is where the details come into play. Screen specifications, site maps and user flows are used to detail each screen’s content and functional components.
So back to original question, are either of these documents necessary? For my the answer is “Yes”, but not because I think anyone is actually going to read them. The main reason I create these documents to fact check my wireframe. For me, the wireframe is the primary deliverable because it something people can actually view and interact. It is the application. However, some things just can’t be fully explained through the wireframe alone. Calculations, rules, flows and other bits of logic that define what the user can see and do should be written down. If not, your going to have a difficult time getting your application coded.
Another benefit is it helps me catch mistakes or omissions within my mock-ups. The act of writing out how a particular screen will work uses a different part of my brain than the visual/design part. It like someone else running quality control on my work.
So is writing a requirements and specifications, mind numbing, tedious work? Definitely! Does it improve quality and save time? Yes, but keep in mind that these documents are not etched in stone, they can be changed, ignored or just plain disregard as soon as the code starts to fly.
Yes, my real name is "Chance Bliss". I am a product manager for a digital marketing agency who geeks out on user interface design, gadgets, playing guitar and video games (a shameful pleasure).
