Thanks for visiting! While you´re here feel free to take a look at my blog, view my recent work, or view my portfolio.
Unfortunately, I am not available for freelance work at the moment.
Well, the switch is now complete. I am now running on WordPress. Finally! Google’s “Blogger” really let me down. Not only was it throwing in a bunch of random unneeded code, I couldn’t officially get my site to successfully validate for XHTML. Well, the switch has been made, the code has been validated and I am very happy. There are a couple more things that I will be touching up, such as the comments area, but overall I am very pleased with the outcome. So welcome to my new WordPress driven Blog/Portfolio site.
As a User Experience Developer / Designer you will find throughout your career that every project you work on, whether it’s within a UX team, along side back-end developers, or working directly with a client, at one point or another your sense of what is correct will clash with the idea of what someone else thinks is correct. If you haven’t experienced this yet then you’re either the most agreeable person that has ever lived or tomorrow is your first day on the job.
There will always be someone that either wants to play devils advocate or isn’t too excited about where you decided to put that “drop down” in the HTML form. Throughout my career I’ve had to go into battle countless times and I have witnessed some doozies. At times, in these situations, voices tend to get gradually louder, egos are challenged, people recline back in their chairs, while running their fingers through their hair in frustration, and everyone is fighting over the dry board marker to draw their idea of what is right on the board. You get the idea?
Now, in most companies you have upper management trying to keep the company running like a finely tuned automobile and the sales guys & gals are pitching to the clients and bringing in the cash. Then there is the tech side where IT ensures all computer equipment and the network is running smooth, while the developers are kicking butt on the back-end. However, you, as a User Experience Designer, bear the unique responsibility of being the voice of reason when it comes to building the best solution for any given user problem. From usability, to documentation, to design, to coding, you bear that burden and you love it. It is your job to ensure the user comes first and sometimes you will have to fight tooth and nail against everyone else to ensure that happens.
So what is the key to successfully presenting your case before the court? Well, I’ll tell you: Research & Reason. Research encompasses all forms of usability testing, case studies, and “documented” personal successes and failures. Reason, in this scenario, is the cognitive application of your research to prove or disprove a particular idea.
With one or the other you have a decent chance at proving your idea but with both, failure is rare. So before you go into that boardroom to present your solutions make sure you have done your research and that you have the reasoning to sell the jury. A hunch just won’t do it most times.
Oh, there is one final thought I have to throw in here. After you have pleaded your case, you know what the hardest part of being challenged is? Being open minded enough to accept that you might actually be wrong. There is no “best” way to solve a usability problem, it’s all about finding the “better” way.
If you have a good story on how you’ve won a particular battle, I’d like to hear it. Feel free to post it in the comments.
When beginning any project we start with an idea or ideas. Those ideas, no matter how great or how poor, must be translated into some form of audible, visible, or tangible medium for it to be communicated or received by another individual. The effectiveness by which we convey that idea is of the utmost importance. A poorly communicated idea can result in confusion, misguidance, or frustration, while an effectively communicated idea promotes healthy discussion, a clear view of the objective, and a feeling of mutual understanding.
When it comes to defining a solid user experience our ideas must be conveyed through multiple mediums, such as; verbal presentation, flow charts, documentation, and prototypes; usually in that order. Of all of these formats, especially when dealing with application design, prototyping is the most important. It is the culmination of all audible and written communication up to that point. It is the physical representation of the project or idea and is usually when the fun really begins. No matter how much documentation you have or how many times you have explained it, most people really wont be able to see what is literally in your head until you have developed a prototype.
A good way to explain it, I suppose, would be to compare it to reading a book vs. watching a movie about that book. No matter how well we present, or document, our clients will always have a certain idea in their heads based upon what you have explained to them. Sometimes they are on the same page but most times that is NOT the case. An effective prototype will not only visually convey what’s in your head, it will ensure that everyone is on the same page as you are. At this point stake holders and team members are better equipped to comment and make suggestions without creating confusion and it helps promote those “Ah-Ha” moments.
So, that brings us to HOW we convey this prototype. There are multiple methods of effectively producing a prototype. Some common ways are through rough Photoshop designs, Flash, HTML, or Paper prototyping. These days every second counts, literally. So when creating a prototype, especially in an Agile development environment, we have to get it out fast and we have to be able to make quick changes on the fly. Your prototype should have the ability to be altered and re-arranged on the go within seconds. In all reality I feel that there is a 3 step process when prototyping your idea and it always begins with paper. Yes, paper!
Paper is the perfect medium for prototyping. For several reasons:
- It’s fast.
- It’s easy to alter.
- It doesn’t require a laptop.
- It doesn’t require stakeholders to know Photoshop or HTML to make a note or an edit.
- Adding and removing functionality is just an eraser swipe away.
- Basic frames can be drawn up, photocopied and delivered for reviewing, notation, changes, etc.
Many people have the misconception that rough prototypes should be built with actual functioning components. In some cases this is true, but like I said, when I prototype I use a 3 step process and the first step is always paper. Once I have stakeholder approval for my paper prototypes it moves into the skinning phase. The skinning phase usually involves moving your paper prototype into Photoshop or whichever design program suits you best. This is where you add color to your creation. Make it beautiful, let the creative juices flow… ok, ill stop there… If design isn’t your forte, you can hand your paper prototypes over to the creative team.
Some may be wondering why you wouldn’t just start with Photoshop for your prototyping. The reason is “TIME”. Let’s say that you decide to begin your prototyping in Photoshop. You may be fast but I guarantee you’re faster with a pencil and a ruler. Anyone who has done a prototype design before knows that the end product is almost always much different from the beginning product. Imagine having to dive into Photoshop every time a stakeholder wants a change or you want to represent new functionality. Imagine the frustration of the guy sitting next to you chomping at the bit to show you what he is thinking, but cant jump onto your computer to demonstrate the change. Again, I guarantee that a pencil is faster than a mouse in this case and it can be passed around the table and altered by anyone.
After skinning your prototype and getting approval it’s time to cut and code or to throw it into flash. Flash is nice because it requires you to simply drop your designs into frames and link them together with transparent buttons. Although this may be faster in the short run it may cost you more time in the end. Most of the time Flash prototypes can NOT be handed over to the development team. They want code (unless the project is in flash, of course.) Your best bet is to start cutting and coding. By this point you, your team, and your stakeholders have a very good idea of how your idea works, and looks.
An important question could be asked right about now. What about usability testing? The answer: Usability testing should be happening as early as the paper prototyping phase. There is no reason that you should wait until you have a pretty HTML prototype for people to click through. Get those paper ideas in front of as many eyes as possible. When you move into the skinning phase, get those designs, once again, in front of as many eyes as possible. By the time you get to testing within an interactive HTML environment the feed back will be much more focused on functionality rather than how the site is organized or how the components look, saving you a lot of time and frustration.
So, in conclusion, the next time you have an idea put it to paper first.
