design

Image by Justin Gravante.
 
Dear Engineering,

No one says it aloud, but let it ring true, we are nothing without you. Designers and engineers are truly the heart and soul of the user experience. Let’s bring the best of each other out through communication, collaboration and embracing our common goals.

Love,
Design

We are nothing without each other.

Design and development have a relationship that is truly unique: one that is a force to be reckoned with if put into motion via collaboration, listening, and humility. The duo can create 'practical magic' by transmuting what is imagined into the realm of the possible. It may be that there are jacks of all trades, but in larger companies especially, often we find that designers and engineers are specialists in their field. These individual specialties are more powerful, more creative, and more capable together than divided. A user experience may be imagined, a comp may be beautifully crafted, but it is nothing more than a set of pixels on a screen until it is developed. We often hear the benefits of prototyping early: a design schema put into a prototype early on allows for teams to catch user errors and potential technical solution inefficiencies early on. An interactive design of any kind without a prototype is like flying blind. Prototypes allow teams to fail fast, early and facilitate room for early iteration.

Getting creative with technology is the best thing one can do!

Engineers help us designers find boundaries to work within. These boundaries are essential to the creation of design. A blue sky vision is in most cases not grounded in a reality that can touch the hands and lives of users. It also is much harder to create without limitations. Just like physical materials have properties which an artist can manipulate and experiment, so to in the world of virtual creation do technical properties allow designers to experiment within a ruleset. Sometimes the most creative ideas come out of technical limitations. An art teacher of mine once said: 'find out what the material does best and help it do to that.' By studying and understanding technical boundaries at hand, designers can start sculpting solutions that are imaginative and real. It's about successfully finding the edges of those boundaries early on that can often make or break a given design.

When working together, designers and engineers are faster than working alone. I am privileged enough to have the opportunity to work side-by-side an amazing engineering team and this allows for faster, more productive iterations. We are able to find on-the-spot solutions because we both have our sleeves rolled up, and are at the same table. Cross-functional teams are powerful because they bring together all different viewpoints rather than fragmenting them and forcing communication to happen much later in the game.

Performance, reliability, joy of use, and usability are four components that together make up a great user experience. Both engineers and designers have the ability to affect each one of these. An app that is beautiful yet slow is not a great experience. So too, a reliable app without a great UI lacks the human factors which comprise a satisfying experience.

Together we are more empowered to do something better: We are closest to the product because we are in the day to day, creating and building the product. Let's face it, if a product is not designed and built it does not ship. Don't ever forget this when you are working on a project. It can be easy to do so especially in large companies where business analysis and general management are forces of nature. But feel empowered in knowing that you have huge influence over the product at hand because you are knee deep in the creation of it, you are on the front line. Never loose a sense of ownership, purpose or control.

"Find your common cause and get fucking passionate about it." - J. Gravante

Purpose unites teams and inspiration drives teammates. Its essential to maintain momentum together. Projects are fluid, so is inspiration. Don't hold back! Share with your team: every inspiration a single person has when working on a project has the potential to inspire a team or even just one other individual. This leads to maintaining the momentum necessary to effectively move the team forward.

Be inclusive! Don't throw requests over a wall and expect good results. In fact, expect poor results - no one likes to feel like there are fingers pointed or walls are drawn. We are all in this together. Don't assume a designer doesn't care. Don't assume an engineer doesn't care. Designers can be flexible, we value the work that engineers do and understand what sweat and tears can go into developing a great solution: nothing is 'just magic.' Real people create real solutions through both design and development.

Share ownership with your teammates. Nothing is black or white. Every team-member has the potential to individually contribute, so don't de-value the power of co-creating. Feel empowered to speak up, especially when you don't agree or understand a design or technical idea. Sometimes the best results come out of the disagreements we have because they point out different ways of seeing the same problem and, in turn, allow us to expand how we think as well as to be more creative collectively. The more questions asked, the more thoughtful decisions are made!

Expand the definition of what you do.

Powerful teams respect dynamic roles. This means that I may not always have the same role on a team. I may have to wear many hats during the evolution of the project so I, in effect, expand and contract to fill in the holes of the team. Be flexible enough to provide room for your teammates to do their job best, be humble enough to ask for help when you need it, and be fearless in taking on new challenges. As you grow the team grows. Designs and engineers are both researchers and problem solvers. As some have compared the creativity that scientists and artists both have, I believe this dynamic to be the same between engineers and designers. We are more alike than one may first observe and with a common goal we can work as a great unit.

Play a role in every aspect of the process. Don't settle at being the bottom of the funnel. Your component may be a peice of the larger puzzle, but it is the overlap, those fuzzy areas where the true glue happens. Don't over-reach, but at the same time know that people will in most cases be thankful for your input. A holistic approach to design and development means a better product in the end. Not everyone is going to be a bridge to the extended team, but for those that are capable realize the importance of reaching out and getting involved in the greater effort.

Own it together! Unique talents comprise a team. Individuality is essential to gaining perspective. So celebrate individual talents, successes and opinions. A team is only as good as the sum of its parts. So let the individuals shine within the group and be vocal about these differences.

In conclusion: designers love engineers because together we can build, grow, iterate, evolve, make things, and get shit done that no one else can!
 
I have given a talk accompanying this information 3 times now. Please check out the slideshare! http://www.slideshare.net/henkenbean/a-ux-love-letter-to-engineering

////////////

Image + collaboration by: Justin Gravante
Inspiration: CIM Mobile Engineering and UX teams

...and it's called "Behavioral Systems Service Experience Design Innovation"... or something.

There has been a lot of talk recently about questioning the scope of experience design within business: In Adam Conner's article for Mad Pow, he states: "I believe Experience Design should be defined as a specific approach to design that treats the product as secondary and determined purely based on the ability to contribute to the creation of a desired experience." I tend to agree with this statement about the expansion of UX from the screen or product to the holistic experience and I also think it gets at the heart of the conversation on Design Thinking and other related innovation discussions.

In Sarah Malin's response to Bruce Nussbaum's Article "Design Thinking: a failed experiment" she writes, "Focusing on isolated elements of design thinking neglects a “systems” understanding of the whole skill set – ignoring the increasing need for systems thinking that can take in global reality in its entirety and embrace complexity." I think its astute to speak of "systems thinking" as this gets both at the heart of what business stakeholders, product managers, and designers all are trained to do: to make decisions based on holistic and complex data and systems. I'd rather take the discussion of what to call our field out of this article and focus on defining what I see the environment to be.
 

"I am a problems guy, you're the solutions gal."

That's a phrase I heard from a colleague of mine in terms of the relationship between his role as product manager and my role as designer. We are more alike in what we are attempting to do than many people think. In fact, our fields are beginning to overlap in real ways that are creating tension as well as sparking the above mentioned conversations. Market research which can pinpoint potential areas for business growth is not unlike ethnographic studies that User Experience professionals do to pinpoint sucesses, failures, and identify areas for innovation. In large companies product managers may conceive the initial product idea, but in the end we (user experience practitioners) are the ones at the front lines of the interface between that product or service and the consumer.  How can we make informed decisions about that interface without being part of the team that conceives, strategizes, and maps out the plan for not only what that product is but when and how the consumer will interact with it? It's like asking someone to make really pretty wrapping paper.
 

I want to be both a problem identifier and a solutions gal.

I want to help identify the experience gaps! Without having background into why decisions were made and previous history on the strategy and technology we can't help fill in the necessary holes in the experience, nor can we make informed decisions on the design. The problem here is a perceived lack of trust. By saying we want to be involved in the lifecycle of the product and service development phase, Product Managers and Business Stakeholders may not see the need any may even feel offended. They are trained specifically in market research, finance, complex decision making, yet we are trained in people and the creative thinking that will add value to those phases of that project and better inform both the design phase and the final outcome. We don't only want to present to business, we want to work together. And not just at then end phase, but from the formulation for the strategy phase. Why? Because design and business both want the same thing: a great product that our customers will love.
 

Asking lot's of questions leads to questioning.

I tend to ask a lot of questions, questions directed towards product managers, engineers, and other user experience colleagues. It is from these questions that I get the best ideas for designs, not from requirements documents or internal reviews. It is also from these questions that I believe I communicate most effectively, because by having a clearer picture of the larger system I can make more creative solutions from knowing the parameters before me. Then by then mapping the design back to the answers I get, the larger team sees the value of the questions when at first they may not have. This may seem commonsense, but I have been asked "Why do you need to know that? How is that related to design?" and told that I should not, "try to boil the ocean" by thinking to broadly.
 

Let's not boil the ocean...maybe just make it lukewarm!

Recently the company I work for decided to merge two main design teams creating a unified front for User Experience Design. The culture of the new team was entirely different: significantly less formal, faster paced with a much heavier focus on group collaboration. The difference was so immense yet it still seemed to still have a powerful synergy within the business. I began to re-think the how I saw the role of the User Experience group within the larger organization. This transition as a case study, I decided to analyze design within business: more specifically, the potential for cultural change within an institution via design thinking + creativity.
 

The turtle and the hare, can they work together?

I was excited to join the CIM mobile team this past August, yet it was a significant change that has taken me considerable amount of time to adjust to. I would almost describe this change as a culture shock! Excel spreadsheets were suddenly replaced by rainbow post-its, meeting invites were replaced by hollering over the cube walls, wire-framing individually was replaced by group white-board sessions, and "where's my adaptor" became "where's that sharpie?"

But I had grown to enjoy immensely the challenge of thinking of better ways to formally communicate in widely spaced meeting touch-points, to solve problems individually and then present them to a group, and to craft the order and content of a document such that it was catered specifically to my audience. I did enjoy the fact that the audience was always different, and adjustments of communication strategy were needed, many times on the spot. Although it did feel it was an us vs. them mentality: between design and product and then later between product and engineering.

In this new environment with an much more casual set of meetings / gatherings, I felt a bit like a fish out of water(fall). It took me a while to recognize that what I was perceiving as a lack of formality (or in my view a lack of perceived clarity) was not getting in my way, rather it was enabling me to think 10x more creatively. I could still individually contribute to a group brainstorming design phase in a valuable way by sharing the idea generation phase rather than dividing it. And that casualness that seemed to come with agility was not the sign of a loss of clarity, but a tool for fostering an environment of creativity.

But I was still left wondering if and how that culture shift would be recognized with the teams I had formally worked so closely with - would the benefits of this way of working translate and how? On the flip-side, would the fast-paced hare, stop to ask for the turtle's seasoned perspective?  Knowledge of the business at large was most certainly not something to just leave behind, or was it? Was organizational history meaningless? Enter my interest in design thinking and related fields:

Design Thinking, a background.

Design Thinking has been used to describe implementing certain forms of the design processes within larger business structures. Usually it incorporates the idea of cross-functional teams and early on discovery methodology to promote collaboration, enhance innovation, and in the end create better products that support the user and the business. Or as Helen Walters in her online article for Fast Company states, "it’s at this nexus and intersection that the thriving businesses of the future will be built."

We've all seen those ven diagrams which seek to illuminate the designer's process and read the briefs describing the designers 'plan of attack', which usually goes something like this, "define, research, ideate, prototype, choose, implement, and learn" from Wikipedia on 'design thinking'. A component of design thinking, is taking these approaches, alongside a toolset of different cross-functional collaborative ideation practices, to create anything from a product to a business strategy.

Company's like IDEO have leading the way in terms of using design methodologies within business, but also have served to elevate the status of design beyond its narrowly focused 'aesthetic' role to that of a strategic partner within business, government, and cultural institutions. Through partnerships with such institutions, IDEO has been a successful partner at the table of cultural change and leadership, helping to create fields such as Social Innovation, Service Design, and Organizational or Business Design. The birth of such design fields illustrates a shift in the way design is perceived by the world at large, and has acted as a catalyst for change within the culture of business.
 

Creativity as a agent for change.

In his recent article Design Thinking is a Failed Experiment. So What's Next? a former journalist of Business Weekly and early-advocate for Design Thinking, Bruce Nussbaum highlights some failure points in the adoption and success of design thinking, proposing a new meme, "Creative Quotient." Some are quick to criticize this article as a sign of a lack of accountability on the part of the Nussbaum, others are more supportive.

One things for sure tweets from the design community at large get at an important point: the ball has already begun rolling. Take this rather humourous comment from @gretared (Gretchen Anderson of Punchcut), "What does the death of design thinking mean for the construction of rooms with bean bags and the sales of post-its?" This comment hits close to home: I think of the construction of the large CIM City space in the building, chalk full of orange bean bags and plants, not to mention the walls full of post-it scrum boards that line the mobile development corner. But self-satire aside, I don't see Nussbaum's article as describing the end of an era, rather I view it as an attempt to get at the heart and soul of a deeper inherent idea: the elevation of creativity as a valued and respected form of intelligence, to be applied to many arenas including, but not limited to, leadership, innovation, and strategy.

But change does not happen overnight, and in a large corporation, incremental change is often the way. I can see many glimmers of this, especially as described before in the adoption, at least in-part, of certain aspects of agile methodology and the implementation of cross-functional teams, which no-one is slow to mention the mobile team as a successful example of this practice!

So how can we as individuals designers act in support of creativity as a change agent? At last years Wharton UI Conference at Penn's Wharton School of business, Cory Ondrejka gave a brilliant talk entitled: Angry Dinosaurs: Accelerating Change and Institutional Incompetence. Where he advocates the following process for creating change within an institution (lovely nicknamed institution-hacking):
 

• find a space to work in where you have room to experiment/explore,
• collect data and build value from this data,
• publish findings (be transparent at least within the business) with a sustainable interface,
• include the customer in this process,
• "fail fast, cheaply, and publicly."

Sound familiar? For this process to be adopted, Cory recommends the following, "If you are trying to change a group, find the people who are your critics and make them your fans. The way to make them your fans is by spread the wealth, not to go around saying they are stupid dinosaurs." Which get's me to my last point:
 

When offered a seat at the table, respect the rules of the game.

By this I mean: in order for design to be a respected participant at the table within a business, a certain level of mutual respect is in order. A business stakeholder's lack of trust in the seemingly fuzzy design-speak about collaboration and creativity is not unfounded, especially if previous success has been proven through traditional business practices. Even though design thinking and creativity may have a multitude of recent successes, within the company I am part of, and it may seem refreshingly promising to jump on the bandwagon, there's still the voice of experience and tradition to resist the urge. These are often difficult to argue with, especially in terms of the inherent risk which accompanies true innovation.

I do not believe all stakeholders are indelibly averse to change, rather that we can't expect to build something internally or shift a culture without recognizing the foundation and system around us. Or as Helen Walter's says, "Designers who are looking to take a more strategic role in the organization, who should really be the figures one would think of to drive these initiatives, need to ensure that they are well versed in the language of business."

So let's check our communication style and our methods of quantifying success, such that we are working within the existing language of business, and not adding the to the perception of design thinking and creativity as risky. We can still employ agile and creative methods, while effectively communicating bottom-lines, evaluating metrics for success, and most of all being clear and honest in the way we communicate.

With all this said, internal design groups are obviously quite well situated to initiate such conversations, to collect large amounts of valuable data from customers, and have enormous potential for the specificity of knowledge required to create amazing customer experiences because they have the a level of visibility into the structure of operations and the culture of the business that external agencies do not. This assertion was echoed in Jarad Spool's talk Anatomy of a Design Decision where he mentions the advantage of internal design groups in creating powerful 'experience-focused' design or the design of the space 'between activities.' It's this transitional space is the exact realm I consider a required space for design at the holistic customer experience and service level.

As designers, we are in an extremely exciting space, within institutions that are supporting new technologies, innovation, agile development (at least for certain projects), and by considering opening the door for design partners to start having a voice at the table. By seeing ourselves as valuable experts in creativity, by finding a common language to communicate, and by including a diverse array of business parters in practices used in our own field to solve problems, we have the potential to not only create amazing experiences for our customers, but to also help evolve a changing institutional culture.

SOURCES:

Nussbaum, B. Design Thinking Is a Failed Experiment. So What's Next. Retrieved April 6, 2011, from http://www.fastcodesign.com/1663558/design-thinking-is-a-failed-experiment-so-whats-next

Ondrejka, C. (2010, June). Angry Dinosaurs: Accelerating Change and Institutional Incompetence  Keynote Talk, from Wharton School of Business Higher Ed Web symposium, Philadelphia. PA.

Spool, J. (2011, February) Anatomy of a Design Decision Presentation, at the Wharton School of Business, Philadelphia, PA.

Walters, H.  Design Thinking" Isn't a Miracle Cure, but Here's How It Helps. Retrieved March 24, 2011, from http://www.fastcodesign.com/1663480/helen-walters-design-thinking-buzzwords?partner=homepage_newsletter

I found these diagrams printed on glass slates in a box from my grandfather, entitled: "THERMAL AGING OF LAMINATES." I find it interesting that even engineers document similar processes and systems in the same was as UX designers today. These slides were in the same box as others showing graphs of different materials aging overtime. I assume they were used for a presentation as each slide has a number and all are on clear glass. I wonder what the words behind each one would have been. Here's my interpretation:

fig. 1
A proper assessment of a given property [for a thermal material] should be made by taking a look at its significance (usefulness to the client), calculating the value of the property at hand, and evaluating the level of economic efficiency, which can be done by measuring how much time and equipment must be used to create the material.

fig. 2
Factors that affect the evaluation of the end point [data] include: the discrimination of evaluator in relation to other data points calculated, the significance (or use) of the given material and its overall rating, both of which are a function of time.

fig. 3
The format for evaluation includes the type of equipment, its model number, the system employed by this model number and the type of material being evaluated.
 
Because these are pretty high level, and the other slides are generic graphs without data, rather titles like: Properties as Functions of Aging Time." I either think he used them in a class on electrical engineering for students, or to explain the processes he employed at his business to potential clients or investors. 

It’s ... a challenge to illustrate a holistic view of a site that has a nontraditional navigational structure." from  Is The Sitemap Loosing Its Client Facing Steam by Vincent Au from UXMag.com.

This is a great article that makes you question about the value of traditional site-maps and UX documentation. I have been thinking about this a lot recently, since I am transitioning from a team that works with a different larger dev group to a smaller more agile one. I am not yet sure how UX documentation falls into the picture, but I do know that all very successful meetings I have presented at, have had some type of support documentation tailored to the goal of the meeting. This makes me feel confident that some level of static documentation will live on if not only for means on in-person communication and decision making.
The level of formality of a design presentation or meeting can vary greatly depending on who your client is. At an internal agency this holds true as well. With many different teams in a corporate environment, there are many different types of presentations and brainstorming sessions which occur. Creating documentation that can both be presented formally in a meeting to stakeholders, as well as live on as the building block for development documentation can be a way of keeping track of decisions made as well as framiliarizing different teams with the evolution of the design.

When creating documentation for a meeting I like to start with the following basic outline for the slides:
 
1. The Opener
Questions, open issues, related projects, goal of designs. For visual support it can be great to diagram out the different things that are open and who the related teams or stakeholders are that need to weigh in or if the project is further along, open issues, questions, or timelines.
 
2. The Design Schema
This is completely dependent on the audience. By schema I mean to include either a IA map of some kind for a business stakeholder responsible for menu structures, a diagram of features for a stakeholder responsible for the product definition, or the core wireframe templates called out by name for an internal design review. The point is, you have to identify what are the key decisions you make in your design that your audience will care about. A developer may not care about what the menu options are called, whereas a content programmer will.

3. Detailed Designs
In the later sections is where I show more detailed wireframes or visuals only after the design system or schema has been presented. Often times if you start with this the meeting goes slower because you have not laid out a foundation yet, even when discussing internally.

If you have such a document for a presentation or meeting, it can easily evolve into the development documentation. Even if designs are prototyped quite quickly, you still have a record of the decisions made and questions considered.