 Yeah, so the organizers of Meta Refresh told me to remain factual and not go all philosophical on you and my mother told me to speak slowly I had a number of facts here on my slide, so that part should be covered But I would be very happy if one of you would raise his hand if I start to speak too quickly My mother will love you for it So why is managing large-scale design projects? So incredibly difficult To understand this a little better. Let's first look at the ideal Pure design project. This would typically feature The Microsoft is kind of strange This would typically feature a designer thinking long and hard about the problem. He might ask some stakeholders He might interview some users He might consult a book or look at some reference sites He might fool around on dribble or something and then he will come up with an idea That solves the problem at hand. This will be implemented and bam, you have perfect user experience These projects are extremely rare. Take for example your portfolio site the epitome of a Single-made design project probably at one point you will show it to your mother and Your mother will have a very strong opinion about what you should show on your portfolio And you will likely incorporate some of your of her input you probably just forced to do so and So your portfolio site even that project that is purely yours will be ending up being 90 percent pure your design And 10 percent input Large-scale design projects are a completely different beast So there this gray matter That surrounds design grows to I would say roughly 70 percent and the pure design part is Only 30 percent remaining I call this gray matter Somehow designed to because if you are managing large-scale design projects and don't get this part, right? Your design project will fail. So it's inevitably be a part of the design process An example Most of you probably know the design language metro developed by Microsoft. It's been 15 years in the making or more than 15 years It's a truly modern design language. This design language that has allowed Touch interactions or that dealt with different screen sizes long before Steve shops allowed Apple to even think about the iPhone it is a truly forceful modern design language, however when Metro was integrated into the first major desktop product of Microsoft in the Windows 8. It was a complete failure When you installed Windows 8 as a better version of pace PC you immediately saw that something was wrong You were confronted with a touch interface That you could not touch because your typical PC screen was not touchable. I Can only match in what happened inside Microsoft Maybe it was a sales guy who said well people are used to buying new PCs when the new OS from Microsoft comes out Maybe it was a marketing guy who said Touch is so cool. We just have to do it. Maybe it was one of the futurists who said by the time we bring Windows 8 out Everybody will have touch anyway, but it was obviously a design decision that was not Was not taken inside the metro framework of thinking it was the design decision that was taken somewhere in this gray matter inside Microsoft in the making process of Windows 8 Another example Community also from the desktop is the introduction of unity desktop on onto Nazi normal when it first came out There was huge huge outrage in the geek community using Ubuntu I mean geeks using Ubuntu always were kind of uncomfortable with the fact that their system could have a graphical user interface and Maybe just unity brought this back to their minds Maybe there were some errors in unity and some omissions Maybe it used a little bit more system load What is interesting here is that the critique and the input came from outside of the knowable Universe of the people who actually took all the decisions to make to integrate unity with with Ubuntu on Latin Arbol It's also interesting that the community and the Ubuntu Committees managed to react to this and that Meanwhile with the current versions of Ubuntu that the unity has reached quite a good adoption So a more systematic way to look at this If you go inside a very large company, you will see different kinds of people defending different interests You will have technology people talking about functionality They are thinking about feasibility Compatibility and so on you will have business people reasoning about cost profitability You might have the designers coming in thinking about structure and usability and you also have the user as a stakeholder taking his part in this experience at least later on All of these stakeholders are completely right in defending their position You often hear designers say oh those damn tech guys They just can't implement what I designed or oh the marketing guy always forces me to add some balance to the interface This this is the wrong position to take it's the The task of the designer in a large-scale design project to manage all these stakeholders and to find the best Possible compromise he cannot exclude any of them because in the end Inevitably the project will fail and somebody will force you to make a touch interface on a piece without the touch screen Another way of looking at it is by design awareness When we enter large companies we usually find all levels of design awareness throughout the project stakeholders The lowest level we encounter is what I call magical thinking it's from Ethnology as a term and it's the kind of people who believe that we as designers can add some magic to the end of the process of Designing a product of or of doing a product and make the product wonderful and make it a good experience So we are kind of shamans or the musicians or those people who do the things nobody understands and make the things awesome this is a very difficult stakeholder to deal with because it's It's it's you have to educate him from the ground up and that's that's really really difficult to do because it's worlds that collide A level that we can perfectly work with is a certain kind of sensitivity a certain kind of knowledge what design can do and what he can't do and what it is about Of course, it's always wonderful for us to work with somebody who has true design knowledge as it happens when Companies have internal design teams or when we work with other agencies. That's the best level we can reach All these people again are completely right It is completely reasonable that there are stakeholders inside the company who do not know anything about the design and think We are like artists or something. It's completely reasonable and we have to take all these people seriously So how do we approach this kind of project? we try as mindset to approach large-scale design project through understanding and through understanding the very specifics of each project So as a mindset we tend to favor human interaction over certain processes and over certain tools That will maybe disappoint some of you who would have expected that I will deliver kind of an applicable method here This is not possible in this kind of project these projects are gigantic and by the sheer size each of them is completely unique So we have to interact with people as much as possible to understand the process in its entirety We tend to trust our experts much more than the sir the current Usual methodology and we try not to follow the canon too much of course in some details It's always helpful to to have conventions, but we tend to value the judgment of our experts Regarding the unique project and we favor qualitative understanding over quantitative analysis Simply for the reason that quantitative analysis needs a lot of previous knowledge to be done correctly We also only have a loose back of kind of modules that we put together in a project So it's not a waterfall model or it's not a full a method We always follow in the same way. It's a bag of modules that I will now describe Context analysis that has been said here before and it's evident for most people doing design work design It's not about creating a beautiful surface. It's about understanding the machine below And about giving this thing the best possible front-end expression in the interest of the user So our goal when we do context analysis is to reach an in-depth understanding of the project context This is something that reaches further and wider and deeper than any of you would probably assume We ask an enormous amount of questions and we ask an enormous amount of people and we often get the question Why the hell do you want to know this? But at one point in the project people will realize that there was a good reason for us doing all these things We never know where the big idea will pop up or where the constraint will be that will limit an entire part of the project We have to understand everything and we have to find every stakeholder possible I have seen projects fail because one single stakeholder was forgotten in the project process But this guy was super powerful and he pushed all his ideas into the project Really near the goal line and the project came out completely Scoot it's very important to contact all the people if a company tells us don't interview that guy He he doesn't have an opinion on this or this guy is going to be fired anyway So you shouldn't talk with him. That's exactly the people you want to speak to Projects goals often are communicated to us beforehand, of course You get the briefing it's set in the offering we write it's agreed upon But there are always also covered goals of a project and then there are always also hidden Expectations towards a project we want to find these out to a good way is to sit in people with people in a room and ask them What do you think? Can we really achieve in this project? Our method is really very simple in this in this part. We are asking we are listening We are reading we try to find for example analysis that exists inside these companies there have been previous projects It's incredible how many projects we start only to discover that there have been three to four failed Projects before that try to achieve the same that there have been three to four agencies trying to get the design right One of the most important things we do is that we study all these projects in detail and try to understand Why they failed why they didn't fail and we digest a lot in this in this term Based on on this early phase we do not produce much output we were always kind of afraid that People might get angry at us that these follow up 30% of their project budget and just kind of give them a measly list of questions at the end, but It works inevitably because one Additional thing that is generated in this understanding process is that people start to love the work we do and this happens because Inside very large company. There is a dire lack of open ears Very many people are just working in various situations and having trouble all day And they're trying to suggest improvements and they are simply not listen to and having somebody coming in and Speak with them and listen to them and occasionally giving a suggestion or just suggest That he's taking this seriously is something like a corporate Psychotherapy and it makes people love the work we do This is a typical array of questions We would ask we have large document with hundreds of questions like this You would ask business questions about target markets about competitors. We would also ask about processes I will have an example on this later on We will of course ask about technologies that they're in use about how they can be abandoned Whether new technologies could be introduced or not We are asking about design what design has to achieve and we are trying to find more out about usage For example, when does the user use this product or how is this product in a B2B context integrated into the users processes on his side But we then output is not just questions. It's a list of issues and proposed solutions This is very close to what the scientist does at the beginning of his research He writes a hypothesis Thinking saying with the current knowledge I have about this field the following is probably right and the following is probably wrong And in the subsequent process, he will try to prove whether he was right in the beginning or not That's how scientific exploration for example in social sciences work Here is a typical example of an issue we encountered in a project. We did a website design for the Freitag bag company It's a Swiss company. That's by now known more or less worldwide. They make back Out of used truck Turpolins so the result of this is that every single bag is unique There is not one Freitag bag in the system that looks exactly the same like the other one Even if they're made out of one single gray turpolin because of usage the backs will look very different What how they dealt with this before on their website is that they made a star Photographers image of one of the bags and use these kind of images as category images What happened for the user was terrible. He saw very beautiful category images Clicked on them and he couldn't buy the bag He saw because this has been sold a long time ago And he saw a list of very very shitty images that had been taken in the production process So the actual sale sold product looked much worse than the star product that existed on the home page We raised this as an issue and said this must change of course the Freitag bag company said we are producing Thousands of bags per day. We cannot ask a star photographer to photograph every single one of them We said no, it must there must be a solution because the user must be able to buy every single back He sees on the site there must be no placeholder bags in any case except maybe in marketing images or in style images or anything So what we did in the end is that they designed a Photography system into their production process that was able to produce this kind of high-level product photos These product photos are real photos done in the production process They had to design to custom-made photo stations that cost about a hundred thousand dollars I if I remember right per piece to put into the process to be quick enough to make a perfect photo of every bag The good thing about this is that they experienced really an increase of sales on the website of about 25 percent Which is massive by a simple interface change. There was no additional promotion or anything So they had a payback on this investment into their processes within mere weeks It was totally worth it But this is something we would not have discovered if you would not have dug very very deep in their processes We would simply have accepted that the bags that are on the product pages look shitty if you would have stayed on the surface a Second module we have its user research. I won't speak about this too long I mean most designers by now know that they should know their users It's astonishingly difficult still to argue for user research in large-scale projects because companies are somehow afraid of the user They are somehow constructed as reality shields Towards the outside they have layers and layers of people between the real executive people and the end clients Most inside people have never seen one of their clients one of their users so One of the important processes in user research is to mirror what we learn about the user back into the project to learn to Give people a vivid image of what the user is all about to give them Something real to argue about and we have design discussions and not just this kind of discussion Well, I don't like to be the button here on an e-commerce site You should have a clear and vivid image of the usage of the site So the user that's the main goal of user research for us besides of learning about him is To be positioned as his own advocate inside the project There's various ways of doing this. We can of course analyze artifacts very often There's a list of help desk mails. There are users communicating outside There are feedbacks and Twitter and Facebook we can ask him in classical user research Or we cannot give him a questionnaire if you have very close things to test. That's basically standard to use a research method Usually we end up with some kind of research report and it's very important to make this a true story We do not want to have a research report that is just a Boring kind of rundown or a lot of graphs about users We want to draw a picture. We want to tell a story because we want people to read it and to form an image in their mind We can make persona models. I will show one afterwards and we can hopefully build user awareness Here's an example. That's not done by a but it was done in a project where we worked also a Person from the US Tamara Adlin made this kind of persona models in a project for the World Intellectual Property Organization. That's a An organization that makes 1.2 billion of revenue online on their website But this has never had a clear picture about the people actually using the site So tomorrow made these nice little portraits of people. They were printed as a brochure in Corporate design and they were handed out to old stakeholders in the project and it was quite magical because in every design process where we were When an argument came up, we could discuss how would Patrick or how would Patricia Expect this to be how would she prioritize the homepage? How would she want to close a deal with us? So that was really interesting to see to enlighten the people about the people they're actually working with and it was enriching their their job I would think Another thing we have learned in these large concepts and that's That's something that is very similar to small projects even in the largest web design project The core is made up of maybe three to maybe two pages and maybe two or three user flows This is if you try to remember the websites you use most you are usually only using one or two pages Very often three very rarely more than that if you get that core concept, right? You have a strong fundament that you can build on after it So if you get that right you are then more or less out of the gray matter and you are able to just go and Work on the tricks of your trade for yourself in calm. So we set up this kind of Of core model and we try to get buying from high-level stakeholders for this kind of model It's very important to have to find these people and to convince them that for them. There's only like a Few things they have to get right that we don't have them in the project until the end Complaining about the color of buttons or something like this We want them to see what the big lines are and to say okay to this and to be convinced enough to support a project To its end and to leave us alone as experts afterwards as much as possible We do anything to show this core model We do not have a fixed way We do not always build the same prototype or always use the same wire framing tool We have had sketches. We have had physical models. We have paper. We have wire frames You have some kind of charts. Sometimes we just simply tell a story Whatever does the trick is right. That's something we heard just like 15 minutes ago or so We hopefully Achieve what we plan to in this in this phase then the project really comes calm me as the the main project manager in at I am Completely calm and I can sleep again. Once I know their stakeholder buy-in for the core concept Here are a few examples that simple line drawings that were done on a strategic workshop with this cooking provider This worked very well in this situation Here we analyze the structure of a new site to subsequently propose an adapted structure One thing we have learned in this project is that we have to stay in structure as long as possible And that we have to stay at the most abstract level as long as possible the longer we stay in structure The more we can rationally argue with people the more we go towards design the more we get into these taste Discussions where some people would like rose color buttons and others would like blue buttons We have to stay in in structure. That's where user experience is really designed in our opinion Here's another structural example That's a big news site in Switzerland that has to transition from a news approach to an entertainment approach over years or months We do not know yet So to the left you see orange fields that are more news oriented and then slowly the blue fields sneak in Which are more entertainment oriented That's that is something we use to convince the people that it's possible not to switch But to slowly transition this site into the entertainment field That's a mobile application sometimes with more details sometimes with less whatever did the trick in this particular situation That's a music platform here We had to do design in this early stage because the screen real estate is so constrained And this is so fixed towards a single viewport here for once working in design was the was the correct approach So there's really no rules here to what whatever does the rationally does the trick Here is something to show the difference between the wireframes we do and our surface design Here is a wireframe and that's the surface design an Uneducated user who probably not see the difference for us as designers, of course This is really beautiful and the wireframe I drew it is kind of shameful and There's a lot of there's a lot of stuff. That's not right here But we could probably have released this wireframe and the website would probably have worked So the surface designer truly does his job as somebody who adds The little thing that need that needs to be there to make it really beautiful. It's a little thing It's it's it's not chrome everywhere. It's not decorations everywhere, but it's of course a lot as As a creative act It's not I do not want to say that this is not an important job It is it is the thing that makes a difference in the end But it's he has to stick to this he has to understand a little bit of structure So not to destroy the structure from the wireframe and the wireframe of course has to understand About surface design so that he doesn't produce structures that cannot be designed without being changed later on we are Ever so often astonished how close these these kind of projects end up to be to the wireframe in the end We prototype mainly for one reason we prototype to clarify things that we are uncertain about We have the opinion that we can trust our experts to do a login form right if they have already done 20 login forms So we don't think that the prototype has to be complete We have the ability to design a lot of things Simply out of experience and we should trust that but we should also have like antennas up to feel when Things are probably not so According to the cannon or when we are not on our turf that's when you build a prototype and they're like in The core concept used a method that is appropriate to test this thing or thing for example once we had a model where we Wanted to make different panels that split into each other in a way We had never seen before on any other side that has obviously never been tested So we made a model with these panels sliding into each other based on Chava script But the actual panel content was simply a screenshot because the only thing we wanted to test was this lighting mechanism and see whether That's lighting mechanism could actually work Another goal that we might have when prototyping is to show an image that is slightly more ideal than what can usually be achieved That's in large in large context That's often a problem you have to compromise so long that the end product is a little bit unsatisfactory From the point of view from the main stakeholders and exit to this is to show a Wireframe or a prototype that would show how it could look like in two years It's it's a delicate balance to be still somewhat realistic and to draw an image for of the future And we can of course use prototypes to do first user tests Web development is the thing we use here and of course also prototyping software wireframe software like a cure for example We sometimes have a refined concept after that sometimes you have what I call a future beacon like Something that shines in the project and then kind we pulled out Ever so often during implementation to show hey, that's the benchmark. We initially said maybe we should aim to go there a little more Here's an example again from the Freitag back company project We had a way of cutting up the website that was relatively novel back then I will come to this at the end of the presentation once more and the only thing we were uncertain about is whether That model could accommodate all types of content that were needed on the Freitag website. So we bought we Drew a model of these content arrangements without any actual content We just work with content names, but in these content names You are very precise they were based on an Excel sheet and the little piece of software that translated this into a scheme and These this Excel sheet was complete. So it contained all types of content that was needed on this global site Here's a navigation. We are just have just done the navigation and nothing else no pages below It was enough to test whether user could find his way through the application here we convinced a two billion dollar holding company to present itself on one single page and that was kind of daring because That didn't exist in that for me there before so there was no real other way than just to design the entire page So our prototype in this case was the good old Photoshop file that we could show to the owner of the company and tell him or Ask him whether he would think that this is a correct representation of his company. I Don't have that much to say about implementation. That's the last point. I'm coming to The reason is that the projects we work in are usually so large that there are huge Implementation teams on the client side and we as a relatively small agency of only 15 people adapt to these implementation processes There are of course some things we try to do during this process one thing is we try of course to ship that product we ideally want and Another thing is we try to stay in there as long as possible to always work on that balance between the compromises We inevitably have to take during implementation and the original idea We try to hang in those projects as long and possible and not just hand every everything over To to the implementation team and see things break later on So that's one thing we have some kind some things learned and one thing is in implementation We should not go to atomic when describing the minimal design unit So we are working on modules. We call them containers that we ship to the implementation team We are sometimes in some circumstances in more interactive interfaces working with user path there is a huge discussion going on now about whether design could be atomic and whether we could just ship descriptions of h1 and of p's and of Form fields we have learned that this is not something that will be understood on client side This leads to a very detailed specification that will not be read that will not be Implemented correctly and the user let's face it He still sees a page in one way or another or at least he sees one functional container So we have to stay on a level that is still kind of reasonable for this kind of project Another question we often encounter in larger projects is can we just kind of improve what we have a little bit? It's very difficult. There's various benchmarks for for for whether a project can be improved or whether it has to be redone from scratch one benchmark we can apply it's just as a tip is that we are looking for consistency if Design ownership in a project has been lost a long time ago usually consistency was also lost somewhere along the way and Things will look completely different on from one page to the other and it will be very hard to improve such a project on the surface because there are always deep structural implications if you have lost consistency But if sometimes we encounter interfaces that are but ugly But that had some kind of design ownership going on through over years And they might be ugly but completely consistent and there we can really retouch things So consistency in design and I showed her when I saw the two Facebook pages just about a half an hour ago This gives user an extremely bad feeling to have a page a that looks in this way and the page B That looks in another way. It's something we should try to avoid so the key takeaways For managing large-scale design projects is We should listen in the beginning. We should deeper and broader than anybody would expect We should try to foster true Understanding for what we are doing inside the project. We should be real missionaries in these projects inside the companies We should try to catch everybody who could be of significance to the project We should try to nail a core and win a true strong support for that and We should then it's a due diligence on part of the designer also We should test what we are uncertain about you should test it in prototypes We should test it with users. We should then go to implementation and we should implement modules and flows not pages We maybe hear this sounds a little bit like a waterfall process And in a way there are aspects of this because large companies don't lend themselves to very iterative processes Unfortunately, but by making kind of the head of the waterfall source very narrow the the core will be small the prototype will be small we Reallocate a lot into the implementation process and there we have a chance to start over and over again With each aspect we have to design the implementation Yeah, so that was more or less it. I'm Chris Lusche from information architects. We are a small company based in Zurich in Tokyo with 15 employees We are working in very large design projects usually a million upwards. It's not our money So I'm not rich yet. Unfortunately, but it's a big Responsibility to invest in interfaces of that size. I am the co-founder of a platform based here in Bangalore and Venture funded by 500 startups in San Francisco. It's called cucumber town. It's a cooking platform which is releasing a mobile app on Launch.co on the 24th to 26th of February So if you're interested in cooking you might want to follow that Please contact me under the addresses I give below see at IA.net or you can simply follow me on Twitter You can chat me up here at the conference. I'll be hanging around tomorrow And I hope I didn't bore you that much I think a lot of you people have rather smaller projects and don't work in big big huge companies Be happy about that I'm happy. I'm just a guest there Question for you How much did the domain name cost? It's only two letters It costs like a small car. We negotiated over two and a half years and Our name information architects is very complicated and it generated a lot of sales problems And the older the company got the more we understood that this kind of little bit of bling is necessary We now have a large meeting room with glass walls and we have a small URL and we have stationery and these things Make it easier for us to be respected in large companies and it makes it easier to us To sell projects we we try to keep everything at the lower end But we have learned that a little bit of fling can can be really really substantial important for projects in this So the other thing I wanted to ask you about you know when you're talking about mockups The mockups you were showing were really low-fi not even outlines just color blocks So could you tell us a little bit more about that? You know, I mean what you seem to have done is saying that you're allocated a part of the screen for a certain kind of activity Without even trying to describe what it looks like if you look at something like balsa make which describes itself as being a very low design process Yours is even lower And you seem to think that's actually a great thing. So I just wanted to ask it again and say What would you say about your process versus something like what balsa make mockups prescribes? I mean we do those two it depends really very much on the process or and on the project itself Is it really important to show every detail to get the true understanding of the core concept? Then we show that I showed the Exceptions here also because I wanted to show that it can be done like this also But there are of course projects very after on Hundreds and hundreds of pages in very detailed wireframes. We had the project where we did a security monitoring software for a global company that monitors the security infrastructure of 240 global concerns So they monitor security infrastructure of the likes like IBM or Accenture or the Red Cross and of course in such an interface every single detail element has to be perfectly, right? There's no way you can just make a screenshot of a server page and say that's that's the future server page You have to discuss every single element that is displayed on there and of course that Necessity say that The the creation of a very very large wireframe which we moved in the implementation Process not in the prototyping not in the core concept process the core concept was lightweight You will have a very quick project over stretch if you go too broad in the core concept And if you start presenting detailed wireframes, for example to a board of a large company these people will Want to comment they are very opinionated and it's their job to comment on everything they see So you wouldn't we say you wouldn't wake up sleeping dogs So you wouldn't want to do to confront them with a button button locations or button colors It is sort of reminds me of the Talk somebody had you know we're looking at this triangle and rotating it to get details and opinions about which angle of triangle looks better I don't who was that present in it Raj Gopal. Yeah, so I guess that validates what Raj Gopal was saying You you mean that we are following the opposite of a lean approach kind of Yeah, that is by bio in a way just it is just rationalized by the fact that we work with companies that That cannot do lean approaches. So if you have a world intellectual property organization, for example They have every country in the world as a stakeholder and they have 1.2 billion revenue flowing through their site Yearly so that's that's such a massive Institution you you cannot go lean there We have now in Switzerland a banking project that is developed in an eight-child manner where the entire discovery and prototyping phase took about 20% of the overall project budget and the whole implementation where everything is really nailed down is 80% So and these 80% are really really fast-moving and they are they are really kind of lean as lean can be when you Discover when you deploy an interface for a hundred banks So it's kind of defined by the projects we have we try to to get new methods and new ways of thinking into this But we have seen projects fail because for example somebody tried to impose a child on an established Entrenched IT team. There are very often very entrenched settings in these in these companies and we have to negotiate I'm I'm quite old by now. So this kind of playing chess is fun for me But it's it's some people would say it's tedious I'm not yet fully used to the Indian English. So please speak as slowly as you can So based on the talk right now What we've seen is that I focus a lot on the big picture But based on your work with I writer we do know that you do spend a lot of time on details also and Can you talk a little more about? What you do when you try and work on my new details? How do you decide what to do? And so you mean whether we are part of the big picture or what what part of the So all the projects that you talked about now tend to focus on the slightly larger picture Mm-hmm quite a lot of your work in terms of your products Frankly involves going into very minor details. Yeah, how do you work that out? How do you make those choices? Yeah, I mean there's at one point There's kind of a churning process where you just work the project down and luckily we have people who love doing this Kind of like librarians work. I will call it because they for them It's their it's their kind of profession to do that I'm of course more the big picture guy I go home and sleep when the when the prototype is is approved more or less But the overall what we try to do as a company is we try to to push the limits in Direction of usability as far as we can go without breaking the project It's very very difficult to judge what can be achieved in a project in a large company and what can't be achieved And finding this kind of compromises is is the business We are really in finding this very special solution for a very special problem that can just be implemented That is just to the to the limit of the feasibility. It's not it's not a startup approach We have this brilliant idea and we will execute on it. It's like it's like an ego. It's more diplomatics It's more negotiation. It's more chess playing That's that's where that's where we come in Yeah, so I have been using I a writer for quite some time and I'm really curious to know what was the design thinking behind that blue cursor I mean It has been kind of a USP of I a writer and I mean, it's really pleasing to you know, just see that cursor. So what was the You know basic thinking behind that why not black or gray or anything like that? I cannot tell it in in in little details because I was not present that at the moment By the way, I have just learned that Microsoft actually imitated that one in the in the writing mode of word. That was very flattering but the the idea was had to have a kind of a true writing machine that has one locus of attention and The cursor you usually see on max. It's just not it's not good enough as a locus of attention It's not attractive. It's not it's not enticing you to start writing So we force the interface to display this kind of blue cursor which took us weeks to develop actually because it's difficult to change a core component in your six or at least for us who are not really Positioned like this. Yeah, I a writer is kind of it's it's the contrary of our client projects in many senses So we love it for for exactly this there We can really play around and we we don't even ask the users because we want to have a project where we just say We have this great idea and we execute on it. It's a good balance to have this product Many people see say that being a product and and a consulting company doesn't work. That's in my opinion It's complete bullshit. It's a perfect balance once you have established Okay, I have a question about a Little internal to IA probably about your internal project. Do you have I'm sure you have design conflicts? Fixed in design opinion. How do you resolve that? Yeah, we have an internal culture of saying that that no concept belongs to anybody So we had people that who said but I had the original idea for this project or something And we actually fired them when you couldn't teach them to to stop doing that because it's it's not productive It's as soon as you develop ownership you develop a lot for your own idea and you develop too much love And you're not open to negotiation and to rational argumentation So we tried to to disembodied the the idea part and the design part from one single person That's that's how we avoid this kind of complex and it works Extremely well it has taken a long long time to build this kind of trust because you give up your your very beautiful idea And you're not even sure whether you can mention it in the portfolio and everything But at one point you discover that it's it's much more invigorating to to create something that is truly more because it's a true fusion Of all the things so very often when we start a project There's a huge number of people sitting together It's somebody who is towards the implementation ended somebody who is on the front end It's somebody from project. It's somebody from structure and usually somebody comes up with the real solution Sometimes it's designed. Sometimes it's an implementation idea and then we run from there And we forget about who had the original idea and try to improve another thing about this is we throw away a Tremendous amount of work. That's the other thing people have to learn at our company If they are too attached to something they did and cannot throw it away when there's a better idea around They will also get in trouble with us and we will really try to educate them on that We are completely ruthless and behind every concept we did there are probably five or six that we discarded were back in Thanks, I Have a question Chris. Mm-hmm. So you have offices in Tokyo and in Zurich How do you balance or how do you how do the different visual cultures and the visual styles of Switzerland and Japan? How do those influence your client work? Do they influence your client work in the first place? Does it vary from geography? Could you talk a little bit about that? Yeah, it's kind of a strategy of us to to remain international It's it's a big trouble We are now mainly based in Zurich because Oliver Reichenstein moved there and we have the biggest office there so it's kind of there it's become the clear head before it was split between me being in Zurich and Oliver in Tokyo and Being based in Zurich. It's extremely difficult to remain international simply by the fact that daily rates in Zurich are probably the highest I would say probably in the world So it is very difficult to get outside business either you have to position yourself so high That you can sell whatever price you want. There are these kind of projects people who are used to employing Accenture they just smile when we tell them our daily rate So that's in any country of the world more or less or you have to discount in countries You have to strategically discount. We have discounted rates for European countries, for example That that that are at the brink of our profitability So this gives us on the client side This gives us a potential to be influenced by more than just a very narrow very Incessuous Swiss design scene the Swiss design scene is somebody you will know after a year of living there And people are not looking towards the outside They are looking towards what the competing agency is doing and that's what we do not want to do and Tokyo is part of exactly this I mean the web design culture. This was surprised some is is is terrible in Japan Japanese websites are a complete mess. There is just simply no real design happening there or when it's happening It's based on this old idea of optimal use of screen real estate So you will see very very tiny phones and you will see very very many boxes We will see all the bang and all the flashes all the stuff you you might remember from the end of the 90s Beginning of 2000 that you don't want to see anymore There's a there's an inspirational layer in Japanese aesthetics and Japanese design that we of course try to take on And we try to find people there who have the ability to To bring that into our company, but essentially the Japanese people come From their higher cultural aesthetics not from a Japanese web design perspective So they come and learn about Swiss web design as people who know Japanese aesthetics They are not learning about They are not teaching us anything about Japanese web design because we wouldn't want to float it float this into our projects Hey, there was somebody up there just one here so You were speaking about really large design projects and also agile right and you even touched upon banking as one of those things that You worked on so my question is like how far ahead of the actual development teams Are you people designing and since you're working in an agile environment? How often do you go back to revisit all of these? Designs that have been previously done as and when development takes it up and And it's also that you didn't understand the second one, but maybe you can I can answer the first one and you repeat the second one the How far ahead we are usually the core concept is and as I said It's usually maybe 20% of the overall project budget or if there's a large project encompassing implementation It's usually developed ahead of any implementation efforts But of course not ahead of any planning in implementation because you have to know whether this comp this broad concept is that Implementable in any way, so it's planned together with the implementation teams, but it's designed Ahead we have entered scrum processes with large teams several times and there we have learned that the best is That the designers are working more or less two sprints ahead of the implementation people so that when there are Sprint planning for example where people discuss about the features They are going to program in the following one or two weeks depending on sprint length We already have answers for them So we are trying to be ahead but not too much ahead because we were too much ahead We would lose this iterative approach We would lose the ability to learn from the development of the project We would lose the ability to keep consistency over the old overall in the project So we try to be a little bit ahead, but not too much in in implementation And we try to do the core concept usually before implementation even starts sometimes we prototype together with our clients That also happens for example, and you you can ask the second questions. I simply didn't get it. No, I think that answers Okay Anybody else so after you Did you take sign off from the client by showing those wireframes? Then did you go for full design? Yeah, it's it's we never we don't always reach sign off and when we reach sign off it's not always valid because These projects are usually strategic for the company and there's a tendency of losing strategic Support in in in large corporate context So there's a tendency of that there are poor discussions for example where there's where opinions change about companies So we can't lose it. So For us, it's more important to build a certain social tie to to the decision makers and to build a certain level of Understanding so that they understand why things have to be done like that And if they change their opinion, they at least have to argue towards us what needs changing That's why we try to keep the project as narrow as possible to still be able to change We have seen projects changing in their course and not failing We have seen some changing and failing. It's possible Another question the latest trend is to Design So start designing in browser directly rather than using Photoshop So what is your opinion on that? Are you mean which tools we used to design in? Oh Yes, I think what he's asking is a lot of people recommend designing directly in the browser instead of making prototypes Yeah That honestly because we are so structural in our thinking we have had some time to learn the power of this Because we always thought like the browser is more towards the the front end It's more towards the design part. We were being kind of naive in this regard and it was to do to draw Structures and then do implementation. We have especially one employee who kind of lives in the browser and who did such compelling examples that Particular aspects of concepts can only be done in in the in code in the browser that we are moving more and more there But there's still that's kind of like a weakness maybe of the texture We are in like companies don't like this kind of approach. They are not able to finance it They are not able to incorporate it or see it as an investment And maybe we are also a little bit on too much on the structural side to believe on that The danger of designing in the browser in my opinion is that you get too hung up in these little gimmicky things that you can do in browser Like optimizing transitions and everything and as you heard in the talk before the site should work without any Special bling it should like be a readable well-structured site if you just look at the HTML That's that's something I would I don't want to start the fight from before again But that's something I would subscribe to and that's kind of opposite to designing in the browser But because what happens if you design in the browser is people will download bootstrap Or I don't know what and we'll make this beautiful prototype that is a heap of technology and they will end up with Effect they can only do with that heap of technology and that's not how we think we think the true strength is in the structure It's in the concept So I mean if you want if I had to add to that the nice thing about designing in the browser is You get interactivity which you do not get on paper on paper You have to point out and say from here the user is going to go there and you need to do this all over again Every time you explain it whereas something built in the browser the interactivity is part of the medium That's it as you pointed out You get so caught up in it that you forget about everything else that's involved Definitely that's especially for example for user tests or so so before we started designing in the browser We had tendency to just simply implement processes in the browser to to test them for example That's obviously conscious that the web is a touchable interactive medium And it's not appropriate to to do more than a rough outline in in a static way It's it's good to do a roll outline in a static way because if you can't do that It's like if you can't explain an idea. It's probably not good idea So you should be able to explain it in a static way But you should be able to move to to the true nature of the web which is interactivity and is Software in a way Quite quickly. That's that's right. Yeah, it's it's just it's difficult to convey But we try to keep this early stage of the process relatively lightweight and relatively narrow So everything gets relegated into the implementation part This sometimes costs us business because sometimes companies to say well your concept is so good But we just take it and implement the rest from there on and we have a hard time arguing that it's nice to have a Surround during a big part of the project to Yeah, that's about it right nobody else. Yes. Thank you. It was very inspiring being here