Sketchnoting as a Talk Review Tool

Oct
13
2013

Two models of design lead innovation - Steve Baty

I have been sketchnoting for a while now and I do find it a very easy way to personally document and retain information.

Over this period of time I have sketchnoted a good deal of technical and non-technical talks sometimes about subjects that I didn’t have a full understanding of.

The other day I was reviewing my sketchnotes, musing over this talk or that event,  and I noticed something, a pattern within the sketchnotes.

Due to the nature of sketchnoting, I do find that I will often get into a flow, listening to the speaker’s voice, and occasionally glancing at the screen. It really is a case of loosing track of time, as I become completely focused on the drawing and the presentation.  In a way I’m almost channelling the talk into the sketchnote.

Patterns Appear

The patterns related to the level of maturity of the talk and the way it was presented.

The collaborative process - Domenico Bartolo

The more mature talks will often have all the problems worked out and run smoothly. A mature talk doesn’t mean that it has been presented a lot either.  I have sketchnoted talked that just worked on their first presentation.  However you could tell there was a degree of maturity in the presentation development.

The better the talk, the more streamlined and well paced it is – hence the easier it becomes to sketchnote; as I tend to follow the logical rhythm of the talk itself.

Now I’m not going to point of cases where the speaker was poor at presentation or the talk just needed a little more work, as that would be unfair to the speakers concerned.  Most of the ones that were hard to sketchnote I have approached personally anyway.

Reading the Patterns

There is some commonality with the resultant sketchnotes and the delivery of the talk.

Better product definition with lean UX and design thinking - Jeff Gothelf

Generally if a talk is loaded with lots of good information in the beginning then this will be reflected in an overloaded first half of the sketch.

You want a sketchnote to be balanced and clearly highlighting the key points and representing the overall theme of the talk.

If the speaker is unclear about a point or seems to be muddled on the clarification of the talk sections or major concepts – then I find this is reflected in the sketchnote, topics will merge, concepts will in turn be indistinct.

Sure while I’m  sketchnoting I will try and pull out the relevant points and transcribe them, but sometimes it’s an uphill battle.

If the balance is out in the talk, for example, if the latter half is just a summary of the first half.  You are going to get a large graphic at some point, as I’ll end up with time to draw big picture; as I wait for new information or ideas to be presented.

If the talk presents as not having any real direction or flow to it, then the sketchnote will look the same. These talks can be frustrating to sketch, as you really have no idea where the speaker is going.

Angel Investing - Greg Riebe

I have had talks that by the 40 minute mark of a 45 minute talk the speaker was yet to reveal the overall theme of the presentation. Again this is reflected in the sketchnote as not having a clear theme.

For speakers if the sketchnote is balanced and all the major points are covered, that’s a good thing. If topics are merged or it’s not balanced then maybe something was a little off with that talk.    Think about this when you are looking over a sketchnote.

If you sketchnote have you seen this patterning occurring too?

Stepping Away from the Perth Accessibility Meetup

Jun
30
2013

shot of Coffee and a glass of water on a window sill

In April this year I stepped away from the Perth Accessibility Meetup group after having guided the group from it’s formation a few years ago.

Originally this group was a causal networking affair, allowing for web accessibility practitioners to meet and discuss all things involved with the inclusive and accessible design.

Now I feel I owe the community an explanation as to why I stepped down suddenly.

Getting to the Reasons

The Perth Accessibility Meetup wasn’t a difficult group to maintain, in it’s previous format, it was just a matter of promoting it a little, booking the venue and getting up early – okay this bit was hard.

In February and March I had just organized and run the first Perth Accessibility Camp.  Which, from feedback, seem to go very well, allowing a good deal of people to network with others who had the same issues.   Still it was tiring, and caused me a drop the ball on a few critical business opportunities.

Business wise I was finding that the demand for quality accessibility consulting was waning, despite a growing requirement from the market, but it wasn’t translating into sales.

As a primary breadwinner for my family this was not good.   The reasons why things were not working are numerous, most are better discussed over a beer, than here.

Frankly I didn’t have the time to focus on community volunteer work the group required to move forward.   This became very evident from the Accessibility Camp.

The main issue was also more one of basic business survival  was not being met, I was just too busy helping people with no return.

Time to Change

Also the group was generally stagnating, and not going anywhere, in fact the numbers were dropping.  I think the issue really was me.   So time for a change.

By sheer mistake, one morning I slept in and missed the month’s meetup completely, and you know what it felt good, like a burden had been lifted.

That said everything to me.  So I stepped away.

One thing I think the incoming team should be very aware of is rotating the presenters around.   Having one or two people presenting all the time can get very boring and a little self-promotional.

Leaving is Hard

You know I am sad about this, but I have to be a business realist, accessibility consultation wasn’t paying enough to be viable, without selling our house and moving into a cardboard box.

This doesn’t mean I’m going to stop waving the accessibility banner, yeah I’ll still be there if a client needs accessibility consulting.   It’s just I’m not going to be an active community component like I used to be.

I’ll leave the accessibility cause to my colleagues and inspirational community leaders such as Scott HollierRuth Ellison, Lisa Herrod, Derek Featherstone and Roger Hudson, they are just tireless in their commitment; when I grow up I want to have their energy.

Moving On

I guess I have also lost my faith in accessibility, particularly when locally in WA , we have a Government that are just paying lip service to WCAG 2 compliance at a senior management level.

For the immediate future I need to focus on Customer and User Experience consulting, as they do bring in money, and at least cover the basics like putting food on the table.

I maybe back; I have no idea when, only the future knows.

Thankyou people for indulging me, the ride was wonderful.

UI is not UX. Remember that!

Mar
27
2013

Barred Window - Old National Art Galley and Common Museum, Wellington NZ

It amazes me suddenly everyone is a UX designer, what next UX postal workers.

I suspect that most UX designers don’t really know what is involved with a real customer centric process.

When discussing User Experience with people that have only partly encountered the term, I unusually first clear up the  myth that User Experience (UX) is just the User Interface (UI).

Often they are surprised at the extent of UX Design and the degree of scientific rigor behind it.

Now it is good that the term UX is starting to mainstream and all sorts of people outside of the IT, marketing and communications industries are realizing its importance.

Still we need to remember why User Experience is not the User Interface:

  • User Experience is Wider in Scope.

    The User Experience covers a lot more than just the visual presentation layer.  It can be sound, information organization, behavioual response, environmental conditions, service presentation and so on.

  • User Interface is usually just Visual.

    The UI is just the visual design and the interface design. With maybe a little interaction design, but that is it.  It’s very easy to forget about the people aspect of this.

  • It’s more than Design Patterns.

    While design patterns help in the building of a UI. Understanding the behaviours around that pattern and the aspects of the micro interactions is important.

  • UI Rules are not critical.

    Often User Interfaces have rules or guidelines for use.  These are often seem as common solutions and are quoted in support of the UI solution.  This is a good starting point; however the UX context and customer behavior may take the final solution in a different direction.  More work that just applying the “rules” will be required.

The Stuff Before and After the UI

Around the development of any User Interface, ideally there should be a fair amount of UX techniques.

Be this from the initial problem verification, customer research and solution proposals, to the final iterative prototype development and validation.  As you can see there are a good deal of processes that can occur before the UI is even considered.

Process from problem validation to visual and interface design in an iterative loop

The UX process around the Interface Design

Sure usually a good UX professional can do the UI if required, however limiting their skill set to this alone would be a complete waste of a resource.

The External Lens View

We know we have a problem as UX design is invisible.

It’s not a thing you can point to and say – that is the UX design.  With UI design however, you can point and say – “see the sexy User Interface”.

From a external view point, outside of the industry, UX is this magical – almost snake oil like role, that is seen as a luxury item.

After all it doesn’t help in the delivery of the product or making people use it? Or does it?

It could be said that all UX people do is confirm issues, and direct others like developers and designers to the right solutions.   In reality does the role exist at all?

Ask most Project Managers, Team Coaches and Project Leads and they will tell you they aren’t really sure what UX people do. But they are sure that an existing team member can fill the role anyway.

Yes all this is all an education and justification issue, you would think after 10 years we would have nailed that one.

Muddying the Roles

There are a good number of Visual Designers and Front End Developers moving into roles as UX Designers, most by simply changing a position title.

I have no problem with this if a complete customer centric empathic UX Design, as detailed above, is being conducted.

However I have found time and time again this change is just a window dressing at best.

The reality is the only empathy that is expressed is in the statement – “I’m a user, therefore I understand user experience”.  Only a marginal consideration is given to the issues of the customer at all.

This leaves people such as myself with a fair degree of UX consulting experience, in a bind.  As now I’m just seen as a UI designer.

Others in the UX industry, have become more specific in defining what they do, morphing into Interaction Designers, Human Behaviour Consultants, Customer Research Analysts or just Experience Consultants.

This doesn’t help anyone in the long term, as now outside the UX industry is watered down and truly a bit muddy.

Supporting Skills of UX Design

You know in a way maybe UX Design doesn’t really exist. It’s just a term afterall to group together all our skills used to produce balanced solution.

When you’re building for a good UX design, you don’t really go out and apply your skills in UX design. You tend to instead use on of the following supporting techniques to bolster up the UX design solution in context of the overall process; of which the User Interface is just a component.

User Experience Supported by interaction design, usability,behavioural design, user research, content strategy, visual design, info architecture and interface design

Proceses supporting User Experience

Whether you are a recruiter, an agency director or a project manager; remember there is a distinct difference between a UX and UI designer. If you advertise for a hybrid I’m going to expect to see some skills cross over not just front-end designer skills.

Heretical Ideas – Abandon all the Pretty Reports

Nov
16
2012

Storyboard Production

A few years ago I proposed that we stop wireframing everything and that we do some sketches and then prototype.

I’m really glad the message has got out and people are considering that wireframing is just a transition to the prototyping.

However there is still a good number of issues when designing to support a good user experience that we need to get rid of.

We have become oppsessed with the artefact – the final report or diagram.  A good deal of resources is just wasted producing them.

Well I can tell you they are not important. We need to take a lean approach and stop producing them.

It’s not about the Results

These 400 page reports and pretty diagrams are the issue.

We have created a world where we have an excess of reporting. Where is it now expected that management will front up to the executive with an expensive looking report to show how “busy” they have been.

Partly this issue has it’s roots in our outdated concept that “more hours worked” = “greater productivity”. We now know that to be complete crap.

On most projects the UX is never really considered ideally, at some point there is always a compromise taken. This is usually due to lack of resources (budget).

Now what would happen if you could find, 10%, 15% or maybe 25% more budget for supporting a good UX, clearly you could use that extra budget on those techniques and methods you discounted to confirm you design or research.

What if doing all those pretty reports was taking 25% of the budget. Would you question why they are being done.

Consulting Reports

Now I get that from a consulting basis the big report or the pretty diagram is usually an end of line item, a solid deliverable for the client.   Something you get paid for. I live and work in this UX consulting world, so I get that.

I have to produced these reports or diagrams that very pretty and extremely over detailed, just so the client felt like they got their moneys worth. When in reality the money was spend on knowledge transfer previously with their team.

Also the reality of the matter is only the summary of the report is ever read.    

Maybe as consultants we need to be looking at producing a MVP in the form of the usual pretty report.

So why bother with the Artefacts of the Process?

If we took all the extra effort and redirected it back into the project surely that woud be of benefit.

The entire point of the final products, is really just to focus the team on the information or design and start a conversation or feedback.  The conversation can be from customers, stakeholders, product owners or colleagues.

Now if you are working solidly on a project, then you will be constantly sketching, researching or the like. 

Producing low-fi items, that can help serve as daily discussion points.  As opposed to the traditional “over the wall approach” when we hid ourselves away to produce wonderful shelfware reports.

It’s just a matter of the way we are working.

What if we just used those sketches, the workshop posters,  that review video of the testing session.  What if we kept the reporting artefacts to the core of the information with maybe a summary of findings.

It’s About the Discussion

It’s this discussion that is the important aspect, the information that comes out of this discussion: the requirements, issues, directions, possible solutions – these are the important aspects. Not the pretty outdated management reports.

To often it’s these comments or discussion points that are forgotten or put aside with our headlong obsession to produce 400 page reports on the matter.

We need to change the focus.

What better place than at the source.   Stop producing the shelfware and focus on greater productivity for the project overall. Get the team collaborating effectively.

Keep the outputs lean.  Generate the discussion and move the project forward.