Respect and consideration

Our role as a designer is to use our creativity for a purpose, to transform experiences into one of function and beauty. We think and strategize about how people use our products and interact with experiences on the web. We make things beautiful and engaging while enabling users to focus on the task at hand. For our designs to function well and serve the needs of a business/person/user, it helps to understand the technology that underlie it.

Understanding the intricacies of the web, how it runs and how things are built allow us to understand what is and isn't possible and how to design the best experience given what we have. Designers and developers collaborate more now than ever before for this reason. We work together so we can rely on each other's expertise to inform our work and to better it.

There's a question as to whether a designer should learn how to code. I think it's not merely a matter of learning to code in order to code our designs but to understand the underlying technology that allows our designs to function. An ideal project may be one that begins from scratch, with a code base that is built based on the initial designs and iterated upon. But for designs that are revisited or complex products that evolve, it's not always possible to rewrite the code base. In product development, you build on the code that's already there and sometimes interactions are not possible without having to dedicate many resources (time, development and money) to overhaul it.

It can be a frustrating situation for both a designer and developer to be in. We want to design a certain experience but the back-end may need to be rewritten to do it and there's not enough time or budget to do it in. A designer who understands the underlying technology can appreciate the complexity that the developers are dealing with. That doesn't mean that the designs are impossible. It simply means that we need to weigh the design and development efforts for the project, consider alternatives, imagine scenarios - in short, have a dialogue and plan.

As a designer with a strong technology and development background, I'm able to have in-depth discussions with my developers on implementation issues. I trust in their expertise but I am able to understand their decisions and question them. I'm also able to question my design decisions and whether it's worth a code overhaul, for example. I can empathize with their experience building a design and ensure that I give them all the assets they need to implement my designs in a way that's easiest for them - that means slicing images and naming them properly, providing font files, labelling my psd files properly, providing ready made css styles, etc. 

This empathy shouldn't be one-sided either. Developers may not need to learn how to design or understand typography or grid systems to the point that designers do, but it's important that they respect the principles of design and rely on designers to make informed decisions that solve the needs of the project. It's extremely easy to pick on a design, but instead of criticizing it, critique it. Take some time to understand the design decisions and how the designer has come to it. Again, have a dialogue. There was considerable time and effort put into our designs and trust me, we've thought of the alternatives and came to our decisions thoughtfully. We're all approaching the same problem and trying to solve it. If there's some really important technical issues that our designs might introduce, then let's hear it out and work through them together. And when it comes to implementing the designs, respect the details - the typography, the spacing, the grid system. Think of them as your curly brackets, your comments, your file structure. We are as particular about them as you are with your code.

At the end of the day, it's about mutual respect and dialogue. I've worked within a team where we have mutual respect for each others craft and can battle it out on design and implementation details. And the result is always a better, more cohesive product.

Everyone on the team should be respectful of each other and their work. Be considerate of each other. That means sales people who understand the advantages and limitations of the product or service that the team builds or provides. That means managers who respects everyone's time and ability and schedules enough time to execute the work to the best of their abilities. It's not always easy especially if money trumps everything else. But the best work environments are the one's that respect the project, the client, the different roles on the team and provide resources for everyone to work to the best of their abilities. There's nothing worse than being disrespected for your time, effort, ability and/or talents.

What is your metric for success?

“How do you want to spend your day?...

What is your metric for success?

Maybe your metric for success is you want to be recognized as good at what you do. You want to be recognized as being competent at what you do. I think that’s a dangerous road to walk down because now your notion of success is completely dependent on strangers and what they feel.​..

How you spend your day every day is your life.”

— Merlin Mann (via Back To Work)

Choice Overload in UX

Reading Time: 2 mins

I came across this TED talk given by Sheena Iyengar in New York on November 2011 about choice overload. It's a short, eloquent talk about the plethora of choice that we are faced with as consumers in this day in age. Grocery aisles are filled with an overwhelming number of choices for any given product based on brand, flavour, packaging, etc. 

Sheena talks about reducing choice overload for your consumers and how that can have positive effects on your business. She revealed several studies which found that reducing the number of choices has increased sales, profit and productivity.

She offered some strategies for business to apply to help make choosing easier for their customers:

1. Cut - less is more
It is easier to make a decision when there are less choices. 

2. Concretize - make it vivid
It is easier to make a choice when you understand the consequences of each choice and they can be felt in a concrete way.

3. Categorize - more categories, fewer choices
We can handle more categories than we can choices. Categories help people identify the differences between their choices.

4. Condition - presenting low to high choices is more engaging than high to low choices
It's better to provide people with increasing number of choices step-by-step than to start with a large number of choices right off the bat. Starting people off with lower choices allows them to prepare for their decisions and keeps them engaged.

As I listened to her talk, I realized that some of the lessons and takeaways she presented also apply to design...

Less is more. Clearing clutter in your interfaces and in your web design helps to clearly communicate your intent and also helps your users to navigate your interfaces and understand the tasks they need to accomplish.

Every action in the UI should be clearly labeled so that the consequences of each interaction is clear. Or else allow users to revert the interaction and return to a previous state. This makes your users feel safe while navigating your UI and allows each action to be clearly identified.

Do not overwhelm the UI. For complex interfaces, it can be better to divide tasks and present them to the user one at a time or step-by-step instead of all at once. Overwhelming your users is the surest way of losing them.

Guide new users through your UI. Help users familiarize themselves with your UI whenever possible, this can be done through a quick tutorial/callout or by using in place help as needed. Make it easy for users to learn your interface.

Seeing (and feeling) is believing

When communicating a proof of concept or a design to potential clients seeing (and feeling) is believing.

Sketching ideas and wireframes is a major part of my design process. Sketching allows me to explore and refine ideas. It helps me to narrow my focus and start to understand the requirements and problems that my design needs to address and solve. It's also a great way to communicate your ideas and collaborate with your team - a picture is worth a thousand words.

After the sketching phase I'll usually take my sketches to Balsamiq so that I can start to create my wireframes digitally and make changes easily. I will share these wireframes with the team and we'll use them to discuss features, workflow, and UI design. This process has worked well when we're developing features to our existing product and discussing the project internally. But when we're creating something new and building a concept from scratch it's been helpful to take our wireframes to working prototypes.

A prototype allows us to test ideas internally and refine our assumptions. Most importantly, it allows us to communicate our ideas to clients and get buy in on the interaction design before development begins. We're able to learn about the technical details of our ideas and how that fits with our current product architecture.

Building a prototype is a lot like designing in the browser. But I'm not interested in the visual design. I'm interested in understanding how the UI behaves, the workflow and how the interactions flow from one part to another. Essentially the user experience. This isn't about aesthetics, this is about getting a feel for your interface.

When I build a prototype, I never start blind. That's what the sketches and wireframes are for. Going directly to code alone distract you from the intent of the thing that you're designing and what the goals are for the interface. So I start with my sketches and wireframes and as I build my prototype I discover things that I haven't considered and parts of my workflow that may have been missing. So I can change my decisions right there and test my designs easily.

HTML and CSS are part of my designers toolset and I recommend designers try to use it in theirs to help clients and your team get a feel for your designs. If you have some JavaScript or jQuery knowledge even better but there's frameworks that can help you with that. If you're not the type of designer to design in the browser, I think you'll still find it useful to take your designs to a working prototype and get a feel for the design decisions you made. You can also get some feedback from your team and test your designs on actual users. The prototype doesn't have to be fancy or pretty, and in fact it shouldn't be. Don't focus on the design details, the color, typography, etc. Just focus on the interactions.

You mentioned frameworks?

That's right, there's help! You don't have to start from scratch. That's what front-end frameworks are for...

In one of my recent projects I discovered HTML Kickstart. It's a very lean HTML framework that allows you to build an interactive web interface really quickly. It took me a couple of hours to create a responsive interface with 6 pages. They also use Font Awesome Icons which adds some great UI elements to communicate your interface to  your users.

Other frameworks...

Twitter Bootstrap - This is a popular one and has a whack load of elements that you can use to build your prototype but bootstrap goes beyond prototyping. You can build a full fledged development project with it. You can definitely do a lot more with Bootstrap but HTML Kickstart was ultra lean and light which is why I opted for it. Update: Bootstrap 3 is now out and a lot of it has changed apparently, I haven't tried this version so read more about the changes here.

Foundation - This one I'm excited about. I haven't fully worked with it (just got it setup and tinkered a bit) because again I wanted something really light and quick to use. Foundation is developed on Sass and can work with Compass, both of which I highly recommend, but that was a lot more more setup than I really needed. As a responsive framework I've heard great things and I definitely plan to use it to start my next web design.

Relationships that feed you

I came across this article on Medium by Shuna Lydon, a pastry chef in Brooklyn. The article is a piece about Gina DePalma, the renowned pastry chef of Mario Batali's Babbo restaurant in NYC, and one of Shuna's first mentors. Gina has worked with Mario Batali for many years at Babbo and before that with Claudia Fleming at the Gramercy Tavern. The article talks about Gina's passion for and adherence to the integrity of Italian cooking throughout her career. I love food and I love anything Italian - the food, the culture, the land, the people (I married an Italian) but this isn't about Italian food or anything related to food really - that will be for another post maybe... In the article Shuna quoted Gina as saying this about working with Batali:

“When you have a strong, creative relationship with someone, you feed off that energy; you can’t wait to share your own ideas and get more from your colleagues... in the beginning years he inspired me with just his energy and excitement about food and ingredients, and our mutual love of Italian cooking.”

— Gina DePalma on working with Mario Batali

It reminded me of the importance of surrounding yourself with people and relationships that inspire you. I've learned through my career, through school, through personal relationships that nothing can replace a great relationship. Whenever I've lost my heart or my motivation I can always relate it back to relationships that drain me of energy. Whether that relationship is with people, with work, with my surroundings, whatever. Finding relationships that are truly great means finding relationships that inspire you, excite you, motivate you, challenge you, and even scare you (in a good way). And if you can find relationships with people that do all that, then that's the best kind.