How should the teams for design be built? There are thousands of handbooks how to build effective teams, so let’s not get into the generics. There’s one specific aspect of design teamwork that I would like to emphasize, and that is the collaboration of interaction design and visual design.

I may have mentioned before, that in a process where interaction designer creates wireframes and then hands them over to a visual designer for decoration, the result often is — decorated boxes. Creating something more, something that is novel, meaningful, effective, fluid, dynamic, alive, and mesmerizing, will require very close cooperation between interaction design and visual design. The boundaries between disciplines are the surfaces where the most communication problems arise, but – I claim – that also the magic happens.

The best designs are such where ingenious interaction design meets ingenious visual design. Therefore my optimal team setup would be such that there are always one interaction designer paired with one visual designer. (This is not unlike the AD + copy pairing so common in advertising industry.) They both need to understand and respect each others work, and get along very well otherwise too. When I see this connection in action, when I overhear these designers sitting side by side and arguing and developing ideas together, I know that we are doing something that very few design studios can.

Mikko Franck, a respected Finnish conductor, was asked to help out and rehearse with an amateur orchestra for a full weekend. He arrived at the site, and just for a trial started to conduct the first composition. The musicians in the orchestra didn’t play particularly well. In fact, they struggled to keep in their tunes. After a few bars he put his baton down and said: “I’m sorry, but I can’t help you”, and walked out.

I’m not 100% sure that this is a true story. Nevertheless, if it weren’t, it wouldn’t make the point of the story any less clear. Just like the orchestra conductor, you as a design lead you should concentrate in the big picture and the nuances of the details that make designs perfect. If the basic skills of the designers that you work with are not there, it will take a lot from your time to simply teach people how to design.

As discussed earlier in this series, you will need a lot of raw material from the designers, based on which you can steer the project. In addition to being able to create solid designs and creative solutions (preferably better than you ever could), the designers must master the basic tools and able to express themselves verbally and visually, and be great communicators. Only then they will be efficiently provide the raw material for you that you need so that you can orchestrate the design.

Naturally, there will be different designers that you will have the chance to work with. Some will be less, some more experienced. You must coach new designers to be part of the team. But don’t let that take all your time.

PS. Sorry for the long gap between #10 and #11. Been busy with fascinating projects – and also the series is now starting to discuss issues with people so maybe I’m subconsciously postponing these as it’s difficult to stay politically correct.

Watercolor paintings and oil paintings look no doubt quite different. The artist had a vision about the desired end result and then selected the painting technique that is best suited to reach it. In any form of art or craft, the tool is always visible in the end result. The same applies to interaction design.

The most typical process for interaction design is to draw wireframes of screens. After that, a visual designer will start working on the wireframes and designs the visuals. This process and selection of tools will be visible in the end result. Let’s say, if you design with Visio/Omnigraffle/Powerpoint, and then fill in the boxes with graphics, you will get … boxes with graphics: screens after screens, dialog boxes, windows, discrete states, z-hierarchy.

However, discrete (yet pretty) boxes is not my ideal of an optimal UI. What is your view as a design lead, what kind of result would you like to see? In my view, the UIs should be much more dynamic and fluid: canvases that transform to other canvases, objects that flex and transform, use of different shapes, fluent transitions. Interaction, that is genuinely utilizing the continuity of time. UIs that never stand completely still. Interaction that smoothly leads viewer’s eyes, hands and mind.
I’m not sure if there are proper design tools available for this. What would be the next generation of Harel’s state charts to describe and specify fluid interaction? Anyone?

Demos are great for many purposes. The most obvious ones are to communicate the design to someone else, and test the UI with end users. However, in a large design project, the less obvious purposes may be the most important ones.

A demo or a simulation is the best tool for telling about the ongoing designs for people outside the project. You can try to explain the design intent and use cases with bullet points on paper, but when people see and feel the designs, they will finally understand. In my work when presenting designs, I usually have simply skipped all slideware and presented the design only through an interactive demo. While using the demo it is quite easy to verbally point out different elements in the design, and at the same time tell the background story; the design rationale. It’s also a good test if you really know your story.

You can’t get a feeling of an interactive UI on paper. The first audience for a demo is the designer herself, or you as a design lead. By trying the designs out you can be confident that they really do work (for the user). With experience you can predict quite accurately if a design will perform well in user testing. Naturally, surprises still do happen.

One important aspect of building demos is process related. Without a demo, you perhaps can keep on working with different parts of the designs separately. Designing like that for long you run a risk that at the end, the bits and pieces will not fit together. Here where building demos help. The prototype engineer (or whoever does this for you) needs to get all the designs, well documented, with all the graphic files, and then make them all work together in the demo. Usually you will find that there are quite a few gaps, missing designs etc. A demo will force you to put together a complete system, not just parts of it.

A demo is a shared effort of the whole design team. Everyone’s contribution is needed. Demos help you feel that you are building one system together. If you can include good looking, although not necessarily final, graphics into the demos, you can also give the team a good morale boost. They start to see their efforts materialize and set further expectations for the final delivery.

PS. Fascinating discussion initiated by Jon Kolko here. I wonder if I should change the name of the series to “Interaction design leadership”…

Agile software methodologies were developed for creating small software applications for company internal use. The process was intended for small software teams. Most certainly, no user experience folks were involved. Anyway, software developer is UI designer’s best friend. If agile makes them perform and feel better, it is good for UI design too. Agile is just very, very different to the traditional UI design process.

Design process itself is agile. I doubt that there are any interaction or visual designs that were designed with a pure waterfall model. In any challenging design task, when you start to draft solutions, you soon understand if the original design intent that you are aiming at is correct after all. The iterative nature of detailed UX design, with prototyping and evaluations interleaved, bears similarities with agile.

My experience in embedding UX design in agile is that although some parts of the process are not completely compatible (for example, I strongly recommend fixing the basic concept before development sprints start), there are so many benefits in agile that I am a true supporter of this approach. Designers must be integral part of the sprint teams. In that way, they participate sprint planning, scrum meetings etc so they can every day keep track what happens with the implementation. Usually designs need to be iterated during the implementation – nobody can design pixel perfect stuff in one go – so optimizing the UI and SW together can improve the quality while the code is being written rather than with fixes afterwards.

Designers often don’t understand all the possibilities of the modern SW engineering tools, ready-made components , etc. While working with coders, the designers can learn that designs they thought would be difficult to implement may actually be quite easy. And designers don’t have a monopoly on good ideas. The best design ideas might come from SW guys too.

Close collaboration helps developers share the feeling of ownership of the designs. They want to implement something really good rather than just what has been specified. UX designers should learn to appreciate their best friends much, much more.

Have you noticed how well a couple of screenshots of UI designs can inspire discussion? In project reviews, technical architecture charts may get a question or two, but when you show UI designs, everyone has an opinion. Although this is sometimes quite annoying (you don’t want to know that someone doesn’t like the color), but I find it quite exciting and positive that our work gets people talking. I think it is finally when people see the UI, they can concretely see how it feels like using the product or service, and that’s the moment when they really start to comment if they have any concerns.

As a design lead, your work is continuously under critique. It is in the nature of designers to criticize and receive critique. Therefore I have sometimes made the mistake of directly criticizing work of other disciplines. They might not take it very well. Although I must be able to take it, they are not used to it.

Part of the job of a design leader is to review other designers work. There are a couple of ways how this typically happens: through informal discussions, through official review meetings, or reviewing designs off-line on paper. My absolute favorite out of these are the informal discussions with designers. In that way, we usually get into interesting and relevant discussions where the deep joint understanding is eventually formed.

Quite often in a busy environment you need to do reviews very quickly. This I find very disturbing. User experience is not skin deep: you cannot review a design by just quickly looking at it. This may work with traditional industrial or graphic design, where the design is everything you see. But with design that has several layers of interaction, you need to spend considerable amount of time to walk through plenty of use cases in order to understand if the whole design makes sense.

The most risky part in hasty reviews is that it is very easy to spot simple mistakes. But it is almost impossible to see if something elementary is missing. If a task flow of making phone calls doesn’t provide the way to save the number of an unanswered call for later use, it is not an acceptable design. To spot that, you need to spend a fair amount of quality time with the design and the background documentation. If you don’t spot the omissions and still approve the designs, you will be accountable for those later.

Reviews are probably unavoidable, but try to arrange them in the way that you truly can invest the time in them that you need. Otherwise, they are close to useless and potentially very risky.

Main image from http://www.flickr.com/photos/sunshinecity (c) Creative Commons

In the previous posts I’ve discussed issues about leading the design work itself. Now, let’s look at some things related to the design process. Processes are there to help you. The name “process” may sound like something that will limit your creativity, but in fact it does the opposite.

Milestones are one of your best friends. They force you and the whole team to make decisions, pull all the bits and pieces together into one coherent set. Typically there is a presentation to management and other reviewers at milestones. The desire for positive feedback and credit (or fear of public humiliation) typically gets the best out of designers. Necessity is the mother of invention. During presentations, especially with alert reviewers, you cannot hide deviations from original plans or design drivers, gaps in the design, slipping schedules, etc. It can be painful, but it’s good pain.

In addition to major milestones, internal design reviews and approvals are very important part of the design process. When you have one part of a design thoroughly reviewed and approved, you know that you have a solution that works. The worst thing in interaction design is that you don’t have any solution that works. It is a very unnerving feeling. You don’t really know if there is a good solution for the design challenge within the given requirements. But when you find one that works, even if it is not the most elegant solution of all, you can breathe. You have a fallback, whatever happens. This will free up your mental energy and creative juices again. You can reinvent the component and try something much more radical and potentially much better.

My recommendation is this: find these fallback solutions early. You will feel more confident while exploring something new. Communicate always only the approved solution outside the design team. Don’t start speculating about your more exploratory work or drafty ideas. This may cause confusion among the stakeholders: do these guys know what they are doing if they are changing the designs all the time? Show the new designs only when they are ready and internally approved. When you communicate the changes firmly and with confidence, people will happy to trust you for the next steps too.

Main image from http://www.flickr.com/photos/sunshinecity (c) Creative Commons

A large group of people cannot work on same design at the same time. A large design project must be split into meaningful and understandable chunks. In the beginning of a large project, when the basic ideas are still finding their shape, it may be difficult to isolate such chunks, because everything seems to be linked with everything else. Therefore, it’s easier if a small (and particularly competent) team of designers create the basic concept, the UI framework, first.

After that, it starts to be clearer what the main components of the concept are. In a mobile device those could include a home screen, a menu and application management, controlling settings, managing content and files, etc. Now you can assign a sub-team to work on each of these.

Every component has a purpose. There are a group of requirements that the component simply must fulfill. It must provide the functionality assigned to it. For example, you could set the expectation that a main menu of a mobile device can accommodate also shortcuts and web bookmarks. If at some point the designers of the main menu would conclude that including web bookmarks isn’t possible after all, you need to find some other component in the UI framework that will take on the responsibilities that this component is not fulfilling. Sometimes such knock-on effects will cause a long chain reaction of changing roles in different components, until you find a solution where all the requirements are satisfactorily met.

Understanding the big picture of a full UI concept is not easy. In particular it is almost impossible for other people outside the design team to understand the knock-on effects that changes will have. This will lead many frustrating but unavoidable discussions where reviewers, quite often in managerial roles, will request you to include X in your design just like a competitor Y just launched. You can’t start changing one part of the UI without changing many other parts too. It’s a puzzle, and all the pieces must fit.

Main image from http://www.flickr.com/photos/dps (c) Creative Commons

If you are lucky, you can be in charge of a design project where many fundamental areas of the UI will need to be changed compared to the old products. For example, in mobile devices or any embedded (non-PC) software, you may need to design both the hardware and software UI at the same time. In such projects you may be tempted to change everything.

However, think about the consumers or customers you are designing for. If they will see no familiarity in the product whatsoever, you need to practically educate them again to the new usage conventions, mental models, etc. With good design you can ease this threshold, but it still requires a lot from the users. Think of mobile phones: about three billion people in the world know how to switch a mobile phone on and off. It requires a long press of the power button. It is not particularly intuitive: you just need to know that a short press won’t be enough. Or about one billion people know that when their mobile phone is on, pressing briefly the power button will show the menu for ringing tone profiles. What if you would need to invest, say 1 € for each of the three billion users to re-educate them that power button will work differently? That would be a costly change in the UI!

So think of what your customers already know about your UI as an asset that you need to take care of. It’s not unlike the value associated with your brand. Use it, cash out by using the same conventions, but also carefully accumulate new funds by educating them about something new. Maybe you can share some of this with other companies in the same market, through standards or simply copying with pride.

Understanding your user base as an asset will make your work easier. It’s a relief that you don’t actually need to – or actually must not – redesign everything. Once again, select where you invest your time. Create radical innovation in the UIs in those areas of your product where it truly brings value. For a mobile phone company, for example, innovating extremely fluent UIs for novel social communication features makes a lot of sense, but redesigning the keypad layout probably doesn’t.

Remember, that you also don’t need to change everything in one go. It is much smarter to leave some for the next products. Introduce new things gradually. Plan the renewal using a roadmap. This will ensure that your users will grow with you.

In any larger design project, the design leader cannot be everywhere. There are so many managers to please, stakeholders to keep happy, designers to meet, usability tests to attend, and so many interesting blog posts to read. So admit it or not, you need to become very picky where to invest your time.

Based on the design driver discussion (see #1) you probably quite quickly form an opinion, which parts of your design are the most important ones that make it successful. They are usually those features or properties that product management or marketing can call “unique selling points”. Perhaps there are a few features that none of the competition has? It can also be qualitative properties, like the old and worn-out but nevertheless valid “ease-of-use”.

Naturally, you must spend your time in the areas that you want to make absolutely right. Which means that there will be many areas of design where you don’t spend your time on. The hardest part is this: you sometimes have to accept good enough or even mediocre designs (naturally, you can’t accept bad design). This will save your time for the important things. It will also provide an opportunity for some designers to do more independent work and for others to take responsibility. If you are part of a permanent team and you want to develop people as well, this gives them a good opportunity to grow as designers.