Blog
A UX Love Letter to Engineering
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
Research : The Academic - Practitioner Divide
A Recap on the Talk
This week I attended PhillyCHI's event featuring Michael Carvin and Michael Zarro. The talk was entitled User Experience Research: Is there an Academic – Practitioner Divide? The discussion proposed the thesis that there is hardline division between the practitioner research and academic research. The talk was rich and the discussion afterwards fruitful. The conclusion was that there is much more room for the use of academic research within the practitioners day-to-day projects, but that due to perceived dense material, difficult search options, and time constraints many practitioners do not use the amazingly thorough research that is done in the field of human computer interaction. There also is the potential for further partnerships between academia and corporations within the Philadelphia area. When the talk was finished there were some tangential thoughts and further exploration that occurred as a group.
The Discussion
Rigor within User Experience (is there a lack there of?)
The subject of rigor within UX research was posed by Dave Cooksey of saturdave, an independent user experience consultancy. His concern seemed to me to be two-fold: 1. that there is not a rigorous community of partitioners providing the necessary feedback and constructive criticism on the amount and strategy for UX research and 2. that there is no standard for UX research, unlike other fields. Without such standards, there's no ability to measure the level of rigor or to even have baseline approaches to our methods. While many practitioners participate in discussing standards through a lively community online there is no formal academic requirement for practitioners in the field. In his talk. The User Experience of User Experience, another PhillyCHI event, Cooksey made the point that 'there is no qualifying test for User Experience Professionals as there is with architects or Doctors' and that 'we are not held to the same standards as other fields.' Yet, we are increasingly being brought to the table as experts in our field without the same formal qualifications as other disciplines. From my point of view this brings us both advantages and disadvantages. Without having formal requirements we are free to help shape what the field is in a way that other more formal professions are not. We have the ability to shape how we fit into a team through our actions. This could be seen as a disadvantage as well, which I think was more the point of the comment: that there are many practitioners who do not follow rigorous methods of practice, who could inevitably poison the perception of the field by producing low quality work and produce irreversible perceptions within the minds of our non-UX partners. This double edge sword I believe to be one though that is faced by many fields due to differences in the level of rigor at different institutions. Overall, I tend to lean towards the direction that our current position affords us immense opportunity to help shape our field as well as act as change agents in legacy institutional structures.
Is the bar set low for design research?
I brought up the point that was mirrored by another participant, forgive me for not citing his name, that the bar for User Experience professionals doing research is quite low. This relates to the way that we communicate to our clients and business stakeholders on the level of numbers and metrics. These are the bread and butter of what they do, and I feel that whenever research is cited or conducted by the User Experience teams, the tendency of business is to be either surprised that such thought was included in what is perceived as more of an aesthetic practice or to somewhat blindly take the research as fact without much questioning. This does get back to the earlier point of there being no true research standards in UX. I also feel it gets at this idea of the increasing overlap of product management and user experience professionals, as we get more refined in our ability to conduct both qualitative and evaluative research we are able to provide more objective rational behind our decisions and also speak more the language of business in a way that we have not been able to before. I recently wrote about this overlap in my article: Product Management and User Experience Had a Baby.
How can we use UX metrics?
After the talk a woman who also works at a large corporation explained to me that my comment on the bar being set low for research hit home for her. She spoke of a way that her internal design team has been able to improve the relationship with business as well as the outcome of the final product by creating User Experience Metrics that are more granular ways of measuring success and failure of given interactions and tasks. What these do is two fold: 1. it forces the designs to align closely with the business goals in a way that elevates the practice of User Experience within the eyes of the business as an important and rigorous practice that is integral to business success and 2. With the added inclusion of "how to measure success" tacked on to the definition phase of the user experience both teams are forced to consolidate and prioritize the use cases which comprise the heart and soul of the desired experience. At the end of a project when the product is within flight, the use of user experience metrics map seamlessly with the business metrics and both teams are able to measure success and failure concurrently.
Potential for Partnership: Academia and Institutions
The talk also raised the idea for more collaboration between academic institutions and corporations, especially within the Philadelphia area. By creating relationships either through a stipend or granting the ability to publish findings, institutions can have academic research and insight into their operations and products that may not be feasible internally due to timing, budget, or internal resources. This would require some level of trust on both parties and could be tricky from a legal perspective. However, from my perspective seems like a no brainer!
For now, I at least feel encouraged to reach out to local academics and libraries to use relevant published research within my daily practice.
PHOTO CREDITS:
http://trevinwax.com/2007/12/26/2007-the-year-in-book-review/
http://www.flickr.com/photos/taedc/5686750281/lightbox/
Product Management + User Experience Had a Baby
...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!
"Mental Models" by Indi Young (an illustrated summary)
Indi Young's book "Mental Models: Aligning Design Strategy with Human Behavior" has become a staple in the UX community. Its in-depth look at a type of generative research illuminates the ability for design methodologies to have immense positive impact on the overall customer experience. This method for determining the way people think is not subjective in nature: rather it is a system of carefully crafted, extensively analyzed, data modeling. The cumulative data of a large set of one-on-one interviews creates a warehouse of information to mine. User behaviors and tasks are then organized into respective groupings (towers) and matched against both existing and future products and services. By visually seeing the flow of the customer's task-based mental space across a strata of different market segments (user personas), business stakeholders and designers can have greater insight into where their roadmaps and existing strategies fall short of supporting their main consumer base. All in all, Young's method of data modeling is a powerful tool for businesses to enhance their experience strategy through gaining empathy for their customers by listening to their behaviors and experiences.
The attached document is an illustrated summary of the book, told in diagram form, that's right: squares, circles and few words. I thought it appropriate to summarize visually, aligning my end deliverable more closely with the book's proposed end deliverable of a full fledged diagram analyzing the data gathered, as it can be distributed both succinctly and easily. Feel free to re-use any of the diagrams should they help you communicate a specific idea to a team-mate or stakeholder, or take this summary as is: one person's interpretation of a wonderfully powerful book!
Download the Illustrated Summary
SOURCES:
Book: http://www.rosenfeldmedia.com/books/alignment/
Author: @indiyoung
Making Room for Listening
As a forward: just as I wrapped up this article a man in the coffee shop where I am sitting handed me a postcard with a large ear on it. You can call it coincidence, chance, I call it synchronicity. OH: the multitude of ideas for future posts abound.
"There's room for endless listening"
My dance teacher said this one day, one of the many insightful things he has said in the context of improvisational dance. I often find these nuggets of wisdom apply to my life as a whole. I am relatively sure that is the intent of his lessons. But that is another topic in itself.
There may be no I in team, but let there be ear!
Working intuitively as an improvisational dance group to create a performance in the moment is not much different than creating any project with a team. You must be flexible and open to the inevitable change that occurs on the "hot seat" or "stage." You must be willing to let go of control and at the same time maintain personal strength. The only way to do this is to listen: wholly and completely to those around you. When I am dancing, this means sensing the quality and emotion behind other dancer's gestures, posture, and breath, noticing the tangental projection of their movement and learning when to initiate and when to follow.
In the context of team-based projects: In order to move the project forward, there must be a deep sense of listening to the members of the group so that things are not communicated poorly, tasks are not misunderstood, but most of all so the group can perform not as individuals, but as a team, especially when there are things to get done and deadlines to be met. The mentality of "get 'er done" can have the ability to fragment a group without the ability of the group or the group leaders to focus on cohesion. Just as with dance, a good team-member knows when to lead and when to listen - in this way we all have the potential to be leaders as good leadership is about bringing people with you, which has nothing to do with the ego.
Listen up ego...
In order to make the necessary room for listening, the ego must be shrunk and kept in check for it takes up the same room where listening occurs. If the ego were a cloud that surrounded each person, by centering and shrinking this cloud, we could make room for additional listening. It may take great energy to maintain a small ego while at the same time have the strength necessary to listen deeply. But it's a fight worth fighting.
The phrase my teacher said has many levels: the term 'endless' says that this action of listening is one that can always be deepened. It also says that there are different levels or degrees of listening. The skill of listening is not static, but based on a dynamic spectrum. This is both comforting and terrifying. By shrinking my ego I leave myself exposed to the elements, I leave myself ready for people to listen to me the real me and I worry they may not like what they hear. At the same time, I feel comforted by the idea that there will always be endless room for listening, which means to me that I will never become bored; there will always be new levels of meaning to understand and no end point in growth.
Now if only there was a pin to deflate this ego, to get on the fast track, or maybe I'll just take the long road, and hopefully hear many things along the way!
Design in Business: creativity as an agent of change
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
From iPhone to iPad: translation not replication
have semi-recently joined a team that designs and builds mobile applications for both iPhone + iPad (and more recently Android, but that's a different story). It's been about 3 months now and, although I claim no expertise, I believe I can give you 'the skinny' based on my experience so far.
Here's a few things to keep in mind in designing for iPad versus iPhone:
Feature Parody
Loyal users of an iPhone app will know what features exists on the phone in depth, so think carefully before eliminating features. Also know, that if you introduce something new on the iPad its likely to spawn the desire to see it soon available on the iPhone client as well. Even though you may rationalize or even test your theory about a unique use on one, you'll likely be surprised by how people will perceive this as a defect. This does not mean that certain features won't be used more heavily on one versus another, or that the main use case(s) for one platform versus another won't shift (sometimes significantly). Rather, it means if the core application is the same, don't make any assumptions about what your users will want to have access to on one platform versus another. We see this in the app store, regardless of doing detailed market testing up front.
Respect the Screen
A larger screen does not necessarily mean way more is always better. I may be preaching to the choir here, but I think its a critical point regardless: The general rule of thumb (forgive the pun) is that 2 panels of content in focus at one time is usually more than sufficient to not force a 'drill-down', as on the iPhone, and at the same time still allow space for focused task completion. By panel, I mean a consistently displayed region of content. Panels with multiple "carousels" count as 1 region if the interaction is the same throughout the sub-groups. Many apps like Flipboard and other news apps even use the single collapsed panel on the iPad. This seems to be better when used for apps where browsing and consuming is the main use case, versus more granular management or task-based activities: where you 'get lost in the content,' but that's the point. However, a single column view may not be your best choice if you are simply displaying a list of content: The width of the iPad can make lists that were legible on the iPhone hard to read on the iPad without scaling down a bit or addiing a navigation panel. Also, all those times when you wanted to use photos on the iPhone, but couldn't becuase of space, rejoice! Use them on the iPad: less text more image.
The Public Pad
With a larger screen its easier for multiple viewers to look at the screen at a time versus a more intimate small screen. I also believe it's the perception of the iPad as a status symbol or "the cool factor." I think this is an important to take note of when working with a client on an iPad app because it has the potential to dilute the discussions on core use cases by focusing more on the wiz-bang of the product and less on the utility. On the flip side of that, the iPad also has the potential to really jazz stakeholders up for the design phase, which can be a really great thing as well. This said, I would take extra time to isolate / test the core use cases of the iPad and communicate them to your client, or co-create use cases with stakeholders to test, as there is often many varied opinions on what the value of the iPad as a platform is due to this perceived cool-factor and status symbol-ness.
For further web-pivoting on the subject:
iPad Application Design, by Matt Legend Gemmell
Designing for iPad: Reality Check, by Oliver Reichenstein
iPad vs. iPhone: A User Experience Study, by Nate Bolt
My Grandfather's IA Maps
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.
Dialogue through Documentation
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.