Design - not the drawing type

After coming back from the Christmas break, I started the design phase of the project. Actually most of the times I think, there is a bit of a mystery and magic around transforming user research data into usable designs. My hand wanted to grab a pen a draw boxes on paper, thinking of zillions of ideas and features which would help people do things better. But again, my brain disagreed and luckily managed to hold this back, as I felt that I am jumping ahead too quickly, cutting corners.

The first thing I needed to do was to get all the things which I have learnt out of my head. The great people at Head London design agency helped me a lot in this, and together we found an easy and understandable process to start shaping understanding into useful solutions. As a first step we wrote up all of the key findings on post-its and prioritised them on a huge wall. An example of such a post-it would be: “The large group of students have problems accessing required readings”. This was an extremely useful activity, which forced me to spell out findings and making sure that I can communicate those to people outside of the project. The next step wast to formulate design goals, based on the prioritised findings. This is actually a hard task to do, since a lot of the times, people would naturally formulate “pseudo” design goals which are actually not design goals at all, but rather an attribute of the system we are trying to create. Very useful to understand the difference, and being able to formulate unique and relevant design problems is crucial. We ended up with 5-6 very good design goals like “How do we help avoid book shortages?”, which served as a basis for the next activity: ideation.

The reason behind clear design problems is not only being able to articulate and communicate. They serve as starting points and triggers for ideas, which tries to solve a given design problem. The way we approached was to have a large number of ideas solving each of the design problems, in the form of user journeys, which had to contain an actor, an object and a goal. Expressing ideas this way, almost like simple cartoon strips, encourages designers to think of user flows rather than individual features or functionality. Features are assembled by disseminating, combining and evaluating all these flows. Once features are there, through a prioritisation activity we can start drawing a bird’s eye view of the system, and mapping out how different features connect, to best support the design goals and the user journeys. This is when my brain is comfortable with drawing, and this is where finally sketching of individula screens can begin.

Another interesting thing which I managed to get a better understanding in with the help of Head, is the ability to communicate design findings. They showed me a number of different ways to visualise complex relations and complex data. Very useful. I realise that without pictures this is dry and unimpressive, but please bear with me, I will make all this more visual once the design phase is completed and the final artefacts are made which is very close now.