Kimboux.

For those who would like to know - and those who are forced to read (sorry, Mom.)

I have always loved helping people. Be it advice about life, the best running shoes, or the perfect gift for <some type> of person. I get really excited when thinking though solutions, ideas, and adding technology in to the mix.

Growing up I could never really stick to just one hobby or interest. I found that I became passionate about many things. When I began my life as a student in college I found that I was interested in many subjects. I felt inspired and challenged by the business courses; determined to make a change from political science lectures; and completely fascinated by the human brain and learning human behavior during my psychology lectures. 

I enjoyed studying psychology, but I didn't want to be a therapist. While I loved helping people, I didn't want that to be the only way I got through to people. Simply put, I wanted to create and build things. I also wanted to be in a fast paced, creative environment working with other towards a common goal.  

I was really interested in how people behaved in life and in the business setting. I took a course on Industrial Psychology, and I started to make a conscious connection between my interests.

I soon realized that I knew these things about myself:

I wanted to help people facing challenging problems

I wanted to continually be challenged by my work at hand

I wanted to be inspired by those around me, just as many of my professors and peers had done so in school. 

I also knew that I never wanted to stop learning. College really taught me the value of being in an environment where you learn something new every day, and you are continually challenging yourself to improve yourself and your skill set. 

So what was I to do with these needs and motivations? It shouldn’t come as a surprise that a career in User Experience Design was the perfect fit for me.

Balancing the needs of the business, users, and development team is something I excel at.

I worked part time at the ERP (enterprise resource planning) company QAD while being a student. It was the perfect balance for me at the time. I loved learning about business, economics and psychology, and applying what I learned to my work at QAD. 

So how did I begin designing? I was already doing UX Design work - and I didn’t even realize it. As a Quality Analyst for the UI Group, it was my job to make sure new and existing features and products were working properly.

It didn’t matter if the feature was old or new - I was constantly analyzing the product to be better. Just “functioning” wasn’t enough for me.

Interestingly enough, after my first week at QAD, our Product Manager left the team. We decided to split ownership of the product amongst the team, and never filled the position. We all had a sense of ownership and because I was sitting alongside the developers, I was able to ask questions like, “why can’t I see how many steps I have to complete this sales order?” or, “why are the form labels and fields so far away from one another?” I was flabbergasted by certain UI bloopers that just seemed so obviously wrong to me.

I fought my battles one by one, but I was still mitigating the results, rather than fostering a better solution by being a part of the design process.

It wasn’t until the Global Requisition iPhone and Android app that I finally got to design the product before it was implemented. I was still pretty oblivious to the whole world of UX as I know it now, but I had a pretty good idea of how to start the design process. I began speaking to users. 

I started talking to internal users at QAD. I asked them what their current workflow was, and asked for them to walk me through a couple day to day situations.

From the beginning of my design career, I have always been more interested in what users do than what they say they do. 

I wanted to understand who the user was, what their goals were, and what was getting in their way of being more efficient, successful, or pleased with their overall experience. 

I researched the product extensively. I was known as the “GRS expert” at QAD because only I understood the complex workflows and quirks of the product.

I was able to design a mobile application that didn’t just rebuild GRS in to a mobile experience, but it also redesigned the users flow through the system in a way that was more consistent with their mental model.

We were also able to surface some key status indicators that wasn’t available in the desktop application. I knew about the importance of those status indicators because of a workaround I observed users employing during the user study. The GRS application was hugely successful. It was QAD’s first mobile application, and we were quickly on to building the next. 

After the GRS project, it was clear that I was interested in doing design full time. I was fortunate enough to have an incredibly supportive manager and mentor who pointed out that I was currently doing UX work and I should invest some time in training myself more about it.

I quickly became overwhelmed with excitement and enthusiasm when I realized the community that was out there.

Immediately after stumbling upon the field of UX I just knew it was the right path for me. Everything I read just felt so natural for me. I just immersed myself in the books, tutorials, blog posts, and even began a few personal projects to sharpen my skill set. 

While many of the UX competencies have come naturally to me, some have been more of a challenge to improve upon. I don’t see myself as a visual designer, but I am improving and am continuing to work on improving that area of expertise. I do feel that I excel in many competencies that are harder to learn. Such as having the right intuition about something. I heavily rely on usability testing and user research with all my design work. I find that right when I put a design in front of a user, I can see it through their eyes. Even if they hesitate for a moment when navigating a task at hand, I can see that problem immediately and sometimes think of a better solution just as fast. It’s an incredibly powerful tool that we as designers should take advantage of. 

A recent blog post on Smashing Mag by Pete Smart recently got me thinking…

When do I come up with innovative design solutions? There are plenty of situations, environments, mental states, etc. that help foster a creative process.

Pete addressed a very important one that I have also experienced. It’s during a time when I, as a user, am struggling with a product. As a UX professional, when I’m writing design specifications, and I struggle with connecting the wireframes with the user requirements, the design specifications, etc.

It’s really nothing earth shattering, the notion of innovating with observing users in their natural environment. It is the cornerstone of User Centered Design, observing users in their natural environment.

If we can immerse ourselves in a way that fosters a deep sense of empathy, and if we are indeed the usability professionals we promise to be, we can better provide solutions to their problems. Observe, analyze, and consider solutions. Validate your designs by immersing yourself in that same problem, and ask yourself, “Is this the right solution? Would I be content with this new design? Are there still usability problems?”

Here are a few resources that I have found to be incredibly helpful for getting started as a usability professional. Enjoy! 

  Must Reads:

The Design of everyday things, by Donald Norman.

  Don't Make Me Think, by Steve Krug.

Rocket Surgery Made Easy, another great and quick read by Steve Krug.

I would highly recommend all of Edward Tufte's books.

Universal Principles of Design, another great book to keep on hand. I frequently reference this one.

Some of my favorite sites:

nngroup.com

uxmag.com

http://alistapart.com/

http://boxesandarrows.com/

http://www.smashingmagazine.com/

http://www.humanfactors.com/home/usability.asp

http://sixrevisions.com/

http://www.uxmatters.com/

usability.gov

uxbooth.com

http://www.blog.theteamw.com/

  People:

http://www.jnd.org/

http://www.nngroup.com/articles/

http://www.asktog.com/

http://www.lukew.com/

http://www.minimallyminimal.com/

http://designingwebinterfaces.com/

Introductory and getting started Articles:

http://www.nngroup.com/articles/usability-101-introduction-to-usability/

http://www.sarahdoody.com/getting-started-in-user-experience-design/#.Ueghvj6XLS0

http://uxdesign.smashingmagazine.com/2010/01/05/25-user-experience-videos-that-are-worth-your-time/

http://whitneyhess.com/blog/2009/06/30/so-you-wanna-be-a-user-experience-designer-step-1-resources/

http://whitneyhess.com/blog/2009/11/23/so-you-wanna-be-a-user-experience-designer-step-2-guiding-principles/

http://3.7designs.co/blog/2010/07/ten-laws-to-design-by/

I have recently been asked this question by numerous people in the UX field:

"How do you communicate to Developers and other Stakeholders?"

This is obviously a very important question. If I, as a User Experience Designer cannot effectively communicate my design thinking, why would a developer want to implement those designs? Why would a product owner support the process without understanding my due diligence?

My typical UX design process has several key areas that I try to focus on and communicate effectively to those in question.

My rationale - this often involves the why and why I arrived there. Why do we need this product or functionality? What utility does it provide to our users? This is where I inject as much evidence based upon research, competitive analysis, technology trends, etc. During this time I might also explain why I might suggest not implementing a product or feature based upon technology constraints, user needs, or other factors that I support with - you guessed it - more research.

Objective: my rationale should effectively convince stakeholders of my position or suggestions. If ineffective, I need to adjust my original assumptions or iterate through my work to build a stronger case.

My process - this is how I arrive at my rationale. It is the flow of applying research and design principles to solve a design problem. When communicating my process to stakeholders, it is important to share with them not only the destination, but the journey that brought me there. If we're designing an interaction, what other alternatives did I consider? Why did I choose one over another? Explaining my rationale along with the steps of the process has proven to be highly effective for communicating with others. 

Key points: introducing my process to other stakeholders makes them a part the process. By involving others, they take and feel a sense ownership.

Execution - once I have validated internally by communicating the how and why, I validate the designs externally. It's important to keep the communication lines open during this step as well. By presenting the key usability findings to original stakeholders, we can iterate through the designs to better fulfill our users needs.

Goals: balance the needs of the users, business and product by listening, understanding and working through those needs. As a usability professional it is important to not only listen but provide insight into the voices heard. 

I've been going through the book Universal Principles of Design, and had a few thoughts on the Prototyping chapter. To summarize:

"The use of simplified and incomplete models of a design to explore ideas, elaborate requirements, refine specifications, and test functionality." -Universal Principles of Design

Prototyping is an incredibly powerful tool. I have found that its use never expires - contrasting to that of a deliverable product, which is finalized, released, supported, etc. You can go back to prototypes weeks, months, or potentially years later as a reference point for future projects.

"Why would we use <control a> within a <design pattern> when we know from Prototype X that it would be better to use <control b>?" -Retrospective team member

This is why it is useful for prototypes to be added to a design teams library as a set to reference, use for starting points, and inspire new concept creation. 

According to Universal Principles of Design, there are three basic kinds of prototyping: concept, throwaway, and evolutionary.

Concept prototyping is used to explore preliminary design ideas quickly and inexpensively. A concept prototype would ideally not involve any coding or time spent past the time spent to conceptualize the ideas. Paper prototyping, and rapid prototyping tools such as Axure RP and Balsamiq are ideal tools for this process.

Throwaway prototyping is useful for designing, testing, and validating individual or specified components of the product. It's not uncommon to mix the fidelity types with throwaway prototypes. For example, you might have a high fidelity component within a low fidelity container. The overall goal of throwaway prototyping should be focusing on specific interaction types, validating against a set of options, and iterating through them.

Evolutionary prototyping is often the method used for creating a completely new design, metaphor, or UI. This UI might have undefined design specifications, or they are intended to be discovered along the way of prototyping. Researching, evaluating, and iterating through the prototype until it arrives at the final design. Use Incremental prototyping during larger projects, which is the decomposition of a design project in to multiple stages, or - to be consistent with agile - sprints.

Learnability, efficiency, memorability, errors, and satisfaction all define the 5 quality attributes of usability. However, for software such as Enterprise Resource Planning, there are other factors to consider. I would argue that utility is much more heavily weighted as a quality attribute for ERP solutions than the aforementioned ones. 

ERP software is complex, it solves a profusion of problems, hosts a plethora of features, functions and solutions. It has the reputation of being unusable, unintuitive, and heavy. As a designer, researcher, and usability expert, how do we address these issues?

Before addressing whether something is usable or not, one must first determine the utility of it. Often times, we are so rushed in the development cycle that I wonder,

"is this what the users really need?" 

Often times, I am hard pressed to answer, absolutely not.