In Part 1, I argued that the need for a designer to know how to code what they create is based on the designer’s chosen professional path and the overall size of the project they are working on. This has resulted in a variety of great comments, both here on the blog and on the twitterverse. If you haven’t had a chance to read it, please check it out.

Having dealt with that side of the argument, I want to provide some thoughts on why it’s important for designers to know about code, understand what a development lifecycle looks like, and why knowing these two aspects of digital creation is vital to being a well rounded designer. As I mentioned in the previous post, my educational background is in Computer Science. There are very few aspects of the coursework that I use in my everyday work, but what I do use is the concepts and domain knowledge that came along with it. Because of the curriculum I have a fundamental understanding of Object Oriented Programming, System Architecture, and the theory behind programming languages and their structure.

How does that help me as a designer?

Having this knowledge allows me to understand the medium I work in, at its most fundamental levels. At a high level, I understand what the technical constraints are on a variety of technical platforms. This understanding ensures the final design isn’t super difficult or complex to develop.  Later on in the overall process, when a developer challenges a design decision or offers up a suggestion, we can speak using the same language. We are able to collaborate more effectively on a problem because we have a shared understanding of the technical concepts that are required to make up a design.

How could this knowledge help you as a designer?

Effective collaboration

Being to speak the same language between you and another party is the first step to effective collaboration. This is something we do when working with users and business folks right? Why would it be any different when we are working with our technical peers? The good news is the craft of interactive prototyping is a great tool to use to facilitate a technical conversation. If you understand, at a fundamental level, how a particular interaction would need to be implemented, you are poised to better communicate that requirement to a technical team. Doing this with an interactive prototype isn’t the only option. As part of the interaction design spec, you could write out the interaction as pseudo-code. But, for the pseudo-code to be meaningful, it needs to be based on an understanding of the technical platform you are designing for.

More Marketable

It common to find that many User Experience Designers comes from either a psychology or traditional graphic design background. This background is necessary to effectively research user needs and behaviors, and to create a solution that meets those needs and supports those behaviors. However, if you obtain a working knowledge of the development side of things it allows you to contribute to areas of the design process that may not directly relate to user experience design. Also, your opinion on non-user experience design aspects of the system carries more weight. Other members of your team will put more trust in your designs and you, as they understand you’re not going to design something crazy and unmanageable.

Encourages Innovative Work

With solid foundation of what’s been done in the past and is currently being done within a particular technical platform, you are best prepared to design something new and innovative. Granted this depends on the project your working on, but innovation is possible on either the micro or the macro level. You will be better prepared to know when it’s time to break the rules and do something that’s disruptive or unfamiliar to either your organization or your audience. We already know this rule works out based on all the work that’s been done with design patterns. The best way to know when NOT to use a design pattern is to have an intimate knowledge of that pattern.

No Excuses For Not Learning

Knowing how to code what you design isn’t required to be a good, if not great, designer. But it doesn’t hurt. At the very least, a designer should have an understanding of the working fundamentals of the technical aspects of the medium in which he or she works. With the amount of information that is available online, in books, or even at local community colleges, the barrier to learn is very low. My recommendation to anyone that wants to beef up their skill set, or at least domain knowledge, on the technical aspects of the web is to pick up a book and build a “Hello World” application or webpage. Even doing something as simple as this will give you insight into what it takes to bring your designs to life and allow you to empathize with your technical peers.

If you are a designer who always goes to design conferences, break out of your comfort zone and attend a technical conference. Better yet, speak at one. It’s been my experience that technical conferences are very open to speakers from the design world. If attending, or speaking at conferences, isn’t your thing, go to local tech meet ups in your area. Not only is this a great networking opportunity for you but it’s a great place to find a mentor. It’s been said that to become a better design just design something. I’d refine this to say, “To become a better designer, design and build something…anything!”

My 20 month year old son Tristan made a visit to my office last week. As we were leaving, he fell victim to my office’s front door. For years I have despised this door, as no matter how many times I walk through it, I always fall for it’s crappy affordances.

This is a door that opens outward as you walk through it from inside my office, so to open it you must PUSH. Myself, and many of my co-workers, continue to PULL on the handles to these doors as we are leaving the office. In many cases, it’s because we allow instinct to take over and guide our movement rather than step in and control our behavior directly. This is due to the fact that we are normally on the phone as we are leaving, calling clients one last time, or checking in with home for any last minute errands before heading home. Seriously, after over 4 years this is a door that plagues me and many others!

The lesson my son taught me, was that we humans have a naturally ability to compute and react to perceived affordances. (Something I already knew being a UXer, but he nailed it home) It wasn’t until this little human, who is still trying to figure out the world around him, attempted to PULL on the door rather than PUSH on it that it dawned on me that our reactions to affordances is almost instinctual. In a world where we are constantly exposed to more and more stimuli, I believe we are becoming more reliant on our ability to instinctively react to perceived affordances more than ever.

So why does this matter? It matters because as designers tackle problems that impact our everyday lives, it’s imperative that our instinctual reactions to affordances are taken into account. If you save me the five seconds it takes for me to figure out WHY the door isn’t opening when I PULL on it, then you are making my life a bit more stress free and easier to navigate. And if I ever meet you face to face, I’ll probably give you a hug.

So if you are someone that is trying to solve the everyday problems of people, consider how a toddler might behave when presented with a particular affordance. Because chances are, a busy adult with umpteen-million things going through their brain will react the same exact way.

This question gets asked in a variety of online forums and Q&A communities all the time. We also hear it offline coming from stakeholders and clients when projects are getting kicked off, or when designs are being reviewed. Fortunately, this question has a simple answer – YES! Now, the rationale behind the answer is where it gets tricky, and for all you out there that are a fans of User Research it’s where the fun happens. 

There is always someone, or a group of someones, that will use a particular feature or function. It could be personal preference, or some person out there has determined that using said feature is more efficient/productive than the standard method. The sad truth though is just because people use something as it appears on other sites and products, doesn’t mean it’s the right thing to do for your design/product. To make a truly informed design decision, it’s best you put yourself out into the world and do some good ole research.

Go find a group of people that represent your users and see if they are even aware of the feature you’re thinking of using. This can easily be done with a 15 minute conversation over coffee, or over the phone. If face to face interaction isn’t feasible, crank out a short, and I mean short!, online survey. You should pay close attention to WHEN people use the feature, and most importantly WHY. Other areas of interest should be when people DON’T use the feature, especially if you happen to run across someone who purposely AVOIDS the feature. All of these little data points are great starting points to have a meaningful and inspiring conversation with people who you will be designing for. The results of the conversation will allow you to answer “Do people use <Insert Feature/Function>?” with an informed response and help convince others how time and money should be invested during later stages of design and even development.

Disclaimer: This is NOT meant to be a statement of general definition. I wrote this article to myself, in an act of self reflection. Since I’m an open person, I felt it was necessary to put this out there for the world to see and comment on.

Do you consider an architect a designer? Is the work of an industrial designer design? If you answer yes to either of these questions, than why is it that some people define the act of design for the digital world to only belonging to the visual side of things? I’ve recently been criticized for calling myself a designer, a user experience designer to be exact. One of my favorite quotes regarding the ambiguous definition of design is “Design’s fundamental role is problem solver”. While this is a great definition of design, it doesn’t really help to justify calling myself a designer, even though my primary role is to solve problems. (Note: The actual title that is prescribed to me is meaningless. What matters to me is the fact that I am recognized as designer, and that the work that I do is design.)

In the work that I do everyday, I try to solve problems for clients, their customers or users, and the problems that plague my own life. What is it about my work that makes me a designer? The key is in the steps taken to create a solution, and more importantly the intent behind that solution. Before a final solution is every discovered, many iterations are explored through sketching and modeling. This ensures that all possible angles are covered, and the problem space is throughly explored to get past the obvious answers and get to the truly extraordinary. Why do these activities make me a designer? Because it’s the same general process, and a proven process, that other ‘designers’ take to creating creative solutions. This process isn’t new, in fact I’d wage it’s been around for centuries thought I don’t know of any source to back up this claim. The fact that some will dismiss this activity as not design simply because it doesn’t result in a rich visual simply doesn’t add up. Not saying that visual design, or emotional design as I like to think of it, isn’t design. As it’s just another slice of the design pie, and all I’m asking is to be included in the pie.

While the process that I follow is important, it pales in comparision to the intent that goes into the solutions I create. Intent is what separates design from art. Artists create as a means of self expression, where designers create based on the expression of others. One argument that I’ve been given as to why I’m not a designer is the fact that I perform research before every thinking about a possible solution. My response to this is that for something to be considered designed, it must have research (‘research’ includes both design and user research) to both inform and validate the decisions that went into the creation process. Without research, your acting more like an artist than a designer. The research is what guarantees that the end result is an expression of the people that will be consuming the solution, and not solely that of the creator.

So why am I a designer? It’s because I throughly explore the problem space of an issue through research, modeling, sketching, designing, and validation using time tested methods that have lead to innovative discoveries, products, and solutions time and time again. It’s because I’m not the audience for the objects I create, rather it’s those that will ultimately be interacting with the solution that is the true audience. It’s because I want to make the world better, and what would make it better for myself may not make it better for you.

Ohh, did you answer ‘No’ to the first two questions? Then there is no hope for you.

I recently had the pleasure of being a guest on Jeff Parks i.a. podcast. This was my first time being both interviewed and recorded, and kudos to Jeff for making it an awesome experience! The conversation we had revolved around failure and why it’s so important for designers. The topics include concepts I brought up in my three part posting on the importance of failure, and feedback we received on the wiki he set up. Thank you to Christian Crumlish, Daniel Szuc, Jan Jursa, Valeska O’Leary, and Eric Reiss for that feedback btw! You can listen to the podcast either here or via iTunes. Hope you enjoy!

In the final part of this series on the importance of failure, I’ll be getting a little philosophical on the subject. Part 1 and Part 2 covered some practical means to take advantage of failure. The final two methods are meant more to change the mindsets of both individuals and organizational leadership to encourage an environment that takes full advantage of failure. Failure always has a negative connotation to it, and these final two approaches are perfect for finally putting a positive spin on the subject.

Embrace Failure

It’s a natural human response to put up our defenses once something goes wrong and we are deemed at fault. This response normally comes out as a series of excuses, attempting to divert the blame to others, or just hanging our head low while the situation steamrolls everyone over. A better response would be taking control, and asking questions like ‘What could I have done differently?’ or ‘What did I miss that lead to this?’ Not only is this the more professional, but it can jump start the conversation towards finding possible solutions.

Conversation Points:

• What kind of policies should be in place to encourage failure?
• How serious does a failure need to be before serious action needs to be taken?
• How does traditional damage control fail to inform project teams and designers on how to avoid the same mistakes again?

Open Minds and Open Ears and Open Hearts

Negatively responding to someone who has made a mistake does nothing to resolve the overall issue. In fact, it makes the whole situation that much worse. Keeping an open mind that everyone screws up every now and then, listening to what lead to the failure, and supporting someone in picking up the pieces greatly is whats need to  improve the situation. This is the keystone to turning everyday design failures into a positive aspect of designing.

Conversation Points:

• What was the worse project/design review you’ve had that did nothing but point out all the flaws and didn’t offer any tips for improvement?
• How do you empathize with a peer on their failure, but still maintain a sense of authority?
• Obviously, there is such thing as failing too much and too often. Where should this line be drawn?

This closes the proposed framework on how to deal with failure as a designer and use our failures to ensure the work we do tomorrow is a vast improvement to the current ‘disaster’ that is causing so much heartache today.

In Part 1, I showcased the first two methods for dealing with failure and learning from it. Part 2 will focus on activities that can be during a retrospective, or stand alone. These next two methods have a certain risk associated with them due to the emotions that can arise during the resulting conversations. If done successfully however, the passion these emotions invoke can help solidify the lessons that are available to be learned.

Assign Blame

There are some that believe that a single person can shoulder the responsibility of an entire project. The truth is though, whether a project is large or small this is impossible. The responsibility of a project is a partnership of the team, even if it’s a team of one, and the sponsoring client. The advantage of this shared sense of responsibility is that when something goes wrong it’s possible to pin point who was the cause. There are many dangers associated with calling someone out, but if done in a respectful and constructive manner it can be a great motivator.

Conversation Points:

• How have you dealt with being call out when you were responsible for a project failing, or an aspect of the project going a-rye?
• Have you ever had to assign the blame to a project member? How did you approach them?
• What are some safe ways for assigning the blame to someone?
• Does the emotional risk outweigh the possible benefits of pin pointing the person responsible for a mistake?

Highlight the Success

All this talk about failing and finding faults in people can eventually become too negative. No project is a complete and utter failure. Shedding light on the successes helps give the team, and the client, a positive view on the overall value of a project. It helps bring the team back together, and if the client is involved it makes them feel better about investing in the project. Talking about all the stuff that was a success helps to mitigate the negative emotions that may have popped up over the course of the conversation as well. Yes, Bob might have delayed the project a week due to a database issue, but he really hit a home run optimizing the database making the app super quick. In the end, a nice pat of the back goes a long way.

Conversation Points:

• What is more difficult, highlighting failures or successes?
• What is the proper ‘reward’ for someone being responsible for a big success?
• Should highlighting a person’s success be public or private?

Related Posts:

Part 1 of The Importance of Failure for Designers

Part 3 of The Importance of Failure for Designers

The key to any advanced prototypes using Blend 3 w/ Skecthflow is using the SketchFlow Animation Panel, the more advanced States panel, or by adding common interactive behavior to controls. Now, if you happen to have any Flash background, setting up animations will feel very comfortable for you. Below are my thoughts on how to set up some of the behavior that is exhibited by another Silverlight Prototype I put together. (Please explore the prototype to see how feedback and annotations work.)

Creating an Accordion Navigation

The image shown above was the base state of the accordion navigation I built. All of the screen elements presented are drawn rectangles rather than any control that comes along with inherited behavior. The base state is the foundation for any animation a designer wishes to built to mimic interactive behavior. From this starting state, a designer can create iterations of the screen and tie the various states together. What happens when switching between the various states is completely taken care of by Blend, very much like the tween functionality in Flash. Below are screen shots of the two other states I created, and the States panel. Notice one of the defined states returns the accordion to the base state, I am unsure if this is necessary but it worked for me.

The SketchFlow Animation Panel works exactly that same way as states, but only allows for a single animation flow. If it’s desired that the interactive aspects of the prototype be conditional, it’s required to use the States aspect of Blend.

Rollover Effects

Providing a rollover effect is a common need for prototypes. The SketchFlow Animation Panel is perfect for exhibiting this type of behavior. On the ‘Countries’ page, the sketched picture circles can be navigated by rolling over the right arrow. Here is a look at the SketchFlow Animation Panel that allows for this type of behavior.

Drag and Drop

Adding the Drag and Drop behavior is as simple as adding a property to a control. With this property added, it’s possible to place the control anywhere on the screen. Blend adds the proper code necessary, behind the scenes, so a designer can concern themselves with exploring the behavior rather than programming it. As you can see from the screenshot, there are many behaviors available that can be added to any control.

Blend is a powerful prototyping tool given that you find yourself in a WPF/Silverlight development environment. It provides the same benefits that many other prototyping tools have for other development environments. So which tool should a designer use? It depends. It all depends on the type of environment you find yourself in and personal preference. Hope you have enjoyed my exploration of Blend and if you find yourself using it one day please share your experiences.

My first introduction to Blend wasn’t a pleasant one, so bad that when Blend2 came out I promptly ignored it. However, while attending the Day of .Net Conference I sat in on a demo of Blend 3 with Sketchflow. It was impressive to see the improvement that has been made in the Blend, and with the addition of Sketchflow.  To dive deep into the capabilities of Blend, I downloaded the trial version and set out to create a prototype for a future design of this blog (and do some R&D for how to use this on my project team). Below are some thoughts I had while cranking out this concept.

Pros:

Powerful Mapping Module - Flow maps and site maps are key to any design process. Using the SketchFlow Map module, a designer can make either of these very quickly. Blend 3 takes these models a step further by breaking them up into two types. A Screen represents a unique page in the design, allowing for a detailed set up of the overall structure of the site or application. Components are aspects of a page that can be used on many screens throughout the design. The SketchFlow Map module allows for connections to be made between the various screens and components in order to properly showcase the relationships that are involved. The various Screen and Components nodes can be customized via coloring coding in order to convey some deep meaning. In my example, blue nodes are main pages, green nodes sub-pages, red nodes navigation components, yellow nodes UI components, and orange nodes form components.

Components - Creating components that represent shared aspects of the overall user interface is a huge boon. Only having to create a form that is used on half a dozen pages only once not only saves design time, but also removes a lot of repetition in our work. Other applications have a similar concept by the use of master pages, or template, but the downside of these overall frameworks is when only certain aspects of the framework need to be used.

Low-Fi Look and Feel - The name SketchFlow really holds true with the overall style that is applied to produced prototypes. Though it is obvious that they were created with the aid of some program, the prototypes look down and dirty enough to really get the message across that this is just a concept. Though I haven’t tried it yet, during the demo of Blend3 it was stated that user defined controls can be created and the sketch style applied to them in order to maintain the low-fi look.

Behavior Set Up - A prototype isn’t really a prototype unless it has some level of interactivity. Setting up a simple click thru is as simple as can be. Through the use of the animation module, some pretty slick behavior is possible to set up without needing to get into the code. But, if you happen to have some basic skills in C# or VB.net, it’s possible to add some pretty complex behavior as well.

UI Control Library - The library of controls that comes included in the SketchFlow style covers just about any standard control you can think of. Included with all the standard controls are simple shapes that may need to be used for a variety of reasons. When prototyping is complete, and approved, a developer can simply remove the Sketch styling and all controls revert to standard Windows styling and are ready to be hooked up. (In theory)

Adobe Import - Blend has the ability to import any layered file from either Illustrator or Photoshop.  Each layer gets inserted into the Blend project as a user control, which upon import is just an image. Once imported though, you can tell Blend that this image of a text box is an actual text box, and poof it’s a text box and all the styling from the image is retained. The has great benefits for the interaction designers, visual designers, and user interface developers that work closely together.

Animation - Todd Zaki Warfel has a great quote regarding prototyping, ‘If you can’t make it, fake it.’ The animation capabilities in Blend3 allow you to fake just about anything, depending on your animation skills and maybe some C# or VB.net knowledge.

Right Click - Inside the Blend3 environment, right clicking is really your best friend. The majority of the settings and commonly used functions are available via this little context menu. This is also the main method for which to set up any type of click-thru behavior you want presented in the prototype. Denny Payton, who gave the Blend3 Demo, made that comment ‘If you are not sure how to do something in Blend3, just right click.’

Annotation Feedback - Any prototype created in Blend3 can be packaged as either a Silverlight application, or a WPF application, and shared among the project team, stakeholders, or used for some user testing. The method of annotation is great, as people can grab a virtual pen or highlighter and mark directly on the prototype, these annotations are stored with the actual project for review later. A message box is also available for more detailed feedback and all is captured in the project files for reviewing later.

Test Data - Lorem Ipsum only gets you so far when adding content to a prototype. Plugging in real world sample data can be done in a variety of ways. If you happen to have a functional test database, tables from the database can be bound to any control. Something that was removed in Blend2, but added back in Blend3, is the ability to bind to an external XML file. The real gem of Blend3′s test data capabilities is creating some on the fly, and storing it locally to the project. This way drop downs and list controls don’t have to be empty and the data inside them isn’t hard coded.

Cons:

Buggy - During the course of creating my prototype the application bombed out twice. Now, some might say crashing only twice doesn’t sound that bad, but any crash is bad in my eyes. At first, when creating the sitemap, somehow two of the nodes had become linked together. Moving the most recent one would also move the last selected, the solution came during one of the crashes when the behavior went away when I reloaded Blend. Though the layout of the framework is pixel perfect between the various screens, some UI controls still jump around in the produced prototype. For someone who is a perfectionist in this regard, it drove me batty!

Interaction Design of Blend3 - For some reason, someone thought that the most common use of the scroll wheel is to zoom in and out of the both the Design module and the SketchFlow Map module. Eventually, I found the setting that allows you to rebind what the standard behavior is for the scroll wheel and my frustration eased. The only way to remove a node or connection in the map module is by right clicking and choosing remove from the menu. The delete key is completely ignored from this aspect of the UI. This caused many mental ‘WTF?’ moments.

Structuring Site Map - While the SketchFlow Map module provides great value for visualizing the structure and flow of a site, it’s easy to create a very complex and confusing map for something more than a simple site map. It becomes difficult to follow the connection lines with the crisscrossing of each other, or placing component nodes in a meaningful location when they are shared by many screens. Hopefully, in future versions this module gets a bit more flushed out.

Component Placement - Creating common aspects of the user interfaces once, but using them in many places, is a great advantage for any designer. But, the component has to be placed individually on each screen it’s linked to. This can make the prototype look clunky since the same component might jump around as the prototype is traversed if not placed exactly right. This could be easily fixed if the background size of each component was the same as the overall size of the interface. When linked to a screen, the component gets  automatically placed in the proper place.

Screen vs Artboard Size - There is a huge disconnect between the size of the screen and the artboard that contains the UI controls. Now, I understand this disconnect is in place for detailed animations, but it would relieve some confusion when creating just a simple interface with no animation if the sizes were tied together. For the prototype that I created, it wasn’t until I ran the project that it became apparent that the screen size did not match the interface I had created.

Grid System - Though Blend3 has an underlying grid system you can use to place controls, it isn’t possible to create grid lines on the fly that are shared across different screens. This was the other reason why when the prototype was ran, the screen components would jump around on me. It’s possible to customize the underlying grid system, but it is application wide rather than limited to just the project.

Adobe Import Limitations - The way Blend3 imports the files from Illustrator or Photoshop put a huge burden on the designer working in those applications. The layers need to be set up so each UI control has it’s own layer and the layers are organized in a detailed manner. Now, having organized layers in either Photoshop or Illustrator is the ‘right’ thing to do, but sometimes time just doesn’t allow for it. It’s a good step in the right direction, but still needs a bit of work.

Word Export - Axure is hands down the best when it comes to turning a prototype into spec, Blend3 is taking it’s best stab at it too. The downside being that the produced document is very flat and only creates the images of the user interface. It can be argued that any spec is better than none, but there’s some good information you can attach to controls when they are being placed that don’t get exported into the document. Again, good first step and it will be interesting to see how this feature gets flushed out in the future.

Annotations Limitations - While being able to annotate directly on the prototype is great for gathering feedback, but in Blend3 it’s limited. Annotations are not store per instance of the prototype, but shared across different uses. This pretty much limits prototype review to internal teams and maybe key stakeholders. Allowing the annotations to be shared while performing user testing raising the risk for bias and invalid results. This seems like a simple enhancement to this features, and hopefully become available one day.

Media Sketch Controls - Though the control library available in the SketchFlow part of Blend3 provides almost any ui control you would need, it is missing a few. Generic placement boxes for media, like pictures or videos, are missing. Requiring the designer to use the generic shapes and text to put in placeholders. Granted, you could create a user control to fulfill this need, but it would be nice for generic media controls to be available out of the box.

Repackging Prototype – One of the promoted benefits of using Blend is to create a prototype or interface that could be used in either a WPF or Silverlight application. Sadly, it isn’t possible to just repackage a project into one of these formats when using SketchFlow. So, if you create a kickass prototype in WPF and want to host it as a Silverlight app in order to get some feedback, sorry that’s just not possible. (Like I wanted to do!)

Overall Thoughts

Seriously, kudos to the designers and developers at Microsoft for getting Blend to such a state that you can do create some kick ass prototypes. Though it has some flaws, like any piece of software will, it provides some great benefits for designers. The value could really be seen for any designer working in a Microsoft development environment, creating Silverlight apps or Desktop apps using WPF. The need for other prototyping tools like Fireworks or Axure that don’t necessary provide good output for developers in this type of environment could be replaced by using Blend3 with Sketchflow. I’m not saying one tool is better than another, but when you take into account the environment the project is being developed in, one tool may be more beneficial than another.

Images from the prototype I created

Seeing Things Differently – It is always best to keep in mind the people that always need a little help.

Designing A Unified Experience – Kim Goodwin gives an outstanding overview of design. Great video to check out.

Todd Zaki Warfel – redUX DC ’09 – Todd gives us a great run down of the workshop he gave on prototyping at the IA Summit back in March.

So You Wanna Be A UX Designer Part 1 – Beginning of the roadmap to success for any UX Designer. If you care about UX and haven’t seen this yet, check it out!

Being An Experience-Led Organization – Johnny Holland delivers up yet another gem.

Understanding Critical to Being Understood –  Rather than playing the give and take game, converse with each other and great something great.

247 Web Usability Guidelines -  Monster list of heuristics to consider when reviewing a design.