UX wireframing workshop for beginners

Quick guide to how to assembling a UX wireframing workshop curriculum taught in 2 days.

As a UX strategist and designer I run co-design workshops with multidisciplinary teams on a regular basis. I am used to facilitate different characters working together: clients and professionals of the digital product design cycle: designers, marketers, developers business analysts. Aligning participants with varying background knowledge, agendas and priorities bring a challenge on its own, but altogether is a very different ballgame to teaching the craft to complete newbies.

This is what I realized when I took up the challenge to teach a class to a group of Digital Experience Design MA students at Hyper Island in Amsterdam. The objective was to equip them with the tool of wireframing to enable them rapid prototype any idea — and I was given 2x4 hrs and a request for an introductory hands-on workshop.

We at Chain.Reaction often run design sprints based workshops with clients, a 3–6 day co-creating of new ideas, prototyping and testing them (a methodology Google Ventures have extensively used, to see more detail on the topic check also the guide of Richard Banfield, C.Todd Lombardo and Trace Wax published by O’Reilly), where the condensed time works in the advantage of coming out with quick variations and test results for a concept. My idea was to try to apply this methodology also in teaching given the strict timeframe and an intense workshop setting has its benefits when aiming for a “learning by doing” method. On thing to watch out for was the difference to client workshops: while with clients the purpose is the idea shaping, and the methodology is secondary for them, here the clients are students and the purpose is to give them a sneak peak into all tools and methodologies available.

Hyper Island is a school that prioritises the idea of giving their students an all round view on the subject matter and challenge them with real-life like projectwork. They bring industry experts on board to can give an actual insight into the reality of the job. Along these lines, I was given full freedom in picking how and what I wanted to teach : this meant I had to put together a curriculum, an agenda and a brief.

So, how to teach what you do? How to bring a group of early industry enthusiast to the other shore by giving them the necessary equipment to make it safely and be ready to get back on the seas again?

Here is what I did.

Facts & challenges

Diverse personas: Students came from various backgrounds. Some with little understanding of UX, others already having been worked on the field a little.

A very strict timeframe: Two half days were available to present basic content and facilitate a learning-by-doing workshop.

The agenda

The two half days, 2x 4 hours were broken down to quarters: 2 hours each.

• First quarter (2 hrs) / introduction Started with an insight into baselining the subject. Introduced the most important aspects of the subject, highlighting topics professionals have to think of when working on real assignments. Assembling the content, I recommend to look at UXPin’s summary of wireframing, a source I also relied on. After shaping it to my priorities and adding my own visual examples, here are the main topics I included:
• What it are wireframes used to communicate?
• Which stakeholders are involved in the process and what are they most interested in?
• Fidelity levels: pros and cons
• Tools: digital and non-digital, pros and cons
• Using patterns: platform specific ones, grids, platform-independent successful interaction models
• Wireframing principles

(Another source for of inspiration for the content was UX guru, Jeff Gotheff’s book on Lean UX.)

• Second quarter (2hrs) / workshop: ideating The section was dedicated to ideating and understand what to wireframe. The class of 23 was divided into groups of 3–4. Since they came from different backgrounds it was important to make sure that already existing UX knowledge is well distributed and we do not end up on one hand with teams who have never seen a single wireframe, and on the other with others who already are pros in it. A description of the user journey was handed over, the groups had to work on profiling personas based on their teammates (appointed by the brief):
• Third quarter (2 hrs) /workshop: actual wireframing Kicked off with a short introduction to the absolute basics of wireframing: think of information you do not think needs to be explained, including screen sizes, elements a wireframe have (eg.what is a placeholder), how to display a screenflow, or the difference between flowcharts, IA diagrams and screen layouts. Following was their turn to decide on the tool of their preference and warm up to it.
• Fourth quarter (2 hrs) / testing Broken down to two parts the last quarter is the icing on the cake: following a short introduction to testing (15–20 min) was followed by the testing itself (1,5 hrs) ending with presentations of results . The introduction covered basics of testing, with focus on what they can do easiest on the spot. It contained:
• a few methodologies — peaking into remote, on-site and face-to-face options; interviews vs observation, predesigned tests and surveys
• principles of testing (eg. don’t put answers into your subject’s mouth)
• preparation (what you really want to test and how)
• analysis (how to read results)

The second, doing part challenged them to prepare testing, cross-test between teams, document the results — and present them to the whole class.

The agenda was broken down to the smallest of intervals (10 min in my case) in order to keep the action on track — and by far the biggest challenge was to stay strict in order to get them through it.

The brief

If you want to give students a project, you will need a topic. Being a devoted advocate of context-driven design I meant to present the class a challenge that triggers them into coming up with context based answers. I created a brief where they could come to the conclusion themselves, that some services are best to be presented on a mobile phone while others are ideal on the desktop computer and so on. A brief is your weapon to show them how solutions can depend on where users are using them the most. To see different designs presented for the same interface can also be a lesson to learn, but I chose to focus on the context instead.

My brief presented a client, a new-age restaurant where the solution could tackle 3 different use cases: a sit-in, a to-go and delivery, giving the students a case where they can see themselves as potential users (and thus personas) and enough room to think, experiment and have fun.

Conclusions

My biggest challenge in preparing all this material was to decide where to start and where to end the introduction to the subject. So to all my heartache, here is all what was not told about the design process and how I overcome them missing:

..prior to wireframing

Design & Market Research, Strategy, Brainstorming, User Journey Building, Persona Building, Hypothesis writing

Wireframing is greatly embedded in the UX process. To get to build a wireframe you have to go through the steps of the fuzzy beginning: the discovery phase of market, user research, ideating, strategy building. You have to gain knowledge about your client, your target market, your future users and the business solutions built around similar ventures. You have to build your personas, assemble your user journey, draft your business canvas and have a rough idea about the tech solution to look into.

How to begin without completing these steps?

To jump this gun, the brief will be your best friend. Best case scenario: you can have the class visualize a user journey and let them point out the design opportunities. Second best case scenario is to present them with all material prepared allowing them to focus on the details while they still are provided with overview on the full product. Third case scenario: describe these aspects in the the best possible way and direct their attention to the underlined opportunities.

With personas there is more room: find a project where students can profile each other: the fun and self-interest is guaranteed.

…following wireframing

Testing A grey area. It is extremely hard to treat testing as a separate entity from wireframing: one isn’t really finalized before it is tested and iterated based on user feedback. Best is to plant the seed of testing and have them a quick run at it.

Interaction Design (IxD) The imagined product may use standard interaction patterns typical to the chosen tech and / or interface (eg. native UX patterns of iOS or Android devices), but ixd strategy could also require unique interactions as a key value to the product. In which case: you go straight to deeper levels of interaction design. A whole area again: treated as a separate entity.

User Interface Design (UI) Once wireframes are finalized comes in user interface design: finalizing the look and feel of the screens with colors, actual visuals and fixed pixel precise layouts. It is however, a flexible area as well: one can choose to be working with high fidelity wireframes from the start where UI kits are essential. Yet, try to remember, it is a wide field that comes with it’s own story and agenda worth to dedicate time to and study.