Just today I read a blog post from my friend Dan Martell called “No Excuses“, he says:
I believe that I own 100% of my outcomes. I either win or I lose because of my actions. Some might blame circumstances but I don’t.
He’s right. I also believe we are in complete control of our reality. Whatever situation you are in, either work or life, you can change it. It’s that simple.
Some things never come easy others are hard to change but they are all within you’re grasp.
Unhappy about your job? Change it.
Living miserably with an unsupportive significant other? Talk, change.
Want to start a company? Do it, now.
Don’t be afraid of outcomes; failures will happen and we will all fail spectacularly at some point, it’s all part of learning.
It’s been a long time since I realized that no one is going to build my dream life or my dream company. It’s all up to me, and I build it, day by day, small or huge decision at a time.
Go ahead, stop complaining and start doing. Go to bed at night thinking about your dreams, you will have a plan by the time you wake up.
I recently removed the file upload field from the ‘Apply for a job’ form on the new soon-to-be-live Ideaware website. It was a quick change, it uncluttered the form. Why did I remove it? Simple, I don’t review resumes anymore. I haven’t done so for a long time.
This lead me to thinking on how Tech companies usually approach the hiring process (from my and other fellow Entrepreneurs experience): take a look at code on Github, designs on their Dribbble profile and review their LinkedIn page. A personal, well-built portfolio website is always a big plus.
Here’s why a resume sucks (and should die):
- Very impersonal – tells you very little about the person
- You can blatantly lie in your resume, since it is very hard to verify
- Dates, numbers and GPA’s are worth nothing
- You can’t see & evaluate a portfolio on a piece of paper
Here’s why having a good online presence wins:
- You get a better grasp of someone, not numbers and words
- You learn A LOT from reviewing code
- You learn A LOT from a good design portfolio
- Easy to see if they’re a good fit for your company
- Hard to lie on Linkedin, your network tells a lot about you
You can’t see all of this in a resume, period. When a resume does reach my hands my first task is to find an email in there, send the person an email asking for links to their work & code. That’s two steps we can totally avoid. Oh, you don’t have anything online? Sorry the chances of me hiring you dropped almost to zero.
The conclusion is simple: Resumes/CV’s & cover letters are worthless in our industry. There is so much more to a person and their skills than just facts and numbers on a well-indented PDF (or printout).
The internet tells you so much about a person these days.
I love making wireframes, they make my job a whole lot easier, definitely one of the most important elements in my ux toolbox.
What is a wireframe?
On simple terms, a wireframe takes a webpage layout back to the basics, it’s a simple rendering of where the elements and text are placed on a page. By creating a wireframe you make sure you get colors and visuals out of the way and you focus on what really matters: content and user experience.
I won’t get into too much detail on how to make wireframes, you can find lots and lots of information on the matter by just googling around. I highly recommend Fuzzymath’s recent series of posts on the matter, very informative.
What are they good for?
Thinking about elements and layout first is very important, wireframes help you do exactly that. There is no right or wrong way to do a wireframe, just get a piece of paper or fire up your favorite design app and start sketching away. Once you see elements and content on a piece of paper or on your monitor you will start realizing what works and doesn’t and start moving elements around, adding in more, or completely eliminating useless parts. This is the beauty of a wireframe.
Beside from helping you out in your design process, wireframes will also help you to:
- Create a useable layout
- Work as a team to iterate on creating the right interface
- Convey your thoughts, ideas and proposals to your clients
- Focus on information hierarchy
- Get early feedback on your layout or user experience
Wireframes and user interaction
This is where I find wireframes to come most handy, when defining the user interaction of an app. There are certainly a few of cases I can think of where you could simply skip making a wireframe, normally when the layout is very simple or the requirements are very well documented.
On my previous post about UX design, I discussed a few ideas around creating the right UX for your users. Wireframes are a handy tool for that, they allow you to lay out the user interaction, specify user flows and in general see how a user will move around your app or website.
The great thing about this is that you, your team and stakeholders get to see and experience how everything will work – and change it as necessary at a very early stage.
Stuff to keep in mind
When creating a wireframe always consider:
- Only elements and content that are necessary on this page
- What content deserves the most amount of real estate on the page
- The hierarchy of the information (what is more important than what)
- Who will be using this page
- Where will the user go from here
- Make call to actions very clear
Wireframes get you…
- Early feedback from team, stakeholders and users
- A chance to embrace change quickly at an early stage
- A birds eye view of the project
- Piece of mind
- A very solid starting point to create the visual style
Well that’s it, hope you enjoyed reading a bit about wireframes and why I love them so much. I hope this inspires you to sketch and wireframe before you start out your next design. Trust me, wireframing only makes the process way easier.
There’s always an easy way to do things and the complicated way. The iPod is as successful as it is because it doesn’t make you think, just think about it, when was the last time you saw an iPod or iPhone come with an instruction manual? Yup, thought so. Those things do what you expect them to do, in other words they are intuitive. These type of interfaces make for a transparent UI. It may be beautiful, but the user will move along with little or no effort. This is what a transparent UI is all about.
Sweet lord, is that some transparent user interface?
Go for the obvious
You don’t have to reinvent the wheel every time you jump into a new design, wireframe or whatever it is you are building. Keep something in mind: your users are used to finding things and doing things a certain way. This means, for example, they will try to look for a way to sign in / sign out of your app in the top right corner of the site, so by all means put it there and not somewhere in the sidebar. It sounds pretty obvious reading it, but trust me, I’ve seen my fair share of this, even client requests that will just receive a big no from my side. In other words: don’t reinvent the wheel.
There is a lot of space to design cool stuff and be innovative, but every single UI you build does not have to be something out of minority report. Trust me, a few years ago I made this mistake, very confusing user interfaces is what you end up with.
It’s all about your content
It doesn’t really matter if you are building a website for a local restaurant or a product for a new startup, the UI should not be in the way: it’s all about the content. The less you make your user’s think on how to find/do something the more they will focus on what they are really there for. Outside of the design world, most users won’t care if you have awesome buttons an trendy textures in your site, if at the end they can’t do what they got there to do. Once again, get the interface out of the way and focus on what’s important.
You can always make a website css-gallery worth, but at what cost?
No need to explain
A few years ago I was designing for a startup and found myself putting in infoboxes everywhere trying to explain how everything worked. I did so, once the site launched the main concern was that it was hard to use. So from then on that became a red light for me: if you really need to explain the user how to do something, then revisit your design. As Steve Krug wrote in Don’t Make Me Think:
…if Web pages are going to be effective, they have to work most of their magic at a glance. And the best way to do this is to create pages that are self-evident, or at least self-explanatory.
A quick checklist
Here’s a small list of the top of my head to keep in mind, feel free to chip in and I will keep adding stuff here.
- Links should be obvious: Make them another color, underline them or even bold. It should be really obvious to me that that is something I can click on. (Standard preference is another color + bold or underline).
- Session info: I bring it up once again, but users always look for a way to sign in/ sign out/go to their profile on the top right corner of the site. I suggest keeping it there.
- Content is king: I’m there for the content, so is the user. Don’t take focus away from what’s important. UI is the means not the end. Unless I’m a designer looking for inspiration, I’m probably not there to see how pretty your site is.
- Navigation: Make it simple, if you have multiple layers of pages, make sure that hierarchy shows in the nav.
- Start with wireframes: You will focus more on content and how to lay out the content instead of focusing on color schemes and pretty textures.
- Guide the eye: Most of the time, users will scan or skim your website at first by going from left to right and top to bottom in kind of a zig-zag fashion. Take advantage of that.
- People = Users: I know I’ve been using the term users here and in every other of my posts, but remember the term “users” is not an abstract being, you indeed are designing for people.
I know there is a ton of more stuff, anything else you’d like to see here? Drop me a note at email@example.com or via twitter @andresmax.
This is a question I get asked quite a lot recently, and in no way it is easy to reply to, UX design covers quite a lot of ground when building a website or app. I’ll do my best to define my understanding of UX design through experience.
Blast from the past
UX design is not a new science, dating back to the 1940’s when we started building new machines and systems that required a lot of user interaction and since the goal of some of these machines was to make them mainstream, there was a lot of thought given to ergonomics and human-psychological aspects of these machines.
The ENIAC, simple as pie.
Back then as now, it turned into a multi-disciplinary field involving most of the stuff that makes us human, just to try and understand how we interact with stuff and what was the easiest way to do so. I can start to talk about psychology, social interaction, cognitive stuff, but I wont bore you with that stuff.
What it is (and what it’s not)
UX design is not about how things look (a website, a button, a header, you get it…) its about the user, and providing them with the experience you intend to. Experience you say? Yes, experience. It’s all about defining what your goal is, it doesn’t really matter if you are designing a website for a hotel, or the latest and awesomest web service, in the end its making it easy for the user get to your goal.
Whitney Hess wrote a very nice article last year on Mashable about the 10 Most Common Misconceptions About User Experience Design.
On a dark desert highway
Let me exemplify a bit. Suppose you (or your company) gets hired by Hotel California to design and build a nice website for them.
You can never leave.
Where do you start? Well as a UX designer you should start listening. What is the client trying to achieve? How does he/she intend to use the website to achieve that goal? Every website/web service has a goal.
Continuing with my example, Hotel California would like to let their guests check out any time they like get more people to book and stay at their hotel. That is their goal. Listen, think, listen again and think some more. Sure, pretty pictures and a booking form will get the job done, but don’t just throw it in there somewhere or even worse (and I really saw this recently) hide your booking form in a third – level page. Big no no -unless your goal is to lower Hotel California’s bookings because your family owns the competition and you don’t want people booking rooms at Hotel California- then good job, you are a skillful UX designer (see how your end the goal changes everything?).
Now, UX designers don’t just jump to design and code, we have a set of tools in our toolbox we use and we’re all comfortable with our own design process.
Mix and match your tools
We all have or way of doing things, whether its because we’re comfortable with it or just because it plain works for you. UX is no exception, even though there are a set of tools to use, I’m a huge advocate of taking and using what works for you, we all do things differently. Here’s what works for me:
- Gather requirements (previous website, client chats, spec sheets, etc)
- Build Flows and Sitemaps
- Make up personas to have a clearer idea of who will be interacting with your site
- Sketch up some wireframes (test and iterate these)
- Build prototypes and do some user testing, you get invaluable feedback this way
- Graphic comps (or visual design, whatever floats your boat)
This is my UX process, I find it effective and I’m comfortable with it. Your set of tools may be different but in the end keep in mind it’s all about the user getting to the goal you set.
Its not just one step
Keep in mind UX design is not a step in the process, it is the process. From discovery to building sketches, testing, iterating and coding the actual interface, UX design is building for the user and building for your end goal. The user must feel comfortable, must find an easy way to do what they’re set out to do, what the end goal of your website is set out to do.
My golden rule: keep it simple
Engineers and hardcore users will generally have no trouble finding or performing an action on your site. But this is not usually the case for most of your users (unless you’re building something for a very specific niche). So one of my own first rules of UX is this: keep it simple. Keep the interface uncluttered, most important actions easy to reach and visible and try to avoid cluttering the interface with stuff the user will most probably never use.
What is your goal? Keep it in mind, keep it very visible, and keep it within reach.
If you’ve worked with startups before like me, whether on a startup itself or consulting for new startups this situation will sound familiar to you: Customer (Fred Flintstone) comes up to you with an idea for the next big thing. Sweet! Let’s get things going, get some engineers in the house and start hacking away with a two sheet word document and a few doodles as a spec sheet. Sounds familiar eh? Well, you’re doing it wrong.
You see, Mr. Flintstone is more of a marketing guy, he’s built businesses before or he has the means to get some seed funding to get his product started, exciting times! What Mr. Flintstone doesn’t know is that the engineers he hired will spend lots and lots of time working on a product that has not been designed, tested and with no user experience. How can this be? Well this is where you as a Product Manager or User Experience Designer come in. It is your job to take Mr. Flintstone’s idea and turn it into a winning product even before the first line of actual code is laid down.
Marty Cagan states in his book ‘Inspired: How To Create Products Customers Love’:
“A good product requires a good user experience. And a good user experience requires the close collaboration of product management and user design”
Couldn’t agree more. He also says:
“It doesn’t matter how great your engineering organization is if the product manager doesn’t give the engineers something valuable, usable and feasible to build.”
Yup, this is what I’m talking about here, discover your product, build a user experience and equally important test your product early, don’t wait for a beta product to ask if the product is usable or valuable.
So how does this product discovery thing work? I’ll just make a list, everyone loves lists:
- Talk to Mr. Flintstone, a lot. He has the idea, you need to help him discover what the valuable product will be, remember: an idea is not a product.
- Wireframe or prototype it. Whatever floats your boat, don’t jump to design, don’t code it. Build the user experience, it will be invaluable for Mr. Flintstone, you and your possible users to see what the experience is going to be like. You and Mr. Flintstone will be surprised that at what you find out. I like high fidelity prototypes, I’ll write more about them in another post.
- Test, fix and repeat. Get some people outside your mom/dad/girlfriend/wife usability test group and see how the use the thing. Ask questions, get answers, fix what you know is wrong, in short: make it not only easy to use but valuable.
Once you’ve done this, you’re in pretty good shape. Mr. Flintstone will very happy and confident on the product he will be building and will not attempt a suicide approach at changing product specs daily.
Engineering will love you and will want to have your little babies for giving them such a great set of wireframes or prototypes for them to work with.
In summary, you’re the pro. Help Mr. Flinststone out with his product, find what problem he’s trying to resolve, build a prototype, test and iterate, winning products will come your way (and Mr. Flintstone might invite you to a beer or two).