Challenge  I work as a User Experience Designer at a large consulting corporation. One of our clients is a  gonvernmental facility responsible for pension here in Germany. The processes within that  organization are highly complex and grew over the last 30 or so years. We were tasked with  creating an application to let members of the call center (mid-level consultants) reply to  clients calling in more efficiently. The challenge was now to get an an understanding of the  processes in the institutions software overall as well as the special teams in the call center  (KKC). The existing applications of this organization (yes, there’s about 5 of them) are from  another generation, and every one serves a different purpose in keeping information on a  clients pension. So, besides assembling the requirements first, how do we get the employees  to specify their needs? We talked to some superiors first, but the requirements always  remained blurry. So we asked to have a workshop with the KKC team itself.    Selection & Application  When we thought about how to quickly get input and approval from the KKC team members  we came to the conclusion, that they would probably be overwhelmed by purely structural  diagrams and architecture graphics. Luckily I was partnered with a very competent architect  that knew her way around the systems. So we could extract the data fields from the systems  we thought to be useful to the team.    I opted for the additional tool of Visualization. It helps me understand the problem better  and I had good client feedback several times before, when going this way. Also, since this  problem was especially abstract and the KKC team members were surely not developers or  software architects, an „easy language“ could be helpful.  I took a glance at the corporate design and I made up a quick mockup of a web interface for  them to possibly use. The GUI (Graphical User Interface) layouts were without interaction,  really purely for them to grasp the level of readability and what information could be placed  where in what order. Think of a Logo in the upper corner and the right set of colors and  corresponding typography, mostly screen elements captured from the institutions website,  really.     In a workshop, we then were able to discuss the placement of information and data with  them from what we understood they meant. And as you can guess, we were wrong at  several opportunities. You have to know that the original „architecture“ was made by IT- People back and some three decades ago, growing with new precedences over time and  becoming ever more complex. So, we re-iterated the layouts according to input and in the  second workshop we were able to ask questions we didn’t even anticipate when we first  threw together our initial design. It took us three workshops in all to get from our intuition  and arrangements of certain items to a deeper understanding of what the items truly meant  and how they where related to each other.    Insight   Usually, in User Experience theory they tell you to start with Wireframe models, so  stakeholders are more free to provide feedback, because they are hesitant not to „destroy“  the design work. But we were very relaxed with them in the workshop and told them several  times that the screens provided where merely thought of as a basis for discussion and that  anything could be changed rather quickly.

And it worked very well. The call center team later told us, that they felt very well cared for  in their needs. This was apparently new to them. Also they mentioned that the Layouts  helped them a lot to relax and „get the idea“ rather than from the diagrams which tightened  them up beforehand. The information structure diagrams do have their place in this though.  They represented the reality, the „solid business“ aspect of the project, where the layouts in  contrast were far more accessible to them. Had we only presented those, the team might  have taken the compositions for too „playful“, probably.     Also, for a government institution, whose structures I knew nothing about in the first place,  we got to a good place in fairly short time. Involving only a fraction of cost compared to  other projects in that institution.    Approach  Only now I realize that this was my way to get stakeholder buy in all along. My background  enabled me to quickly imitate corporate designs and put a contextual frame around my  suggestive constructs to be able to discuss it more easily with stakeholders and clients, since  they could grasp where it was going. The design was just scaffolding and could be developed  later on, but the information and its position was easy to get a consensus for.  I think in this  graphical communication with stakeholders lies a tremendous power. Not just in terms of  on-screen designs. But also generally in creating visuals and hence give people the  opportunity to participate. Maybe not being in the middle of the design process in that exact  moment but to see the result, reflecting their input.


Challenge I work as a User Experience Designer at a large consulting corporation . One of our clients is a gonvernmental facility responsible for pension here in Germany . The processes within that organization are highly complex and grew over the last 30 or so years . We were tasked with creating an application to let members of the call center ( mid - level consultants ) reply to clients calling in more efficiently . The challenge was now to get an an understanding of the processes in the institutions software overall as well as the special teams in the call center ( KKC ) . The existing applications of this organization ( yes , there ’s about 5 of them ) are from another generation , and every one serves a different purpose in keeping information on a clients pension . So , besides assembling the requirements first , how do we get the employees to specify their needs ? We talked to some superiors first , but the requirements always remained blurry . So we asked to have a workshop with the KKC team itself . Selection & Application When we thought about how to quickly get input and approval from the KKC team members we came to the conclusion , that they would probably be overwhelmed by purely structural diagrams and architecture graphics . Luckily I was partnered with a very competent architect that knew her way around the systems . So we could extract the data fields from the systems we thought to be useful to the team . I opted for the additional tool of Visualization . It helps me understand the problem better and I had good client feedback several times before , when going this way . Also , since this problem was especially abstract and the KKC team members were surely not developers or software architects , an „ easy language “ could be helpful . I took a glance at the corporate design and I made up a quick mockup of a web interface for them to possibly use . The GUI ( Graphical User Interface ) layouts were without interaction , really purely for them to grasp the level of readability and what information could be placed where in what order . Think of a Logo in the upper corner and the right set of colors and corresponding typography , mostly screen elements captured from the institutions website , really . In a workshop , we then were able to discuss the placement of information and data with them from what we understood they meant . And as you can guess , we were wrong at several opportunities . You have to know that the original „ architecture “ was made by IT- People back and some three decades ago , growing with new precedences over time and becoming ever more complex . So , we re - iterated the layouts according to input and in the second workshop we were able to ask questions we did n’t even anticipate when we first threw together our initial design . It took us three workshops in all to get from our intuition and arrangements of certain items to a deeper understanding of what the items truly meant and how they where related to each other . Insight Usually , in User Experience theory they tell you to start with Wireframe models , so stakeholders are more free to provide feedback , because they are hesitant not to „ destroy “ the design work . But we were very relaxed with them in the workshop and told them several times that the screens provided where merely thought of as a basis for discussion and that anything could be changed rather quickly . And it worked very well . The call center team later told us , that they felt very well cared for in their needs . This was apparently new to them . Also they mentioned that the Layouts helped them a lot to relax and „ get the idea “ rather than from the diagrams which tightened them up beforehand . The information structure diagrams do have their place in this though . They represented the reality , the „ solid business “ aspect of the project , where the layouts in contrast were far more accessible to them . Had we only presented those , the team might have taken the compositions for too „ playful “ , probably . Also , for a government institution , whose structures I knew nothing about in the first place , we got to a good place in fairly short time . Involving only a fraction of cost compared to other projects in that institution . Approach Only now I realize that this was my way to get stakeholder buy in all along . My background enabled me to quickly imitate corporate designs and put a contextual frame around my suggestive constructs to be able to discuss it more easily with stakeholders and clients , since they could grasp where it was going . The design was just scaffolding and could be developed later on , but the information and its position was easy to get a consensus for . I think in this graphical communication with stakeholders lies a tremendous power . Not just in terms of on - screen designs . But also generally in creating visuals and hence give people the opportunity to participate . Maybe not being in the middle of the design process in that exact moment but to see the result , reflecting their input .