Still a saddening lack of dinosaurs though.

I confess – I’m for it. And I’ll go even further – I think “making it up as you go along” is one of the greatest, and most important processes of any age.

No great explorer set out with a detailed set of explorer guidelines. They adjusted and discovered.

No great inventor set out with a detailed set of inventor guidelines. They experimented and adapted.

No great leader set out with a detailed set of leadership guidelines. Leaders point the way and rally followers when their faith fails.

“Making it up as you go along” means that you recognize a good foothold on your way up a mountain and know how to take advantage of it (in other words, you understand your craft). But you don’t need (literally) a step-by-step instruction book (because you understand your craft). In software development terms, the “step-by-step” equivalent is a requirements specification. Kind of like paint-by-numbers for would-be Rembrandts who don’t yet know that method is incapable of producing genuine art.

As good as your tools?

One of the things I hate most about our industry (the web industry, the UX industry, the IxD industry, whatever), is the penchant for folks with too little imagination and too much process training, to force “development models” on us. We have “mental models” galore. We have “process blueprints” en masse. Sadly, we have a myriad of tools, but not always the proper skills.

There’s a Danish expression common to craftsman: “A worker is only as good as his tools.” Granted, good tools are critical, as is a good process. But tools represent the lowest common denominator. Even with the best tools, an idiot will make a mess of things.

Agile or ingenuity?

We’re still at the beginning of an era. The web is not yet 20 years old. We are very much making things up as we go along despite excellent pattern libraries and established best practices. Anyone who says we aren’t is either a liar or a fool. Unfortunately, in the interest of professionalism, many folks are trying to legitimise their existance by formalising their work processes.

The smart tool of choice these days for software development is agile. ‘Agile’ is basically a fancy term for making it up as we go along. Mind you, there’s nothing wrong with this. It’s a good technique used by the pioneers for whom oceans are named.

In the old, pre-computer era, we call this ‘flexibility’ and ‘having an open mind.’ ‘Talent’, ‘intuition’, and ‘ingenuity’ were also once keywords. When did we stop appreciating these abilities? We have, you know…

Now, agile development is being groomed for polite society (e.g. the clueless business executives who would have insisted that Columbus produce a map showing the exact passage to India before he had actually done his discovery work). But gosh, Mr or Ms Business Leader, agile isn’t Russian Roulette. It’s not going to cost a fortune – in fact, it will probably cost less than the idiotic “requirements specification” some overpriced consultant is going to talk you into.

Which leads us to scrum

‘Scrum’ is a term stolen from rugby (which follows a wonderfully make it up as you go along kind of gameplan). In the world of software development, scrum formalizes the informal iterative agile development process. The Scrum Master is a project coordinator who presides over meetings and shepherds the team based on a set of strictly defined rules. A formalised certification course during which potential Scrum Masters learn the basic rules and mechanisms takes several days. Why is scrum popular? Well, first, it’s not a bad process. Unfortunately, scrum can be a nasty weapon in the hands of the wrong people; business execs are often comforted by processes that are governed by strict rules. Particularly those pesky, unpredictable creative processes.

How to win the game? Stay loose!

It’s not that I have anything in particular against scrum, but I have a lot against creating gameplans that don’t allow for deviation or the unexpected voicing of a sudden brilliant idea that turns the whole project on its head. Good Scrum Masters know the value of exploring new directions. My problem is with the tyrants who blindly stick to this (or any other established process); who hide their own lack of talent and creative insight behind a veil of pedanticism and false authority.

Sorry Columbus, ignore this new world of yours. Remember, your job is to find a passage to India. What will you do between now and the next daily scrum meeting regarding this project?

How many of us slavishly follow our car’s navigation when we know it’s giving us bad advice? Very few – that would be silly. And how many times have we uncovered a blatant fault during the very first usability test? Does it make sense to test with several more respondents before fixing an obvious problem? Of course not – no matter what the test protocol may dictate.

Although I’ve singled out scrum, there are lots of other processes that can go equally awry. Many companies these days are busy trying to implement Toyota’s LEAN production system, often with disappointing results. Kaizen quality management (another Toyota development) can also go very wrong – and for the same reasons Total Quality Management, House of Quality, and Philip Crosby’s Zero Defects went wrong back in the 80s; too many managers let the process get in the way of the ultimate objective. Remember, the goal is the goal.

For every rule, there are myriad exceptions. For every battle plan, there are unexpected circumstances. For every process, there are fifty other ways to do things. So, my advice is to do what needs to be done, when you need to do it. And as to the gameplan? Don’t be afraid to make it up as you go along.

Great interaction design is a delicious soup. You boil a variety of different ingredients and spices in the right proportion,  and voila – pure bliss! Unlike other branches of design, however,  it’s extremely hard to write a recipe for interaction design. By its very nature, the interaction design process needs to be fluid and dynamic.

Interaction design tingles the complete experience over time. It tastes most satisfying in conditions when multifaceted flavors and ingredients are brought together. The bigger the challenges are —the more diverse and mixed the ingredients need to be. This beautiful paradox sits at the heart of the interaction design menu, very differently from other design cuisines.

During my time as a Master’s degree student in Interaction Design at Umeå (Sweden), I often found our group repeatedly doing the following:

• Obsessing with finding the ‘perfect’ solution to a problem.
• Frequently questioning the value of having mixed, diverse groups of professionals studying Interaction Design together. Were frustrating debates stemming from disparate backgrounds and differences of opinion really the most efficient way to designing interactions?

I haven’t found ’the perfect solution’ yet, but I do believe the process is a lot more interesting. Having experienced the inherent value of a multifaceted approach professionally, I believe that mastery in the interaction design process lies in perfecting those moments when the room is packed with people who won’t share your views and probably don’t have your skills.

Mastering the science of ‘We, not I’.

The quest for perfection and the myth of genius are timeless aspirations that meet with sporadic and rare success. Genius chefs (like genius designers) never seem to be able to cook the same dish twice.  Some modern authors, such as Malcolm Gladwell in Outliers: The Story of Success, debunk the notion of genius altogether. According to Gladwell, even geniuses like Mozart, The Beatles and Bill Gates had more than 10,000 hours of practice at doing what they did—iteratively—constantly improving their craft while focused on process. I believe that a mastery of interaction design process does not rest in divine inspiration and confined sketching (read: genius!). The key probably rests in learning to churn together – a pool of motley professions, backgrounds, skills and interests. Interaction design is a team-sport at its most intense, meaningful climax, and we need to change the way we train for this sport. We need to rearrange our kitchen in order to cook this soup – and we need to do it often, depending on what we’re cooking.

The big hurdle – we’re conditioned to think and act as individuals, not as groups. Could this be the un-learning needed in order to be able to synthesize truly well-rounded experiences?

As a former architect, the process of design was inevitably intensely personal. My colleagues in architecture were all inspired by the singular genius of Corbusier, van der Rohe and Gehry. Moments of solitary and inspired sketching were thought to be the catalysts for the ‘eureka’ moment. Graphic and product design Masters of that era worked in much the same way. Processes in interaction design, on the other hand, seemed to work in quite stark opposites. After migrating to interaction design, students from very different backgrounds were thrown amidst multifaceted peer groups—something many struggled to cope with. A group of motley backgrounds, each with their own stubborn opinions, conflicting ideas, dissimilar skills oft resulted in frustrated groups and heated differences of opinion during projects. Many were left questioning the value and efficiency of such a process. Product and transportation design classmates seldom faced this problem. They were still relatively blissful in the peaceful confines of their work-spaces, diligently pursuing that perfect sketch.

Wouldn’t too many cooks in the interaction design kitchen spoil the broth?

Craters and pinholes in the design of experiences

Our worlds of experience are riddled with commonplace examples of things that we buy and use, only to discover how miserably they perform and disappoint. Products alone seldom bring us delight by existing in isolation—we want them to link well with all other touch-points that a service/experience provide - offer us the complete experience! This is especially true of experiences that marry the behavior of people with physical and digital worlds a.k.a interaction design. In recent times, even architects and urban planners have acknowledged a need to collaborate with policy makers and service providers to create harmonious experiences at architectural, interior and urban scales.

While designing interactive experiences for tomorrow, we are all keen to create usable and desirable experiences that cause viral social innovation. Once perfect solutions are understood as mere aspiration, our goals as designers become the discovery and reiteration of newer methods that reduce ‘craters into pinholes’. I use ‘craters and pinholes’ as metaphors for the relative measure of how well knit the fabric of a designed experience can or should be. My hunch is that craters get reduced to pinholes when you’re working closely and constantly within diverse, multi-faceted teams. By encouraging creative friction – rather than avoiding it, focus is made to shift alternately between the bigger picture and the smallest details.

The interaction design community today is entrusted with creating seamless experiences that focus not just on a product or user interface, but the entire system and its surroundings. This need for holistic experience is rapidly shifting the way teams are being built. A closer look at the diverse compositions of teams at the Nokias, Microsofts and even smaller global design teams across the world and  would confirm this shift in paradigm. No one product, digital experience or pretty user-interface seems to satisfy. We seem to need and delight in experiences that are complete, well-rounded.

A holistic approach to the design of experiences

A holistic approach to design is definitely not alien to us. It involves a simultaneous attention to the bigger picture and the smallest details. Any successful user experience we use today would invariably embrace this practice. Throughout history, master-builders were often architects, painters and craftsmen alike. Post 1950’s, architects and designers like Charles Eames, Mies van der Rohe and Alvar Alto designed cities and chairs with the same design philosophy infused in both. Now more than ever in increasingly complex, transient times, the need for holistic experiences is vital.

Interaction designers sculpt time and data as critical materials (to quote Matt Jones), revolving primarily around understanding the needs of users/cohabitants, technology and business. To approach such design as a ‘whole’ – we need to understand the varying concepts of time and data through the perspectives of cohabitants, technology and business interests alike. We need to become sensitive to the different tastes involved, by bringing the right ‘spices’ closer into our kitchen. A holistic solution begins when we acknowledge that all parts of the triangle have something equally valuable to add to the process. We must constantly re-think our process to become melting pots of ideas, perspectives and skills that not only drill deep, but also wide.

We must constantly re-think our process to become melting pots of ideas, perspectives and skills that not only drill deep, but also wide.

Perfecting the craft of thinking and doing as a whole.

The team I now work with (at Ergonomidesign) has solved problems through design for over 40 years in a vast number of areas. Having solved design problems of various shapes, sizes and complexity, recent clients have frequently entrusted us with transcending realms of problem solving and instead design ‘cultural innovation’. “Think about the bigger picture” is a common task that comes our way. We are increasingly thinking about systems, experiences and objects that might co-habit our World tomorrow.

As the profession of interaction has grown and evolved, so too have our own methods. Our recent projects involved the design of holistic experiences mostly focused around medical systems. However, the lessons learnt from them have been beneficial to us in all our projects. For the projects being discussed our process relied heavily on the Agile method, which necessitates iteration and constant ’design by doing’. We often found ourselves playing a game of calculated ‘musical chairs’ when it came to design discussions. Our team comprised design—strategists, product and interaction designers, cognitive scientists, communications, medical experts, programmers and a host of other professionals—an approach that proved highly fruitful in ensuring the craters were reduced to pinholes.

Here are some experiences that I’d like to share:

• Remove hierarchy, acknowledge specialization – Building multi-faceted, diverse teams bringing different skills and perspective to a project, inevitably led to more comprehensive, well-rounded solutions. This is especially valid when working on service-design or complex systems. While working on design of ‘the bigger picture’ for our medical portfolio, our team ensured that we had enough representation from cohabitants (users), designers, medical experts, technical experts etc. The constant participation of these interest groups was maintained throughout the design process—for creative input and feedback. This caused several disagreements and debates – but the outcome would always nudge us closer to the goal of holistic design. This way we methodically reduced metaphorical gaps and craters.
• Zoom in and out between the bigger picture and the smallest details- Visualize, visualize, visualize! Don’t just talk about an idea—build, test and iterate them! Once we had a motley group of professionals working together, we combined our knowledge and skill to iterate and evolve our concepts. While developing a recent natural user interface (NUI), ideation began with 1:1 scale paper prototypes on A1 sketching blocks. We used transparent papers for UI-components. Once things made sense to everyone, our UX and programming team coded blocks out so that we could test it for real. Tests were shown to specialists within the team for feedback. Our final solution was a hi-fidelity prototype meant for commercial use as well as detailed, well-rounded scenario that showed our clients the bigger picture they so desperately craved. Working with the Agile method made iteration inevitable even when the end goal was not clear (something which is common during the design process, right?) The method also ensured that we were constantly made to zoom into details of a system’s behavior.
• Alternate between individual and collective ideation sessions; create transparent channels for cross-referencing and feedback - During the project, plan enough short sessions of iteration, constantly bringing in other eyes to review and discuss parts of the idea. As a interaction designer, it is almost futile and counter-productive to spend days alone and finally showing it to someone (we tend to do this as designers sometimes).
• Bring in the perspective of inclusive design thinking (critical users) to reduce massive craters – True to our roots as Scandinavian design group, we swear by a participatory, inclusive design approach. Design groups must plan meticulously to include the creative and critical involvement of user groups throughout the process. Even though the term user research and user-tests are now commonplace, it takes great skill for interaction designers to know how and when to collaborate with users. It takes even more insight for a design manager to facilitate their ideas and feedback into the design process.

Open-source culture (among other socio-technical developments) has given the World a successful honest, democratic model where the role of the individual is invariably participatory. Accountability and transparency are the foundations in open-source systems. It is inevitable that while designing for such a World, the essence of open-source is imbibed in the design process. The multifaceted, holistic roller-coaster ride to Interaction Design is definitely an intense challenge, often catching the most experienced professionals off-guard. It requires great planning, understanding and flexibility. Like collaborative efforts in theatre and the performance arts, it involves a close feeling of synergy with those involved. It requires the individual to shed ego and become flexible role-players in diverse, dynamic groups.

In conclusion, while the perfect outcome and solution must always be an aspiration—it is a mastery of this holistic approach to interaction design that helps create the well-woven fabric of an experience. Despite initial frustration, the process inevitably enriches everyone and leads to a superior design and a more enjoyable design process.

I currently work at a very small company, less then 20.  But compared to the other stories I’ve heard lately from interaction designers like myself, our company gets surprisingly consistent results from our developers in regards to design.  Following are 12 lessons I’ve learned that have helped me get better results from our in-house developers.

1. Be a developer

I can’t stress this one enough.  Development isn’t something that can be appreciated, it has to be experienced.  HTML and JavaScript don’t cut it, you have to go out and actually do what your programmers do.  Write SQL statements, create classes, build an application.  When you can follow along and contribute intelligently to all the technology discussions, developers will start to trust you that you understand them and what they have to deal with.  And most importantly you can help them find solutions they may not see yet.

2. Get in bed with the business people

At the end of the day the business people run the company and they control what the developers do.  At my company I spend a great deal of time with our project manager, VP and CEO.  I try to develop personal relationships with them.  I make it obvious that my goal in life is to help them articulate what they want to the development team.  Then when I present something to the development team, it’s not my idea, it’s what the boss wants.  And in the end the developers are actually happy you managed all that back and forth discussions with the business guys so they don’t have to.

3. Ease their pain

Most developers just want to develop.  They don’t want to worry about requirements gathering, deadlines, art, research, politics and all the stuff that goes into running a project and a company.  So the more you take responsibility for all these things they don’t want to do, the more they will work with you and with what you ask them to do.  When they need something from you, do it fast and with a smile.  The more enjoyable you make their lives the more responsive they are going to be when you ask them to do things.

4. Force business to iterate in design, not in development

There’s nothing a developer hates more then spending months on something that once the business guys see it they realize they want to do something else.  I won’t hand anything off to the developers until I have thought it through and iterated through it with the business guys as much as humanly possible.  There are many decisions that can be made off of drawings rather than programming it.  And business will quickly realize that getting the designers to change their designs is a thousand times cheaper than paying expensive developers.

5. No one gives a rip what the artist thinks

Even though you were hired as the design expert you still have to earn everyone’s trust.  Too many business people and developers have had bad experiences with artists who think they know everything or who are overly emotional.  You typically have a steep hill to climb to affect things as much as you need to.  Design in a business is all about being the facilitator and assimilator, not the dictator.  Collaboration is the only way to get design done in business.  If the developer wants to design, let them!  Just be there to guide them rationally and fill in the gaps when they have to go back to developing.  If you need an artistic outlet, do it at home, or you’ll always be bitter.

6. You get to control those lovely details

Once you’ve checked your ego at the door, something amazing starts to happen.  The funny truth is most business guys and most developers don’t want to think about the details, so you get to!  Usually people on the team only end up really caring about particular features, no one wants to take all that time to think through the rest.  So as long as their desires are represented or addressed, you get to fill in the rest with what you know is best.

7. Write it down, write it down, write it down

The beautiful thing about writing is that it’s the universal standard for communication.  Yes a picture is worth a thousand words, but you cannot draw interactions as well as you can write them.  My documentation is a mix of what we call “scripts” with supporting graphics at key points.  My friend is an html guru at a large company and his biggest complaint is that he gets handed a large Photoshop file with no documentation or annotations that are difficult to understand as a whole.  Writing can be difficult for designers, but it is incredibly effective at communicating the interaction to the rest of the team.

8. Get in bed with the QA team

The QA team is the group of people whose job it is to tell the developers they did it wrong, they are your design enforcers.  The better they understand what you wanted from the developers the better they are going to be at helping keep the developers on design.  It’s critical QA has the right kind of documentation to do their job, and you want to be in charge of that documentation.  The cool little secret about QA is that they like checklists.  I write my documents so that they are essentially checklists that the QA team can easily translate into test cases.

9. You have to have a middle man

In my experience developers do not like to do HTML.  There is a rare breed of developers in the web world called web designers who like to do this kind of GUI development.  But on the whole, GUI is too much of a mental stretch for developers who live in the abstract inner workings of business logic.  As much as developers may think HTML is easy or even beneath them, HTML takes just as much concentration as does any other kind of development.  In my experience the very best scenario is to hire a GUI developer to be the middle man between the designer and the developer.  A GUI developer is someone who cares about the visual details, but they can also code.  If you don’t get this guy you’ll always be fighting a losing battle with developers because they don’t want to do HTML.  They’ll end up butchering the designs simply because their interest is in business logic and such.

10. Proximity breeds understanding

There is a direct correlation to your physical distance from the developers and how effective you will be with them.  Currently I sit right next to my developers.  I hear everything they say, I’m accessible, we go to lunch, and I know what they are doing and saying.  If you hide in an office or work off site, you’ll have to spend a lot more time forcing collaboration to occur.

This one should be obvious, but there’s a basic rule that the more time you spend with someone the better you are going to be able to interact with them.  Be friends with the developers, kick their ass in Team Fortress, go to lunch, carpool, whatever it takes.  Get in their face and take as much time to figure them out as you do figuring out your customers.  Have you spent enough time with Derron to understand why he is such a grumpy loveable prick?

11. Learn to articulate well

This is where studying design comes into play.  Design is difficult to communicate verbally, it’s naturally an intuition and a feeling thing.  But the reality is no one is just going to trust your feelings without good logic behind it.  So you have to learn to verbally articulate your feelings.  The good news is there is actually logic and reason to art, but the bad news is it’s one of the most complicated things on the planet.  It’s complicated simply because of the fact that it’s based on the brain, which we understand very little about.  Computers on the other hand we understand very deeply.  Learning to verbally articulate design takes time, you have to take time to study it.  Study how other designers talk, learn patterns and read design literature like a mad man. Over time you’ll start to surprise yourself how well you can explain why you made the design decisions you did.

12. Good design is always hard to program

I finally realized this after being a developer and then a designer.  Your job as a designer is to get the computer to act more human and to be more understanding of human communication.  A developer’s job is to make a computer more like a computer, logical and efficient.  I came to the conclusion that there will always be a conflict between a designer and a developer because designers speak human and developers speak computer.  Your job is to make the computer do things it was not built to do.

Image: Yourdon

Over the last few years I’ve become more and more sceptical on the value of personas. I know they’ve always been a popular part in the user centred design methodology, which kind of means that they are holy. But I also believe that from the moment they were introduced they were also misused or based upon the wrong data. For me this was the moment to call in the help of a few experienced UX friends. Why should I still use personas?

For the discussion I e-mailed Steve Baty, Adrian Chan, Will Evans and Dennis Koks. This resulted in a four-day long mail discussion. Below is my translation and interpretation of that discussion, which proved to be of great value for me. Note: right before I finished this article there was an interesting discussion on the IxDA discussion list.

The way personas should be used

Before we dive into the discussion it’s important to look at personas from an encyclopedic perspective. What are they and what are they supposed to do? According to Alan Cooper, the grand creator himself, personas are and were originally intended as a heuristic. They are for client communication and orientation. As Adrian Chan states it “they encapsulate and personalize use cases.” To be able to do this you need to have quantitative and qualitative research data, which can be analyzed thoroughly and translated in worthy archetypes.

How are they often used?

Unfortunately the textbook description of personas is too often a myth. Everywhere I look they are NOT based upon thorough research and mainly a tool to please the client. Will Evans says “that a great many advocates of personas simply don’t get to do them – or do them right – because no money is allocated for design ethnography – and even if there is money dedicated to research, practitioners don’t know how to take that research and turn it into personas which are actionable in the actual design process.” I think his remark hits the spot. Maybe big companies such as Microsoft, Philips and Nike have huge budgets to do proper research, smaller companies and design companies often don’t have this luxurious position. But this doesn’t take away the need for proper data. We need to look for possible solutions here, which isn’t coming up with personas based upon assumptions and ‘experience’.

Adrian Chan, in my opinion a pioneer on the field of social interaction design, states “I’m all for a move among social interaction designers to replace cardboard user peronas and instead use psychologically-grounded personality types.” This could prove an interesting improvement. According to Adrian these personality types should not become archetypes, since these are usually not interaction oriented and not specific to social media. It’s an interesting thing to try and understand the personality types, expecially when they are based upon actual psychological research.

So at this point the scepsis was still in my head. Fortunately the discussion gave me three useful reasons why I should continue with personas. Let’s check them out:

1. Great for design decisions

One of the biggest advantages of having personas, based upon good research, is that you can use them for design decisions. As Will Evans puts it “Someone is going to make decisions – often a vocal stakeholder who thinks they know a lot more than they actually do – the VP of Marketing that wants to prioritize a certain feature or piece of functionality because “My daughter is our target audience – I know my daughter – so we should do X” and if a designer has no data, no research, and no personas derived from that – no matter how bad the idea – there is no way to argue against it. User research and resulting personas helps in making prioritization decisions about initiatives and features based on actual users as opposed to the whims of:
1. The designer with their own prejudices
2. The powerful stakeholder
3. The developer
4. Anyone who is not the intended audience”

2. Great as a debrief / briefing

When working for a client it’s really important to dive into their world and prove you really understand it. Personas can help you with this. They form a good summary of the target audience and are a great debrief for your customer. After presenting them I always start a discussion, trying to see how their world matches with the personas. Being truly interested in their audience, but also in how the client perceives it is worth so much. It brings you on the same level as the client, making them feel you really care about their message/product/service.

Another great thing, besides debriefing, is actual briefing. When fresh team members join the design team personas form a perfect guide into the project. They are a nice summary of the data, which gets the fresh people up to your knowledge level faster. This is the real goal of personas: being a means to translate and transfer research and knowledge to others. As Steve puts it “The persona provides us a way to transfer some of the value we derived from the research & analysis process to other members of the team. It isn’t a perfectly efficient transfer – some of the value is lost. That’s what we’re doing when we communicate *through* the artifact: transferring that knowledge/insight/learning out to people who couldn’t be involved in the process of producing it.”

Remember to approach personas from this perspective and it will help you make them more communicative. They should tell a story for themselves, dipping you into their mental and physical world.

The end result and the data is far LESS important than the immersion in the experience of the target audience – Will Evans

3. It’s about the process

I always learned to save the best for last. So this third reason was the one that made me a believer again. It was a quote from Steve Baty that made me see the light: “Personas are an outcome; not the process.” Everybody is staring at the outcome all the time, using the personas as if they are treasures… but that’s not it. It’s the process itself that’s priceless. Personas are only a tool that force us (designers) to do actual research. It’s a means to make us submerge in the world of our target audience and truly, deeply understand them. It helps Dennis Koks “to create a better understanding, and it helps [him] interpret the outcomes better during the rest of the design process.“ Steve Baty states that “only some of the value of personas is encapsulated in the end result; much of it comes from the exploration of the data itself.”

Personas are an outcome; not the process – Steve Baty

In the IxDA discussion Dave Malouf said that “if you are selling Personas then it seems that that is your first mistake. Sell research and don’t even tell people how you are going to model it. Maybe the research itself will tell you the appropriate way to model your analysis.”

So immersion is the key. In my mind it has even become one of the few user centred design approaches each designer must undergo. Will even wants to go so far “as a designer the whole goal is a violent sense of empathy for the user in their own context – the data in this case and the persona are completely useless if there is no bond with the end user. Design insights that were not directly experienced by the designer are worthless.”

“This raises an interesting question: do we need to carry out our own research? Is it enough to analyze the data? If we get a series of ‘design insights’, how bad is that?”  – Steve Baty

As a closure (in other words: I’m starting to repeat myself)

A thing about personas which, in my opinion, is still overrated… Is the value throughout the project. It is often believed that after personas are created they will live on and should come back in all discussions. Even when I’m typing this I want to believe it. I want to put their portraits on my desk and always use their names in discussions, but it almost never works out like this. For me they are important because they make me do research. When I create personas I have to force myself to trully understand the user and context. It makes me want to collect all the data and the translation into personas is more important than the end result. And after that the presentation of the personas to the client also helps to show and test if you really understand their customers. It’s a great starting point for trust with the client and forms a good discussion. After this I think they are less important for the people who actually created them, since they already submerged… they can use them as a reference, reminding themselves sometimes. But they are a great tool for new members of the design team.

I wish to thank Steve Baty, Adrian Chan, Will Evans and Dennis Koks for a great discussion. And Dave Malouf for stealing his quote. In my opinion this discussion is what Johnny is all about.

Images by moonsoleil & randy son of robert