Category: User Experience

Systems, ecosystems and control (anything but the one stop shop)

~ mylesrun ~ Leave a comment

The ecosystem theme seems to be echoing around me at the moment. I realise that this is not a new theme but it has given me pause to think as it orbits. Some interesting remarks from contacts on LinkedIn in a recent discussion further added to the musings. What follows are some top of mind thoughts on the topic (for now…).

There is a powerful impulse at play in IT organisations I believe – it is the urge to tidy up the apparent mess of systems and technology tools at large in the business. As a senior IT stakeholder, there is cost, stress and error at every turn and greater control feels like an obvious response. It is one powerful reason to pursue the single system strategy or the dreaded ‘one-stop-shop’. Neither the “one ring to rule them all” or the “there can be only one” approaches have ended well, however. technology progress and development will inevitably add more ‘mess’.

There is a desire for parental control at play here, I further believe. A view that the best outcomes for users are those that are managed for them (with their best interests at heart, of course). Where there is a parent, there are children, however, and that is not the role a modern workforce really wants to play. (I sincerely doubt it was a satisfactory role for any workforce but has been the tradition nonetheless). As users, we approach the digital consumer landscape as agents of choice. Having that agency removed is a pain. It is a pretty drab reality that many organisations deny the use of consumer tools in the workplace to defend the apparent order of official systems and we step back in time as we pass through the revolving doors at reception.

The LMS is one of the worst offenders in the controlling parent role, replete with allocation, access control and approvals. There are even sanctions for poor behaviour: if you don’t eat your compliance greens, you can’t have your password pudding. This is not born from an atmosphere of trust and openness.

These are not the only reasons for the flourishing of the organisational ecosystem of tools and technologies but they are significant. The ability to swiftly offer a well designed tool focused on narrow and painful use cases is chipping away at the foundations of  traditional systems in all walks of professional life. It is frequently, if not always, quicker and cheaper to use a cloud based web service for work tasks. App store marketplaces have created a very effective environment for testing and developing useful tools. Most often the tools of our every day lives are our first choice in our work, having had their value tested and honed by literally millions of users and use cases. The fact that these tools are in different products and owned by different businesses is no real barrier to their utility in our private worlds, so what is the problem in the organisation context?

It is important to distinguish a true ecosystem of from a series of available tools. If an ecosystem is “a community of interacting organisms and their environment”, then there are, I suspect, few of them out there. There are plenty of organisations with multiple tools and technologies (a development to be embraced), the interaction criterion is more difficult to satisfy though. This does not devalue the utility of the tools but it might make the usability of the ecosystem weaker as data and content does not pass between products. It is likely that meaningful interaction between systems falls into the ‘big and difficult’ project bucket and is tackled less often as a result.

One of the great liberties of avoiding the one-stop-shop, is the freedom to test and add tools as a need arises or possible value is in sight. The recent arrival of many chatbot tools on the landscape is a case in point. There are plenty of authouring tools to create bots and messaging systems to release them into. A requirement to integrate them first is likely to break a business case to create a swift test.

There are two areas, however, where integrating tools to begin the creation of an ecosystem looks most valuable:

  1. Search and discovery: the ability to quickly and simply search for specific content, people and information that are relevant to your work. This requires some engineering and careful planning but technologies like Elasticsearch and erm, Google are very accomplished at this. Being able to search and browse across content portals, social media, LMS, third-party content services, intranet, document repositories and people directories adds huge value to the tools most organisations use.

    In fact, with good search, who needs a learning journey?.

  2. Data and analysis: being able to see what users do (and don’t do) across multiple technologies is enormously valuable. This can range from simple dashboard reporting of items such as content popularity, routes in and through content, patterns of heaviest users, frequency and depth etc. to more sophisticated analysis of the relationships of certain behaviours with business outcomes. The addition of non-learning data sources is very important here, although organisationally tricky in many cases.

    For those in the learning game, the LRS is an interesting development finally gaining some momentum. For those with broader concerns, many other data storage and retrieval solutions beckon. (Data Lakes have a poetic ring too).

Tackling these two (pretty hefty) challenges will offer an ecosystem owner, or those with ambitions for one, a good steer as to the potential value in integrating the tools and products into a user experience of some kind.

There are many other hypotheses forming in my mind to which I may return. For now though, the ecosystem approach is a definite step forward. Perhaps the greatest contribution made by this approach is offering control and choice (or greater control and choice) to users rather than requiring them to seek permission and approval. This is closer to our experience as consumers – we chose the tools we prefer, when and how to use them. Choice has become a foundational expectation of our digital experience and system owners should be very cautious about interrupting it.

 

Don’t leave digital transformation to IT (or learning technology teams)

~ mylesrun ~ 3 Comments

In a few weeks time, I will be hosting a panel session at Learning Live on the theme of digital transformation. It is, in various guises, a major theme of the event and a significant preoccupation of the LPI membership. Fortunately, I have a wise and esteemed panel to rely on for answers to “What you’ve always wanted to ask” about the topic.

In preparation I have been doing a little more deliberate reading around the many and varied themes. I cannot decide whether a focus on L&D will help the debate or hinder it? On the one hand, we can concentrate on topics closest to our work and our immediate priorities. On the other a, mistaken, belief that learning is a special case in the digital world leads to many misguided decisions. Specialist learning systems are a major reason why learning remains in a technology ghetto rather than a daily tool kit.

This post by Jeff Imelt, ex CEO of GE is a useful input. There are some helpful observations on leading and organising digital transition in here. Unsurprisingly, leadership clarity, trust and empowerment are crucial factors. As important, is the assertion that digital ultimately needs to be a part of everyone’s day job at some point. Whilst a specialist team may be prudent to gain momentum in the early days, everyone needs to make the change and adopt digital ways of working to sustain the changes. This is worthy of consideration for L&D folks. Many organisations have digital specialist managers and teams (often born from a learning technology background) but struggle to make the transition beyond that point. I would like to hear some views on that hypothesis in the session, from attendees in particular.

Imelt also asserts that digital change cannot be the preserve of the IT functions. In many ways these are outsourced technologies and activities which operate at too great a distance from the core business to generate valuable change. I really like this point. Too often digital is seen as the preserve of techies and systems folks, under-cooking the potential it can have and limiting the radical change needed. Technology as a function is often too far removed from decision making to create far-reaching changes.

In the L&D world, I suspect (and observe) that digital change is often handed off to learning technology teams. This limits the changes required – digital transformation is about people and how they work as much as it is about technology. In anxious organisations, there can be an insulation from digital because it is seen as a specialism of technologists. Successful change will not occur under these circumstances. I would also like to know wat people make of this observation. It has happened to me directly. As Director of Digital, I have been given responsibility for digital transformation with only technology levers on which to pull. The remainder of the department remained distant, labouring under the belief that ‘digital’ would be solved for them and launched at them. No. It didn’t work.

A related challenge to the preoccupation with IT lead implementation of digital change is the misplaced faith in systems implementation as a source of digital change. Fundamentally, the revolution of digital has been a product of the widespread adoption of digital ways of working. Inherent to these approaches is the ability to experiment and adjust to seek valuable solutions. Any transformation means the old rules no longer apply. Systems implementation, by definition, precludes experimentation and denies the arrival of unexpected value. The computer will say no.

ERP systems, of which the LMS is a prime example, will not deliver digital transformation for this reason. They will deliver efficiency, order and accuracy (hopefully) to established systems or in the embedding of new ones. This is not to be sniffed at, but is not transformative. User needs are rarely anywhere to be seen either.

Other digital tools are where signals of value can be found. As a rule of thumb, it is always best to look outside our own industries in seeking clues to make far-reaching changes. Social media, digital advertising and content publishing have some useful pointers to offer in designing a really helpful user experience. (They also have some useful lessons in questionable business ethics to look out for).

Plenty to chew on for that session at Learning Live then. What else?

 

Making a start on digitalness part 3 – organising for digital

~ mylesrun ~ Leave a comment

It has taken longer than I hoped to get round to this post. This is the third in the series of loosely themed pieces about what it means to ‘be digital’ and some ideas on how to make a start. The first and second pieces are available for the curious/persistent reader.

The impetus to write this post came from leading the first of a series of sessions for Digital Leaders on Developing a Digital Mindset. Future sessions in London and Leeds are available as part of their Academy courses.  The sessions are short, workshop style events aimed to give those with less hands-on experience some ideas and techniques to consider in their work with their teams. The premise is that we all need to be more digital – so how might we go about it.

During the session there was discussion about technology integration programmes in organisations and the fact that they are often pitched as transformation efforts. This, in turn, lead to exploring the notion that ‘being digital’ is not really about technology  – or that, technology alone is insufficient for real digital change. Technology programmes can generate efficiencies, speed and lower cost (they can also deliver none of those things, at their worst). But they probably won’t change the organisation much, and are less likely to change it in the far-reaching ways ‘transformation’ promises.

Some of the most significant elements of a digital mindset are how groups plan, behave and organise. Being digital is about people more than it is about technology (or at least as much) – hence the significance of culture. The ways and means of systems implementation will not support or sustain a digital mindset. Don’t be fooled by systems implementation houses that pitch this as an outcome from use of technology.

Anyway, with that in mind, this post is about organising for digital. Again, in no strict oder of priority, here are some of the most important features of digital organisations or teams. They are:

  • Flat (or flatter). This is not to say that there is no hierarchy. Some people are in charge and need to be (some decisions will need a ‘buck stops here’ approach). A flatter team or organisation will, however have shorter routes between a decision and action. It will also have less mediation and introduce less confusion between a decision and the enacting of a plan to carry it out. (Empowered and accountable teams can get things done with less fuss. as explored in Post 2). From my personal experience, the BBC is not a flat organisation – it is lumpy and bumpy in arcane and vertical ways. Time to and from a decision to action is best measured in planetary metrics. Spotify, on the other hand, is pretty flat and swift in movement and action.
  • Open (or tending to openness). This goes hand in hand with flatness and trust. It is easier to get things done quickly if access to information and to people is more open. Open document stores and open access to performance data are principles that digital organisations have been energetic in adopting. Team members are trusted to use data responsibly, making the apparent risk of open sharing lee problematic. (Organisations with a parental leaning will struggle to adopt digital ways, I believe. They are better suited to programmed waterfalls and the committees needed to steer them).
  • Accessible. Teams working in an open environment are easier to access – and anticipate ease of access in turn. This is partly a facet of openness and the access to information that results from it. It is also a cultural feature that allows for access to expertise and experience throughout an organisation. The structure and model of Stack Overflow echoes this across technology disciplines, being built around the expectation that access to expert guidance is readily available. Tools like Slack and Trello facilitate open access.
  • Small. A productive digital team tends to be a small team. Or, not too big. It will be large enough to get stuff and be self-contained but not so large that it becomes unwieldy, slow and over complicated. Jeff Bezos still stands by the principle of Two Pizza sized teams at Amazon. The optimum size of a team is one that can be fed by two pizzas (probably in the range of 8 to 10 people, depending on pizza size and appetite). It is easier for this size of team to take decisions and to communicate those decisions and share relevant information. Big is not beautiful but a large organisation can have many two pizza teams within it.
  • Multidisciplinary. Those small, self-contained teams are made up of the required skills and capabilities to be self largely self-sufficient and productive. A productive team will have the ability to:
    • Gather and analyse data and communicate information and usable insights from it
    • Design, test and improve a good user experience (this will include but not be limited to user interface and visual design)
    • Develop and test code – or at the very least, have access to and control over developers
    • Manage a the activity, inputs and outputs of the team, most often in the form of an agile project manager
    • Take responsibility for marketing, communication and distribution. Otherwise known as “if you build it they really might not come”.
    • Manage the product and define the roadmap around user needs and priorities
    • Manage the product and define the roadmap around commercial needs and business outcomes
  • Flexible. These small and multi-disciplined teams are easier to form and reform around shifting priorities. There is less organisational heavy lifting required on behalf of the business. Similarly, extended and complex orientation is less likely to be needed as new teams group around their objectives. More mature digital organisations will also have developed production tools and infrastructure which supports this flexibility and can be applied across many or all areas of business.
  • Clear.  Whilst the objectives of the team are clear, this is equally true of the individuals of the team. A smaller team is easier to direct in this respect. The daily stand-up of the agile world supports an open sharing of the activity and next steps of all team members. Accountability is individual and well as team based, as is responsibility.

There are many ways to get things done and no set of guidelines can simply be applied to the unique circumstances of any organisation. Unlike systems, these ways of working cannot be implemented to a preconceived plan. These things take time and effort to bear fruit and find the right shape and size for the circumstances. They are worthy of consideration, however and it is relatively easy to give them a try and adapt them to your needs. Easier and cheaper than a technology programme that is.

 

 

 

 

Making a start on digitalness – digital behaviours are simple but hard

~ mylesrun ~ 3 Comments

Slightly warily, I am considering a series of posts on one theme. The theme is ‘making a start on digitalness’. I am wary because I have started this kind of project before and lost momentum. I am considering another attempt for this topic. In drafting this idea as one post I became lost in notes and paragraphs and my thread became entangled. I think it is too complex for one piece. So. This might become a series.

The idea is borne from a growing sense that many teams and their leaders are peering over the garden fence at their neighbours and gazing in envy at their digitalness. In the learning world, this gaze is often directed further afield to more distant neighbourhoods. Nearby locales are more familiar and inspire less of this longing. This envy is not about technology.  I don’t see much coveting of our neighbours kit – we all have access to the technology and tools we (think we) need. It’s more of an admiration of the lifestyle.

Like anything valuable, making a start on being digital is hard and will require constant effort. I am taking it for granted that ‘being or becoming digital’ is desirable. It is possible not to try it. That route will guarantee irrelevance at some point, however. (I refer you to the inevitable YouTube “How to  do something or other” video which you did not make but everyone prefers to what you did make). So why not make a start?

If this does become a series, it will cover organising for digitalness, the culture of digitalness, working digitally and digital behaviours. This post is about the last one: behaviours. (Yes. These themes overlap – hence the entanglement).

It is also focused on making a start on digitalness not on an end state. This is because, in my experience, digital teams and organisations don’t fix at a certain point. Something happens, mainly to users, that requires a response. By definition, something has changed. This is one of the reasons why it is hard work. Like all the best jobs, it does not freeze in form and repeat.

Here are some hallmark behaviours that I believe a digital team and the members of a digital team will exhibit. These are the behaviours I would start and practice.

A digital team will:

  • Aways seek the user need – answer the “what’s in it for me?” question (the me being the user)
  • Always seek and meet the user to find the user need – there is no substitute for direct knowledge
  • Have a clear user focus – stakeholders are not front of the queue
  • Have a good sense of the business needs (stakeholders are important but not front of the queue)
  • Get something in front of users quickly (until the user has experienced it, there is no reliable way of judging whether it is any good or not)
  • Not wait for the finished article (until the user has experienced it, there is no reliable way of judging whether it is finished or not)
  • Focus on producing the minimum product /service/content from which they can learn about genuine user response (until the user has experienced it, there is no way of judging whether it is enough or not)
  • Seek data data to understand user behavior – don’t move unless you can measure (not ‘track’ – that is something else)
  • Observe – see what happens when you do move
  • Respond quickly to observations – change what you did last time and
  • Observe again…
  • Learn and want to learn – the data and the testing are all focused on improved understanding and then on an improved outcome
  • Reflect on experience – digital teams (agile teams in particular through the sprint retrospective) will find time to discuss and assess recent performance
  • Communicate frequently and directly throughout their work – Slack is a favourite of digital professionals for this reason
  • Share information routinely and openly – Slack is a favourite of digital professionals for this reason
  • Organise themselves quickly to focus on goals – the daily stand up is one of the rituals to set next steps and share recent activity
  • Seek expertise to solve a problem (and share the result) – Stack Overflow is a towering monument to this behaviour

One interesting observation as I scratched out that list: digital teams are learning teams (this is an element of the culture of digitalness which will form the heart of another post is this possible series). The focus on improvement requires equal attention to what has and has not worked, adjusting for both outcomes. Progress is made through this learning.

All of these behaviours signal organisational traits, ways of working and cultural patterns. To be properly embedded, they need those other factors to be in place too. To be true to the title, however, I think we can all start with these behaviours, individually and collectively, try them and make progress towards more effective digital working. The role of the Product Manager – the missing link in developing helpful learning technologies – is an excellent mechanism for gaining and sustaining momentum with these changes in any team.

As with all these successful digital endeavours – these things are simple but hard.

[Worthy of another post in the series?].

 

 

Stakeholders beat out users in LMS implementation (of course they do)

~ mylesrun ~ 2 Comments

I have been nursing this thought for some time now. I managed to spend a little time trying to add some structure to it and see if that helps me think it through more constructively. I belive it did.

Now, in Web 2.0 style (yes I am a traditionalist), I thought I would share it and see what that process might add.

Much is written and spoken about the UX challenges of corporate systems and their implementation. Mcuh of that has dealt with our old friend the LMS. Not much of the commentary is positive. I reckon that the structure of the vendor/customer relationship is, perhaps, the most significant factor in creating that negative sentiment. The poor user is a distant and quiet voice amongst the chorus of sales folks, solutions partners, stakeholders and implementation teams.

I have tried, quite simply I know, to illustrate that in the diagram below. Depending on the size of the organisation, more or fewer of these ingredients might be in place. There is a lot of decision making going on between the bright idea and the recipient of that idea. The needs of the organisation are studiously gathered and arranged. The system is painstakingly designed in the image of those needs. (A cynic might suggest vested interests are at play. I can see the point).

It is then, all too often, implemented at the poor user.

Learning Management Systems – from Vendor to user

LMS chain

The digital consumer market is quite different. The product creator makes the their product available as directly and swiftly to the user as possible. And that’s about it. (I recognise that I have not reflected that economic dynamics of the market here. The ad networks, analytics, optimisation and billings systems are not represented. These, however do not often impact the user value, they signal the user value in the metrics). Meeting user need is central in a fiercely compeitive market for free and paid products – attetnion is always limited, it seems. All other value flows from there.

It is much easier to design a tool a user wants to use when those layers of corporate interest are absent. Hence the universal preference for consumer tools such as Google, Twitter, YouTube, Wikipedia etc. as Jane Hart reminds us annually. In fact, when those layers of interest are present, I would argue that a product is not made for a user. It is made for the customer. That is where the invoices land after all.

Meanwhile users vote with their clicks and swipes and adopt the consumer tools that have become so familiar to our daily lives, at work and play.

What do you think? Does the diagram look familiar? I am minded to pursue this line of inquiry, so any steering thoughts would be welcome.

 

An LMS for the open web? Not for me, thanks

~ mylesrun ~ Leave a comment

Yes. This is another post about the LMS. A perennial feature of any learning commentators blog. I return to theme this week following a call with Don Taylor about leading a session at the Learning Technologies Summer Forum on designing good user experiences for digital learning. Something practical about good and bad practice is required. As I turned the theme over in my mind in drafting some talking points, I realised that I was essentially listing reasons not to use an LMS. Yes. This is that kind of post.

Since landing on planet L&D, I have tried to understand why nothing like the Learning Management System and its raison d’etre, the eLearning course, exist on the open web. In the roughly twenty years of evolutionary experimentation in the venture capital funded laboratories of the web there has been no meaningful sighting of an LMS-like product or service. If these tools are the best of the available solutions to the learning potential available online, then where are the public equivalents?

Similar services do exist to make courses available on the web (or course like packages of learning content). Masterclass is a really interesting example of the type – an explicit course provision product with closed, commercial access to exclsuive courses. This makes sense, I suspect, to provider and learner alike. It is the closed part that works best here. Register for an account and pay for the course. It’s a very simple, paid access LMS. The value for the payment is access to the course and experience. What is the user value for an open access LMS on the web, however? What extra benefit would I receive from use of that system? It certainly not search or browse – Google is pretty good for that. Recommendation is well handled via social media, as is discussion and commentary. Access to expertise is available and in large part is free, although I fancy this may change over the coming years. Of course, none of this is tracked but I don’t think LMS data is used by learners anyway (is it?).

At the heart of my LMS misgivings is basically that lack of user need. A service like that would attract little or no funding in a world where generating a large , loyal user base (i.e. millions) is the oxygen of investment. The value in the LMS is the for the learning provider: allocating courses to learners, managing access and tracking and reporting on completions. From a user perspective the LMS typically erects barriers to learning content. It then controls the experience of the content once accessed.

The gradual emergence of the Learning Record Store might shift movement in a more positive direction but I suspect it will be adopted by LMS operators as a means of dragging open content into the closed LMS domain. Open Badges also play a part in creating a location or system for recording and displaying learning achievement and activity in the wild – there is more hope here I feel as the education sector starts to consider these kinds of services. (I fear, though, that they have also been bacterially infected by the faddish application of another new buzz-tool: gamification).

Find things out. Get things done.

At one point of my BBC career I held the title of Director, Intranet Refresh Programme. The team I worked with were tasked with refreshing and re-presenting the entire corporate intranet (take a role like that with care is my advice). We had a working motto for the new product “It will always help users find things out and get things done”. This is the kind of utility value that good open digital learning tools should have too. They are designed to answer those needs as defined by the user and available at the moment of need with minimal or no barriers to access. An LMS is a long route round to the need of getting something done.

All of this is not to say that there is no value in the LMS. The idea of recording behaviour in a learning system is excellent. If only that data were then put to the use of the learner. This is where LinkedIn Learning Solutions could play a role as the place where open learning resources can be collected and reflected upon in a social context, gathering value in the user profile. Early days for this development, perhaps but there is something to pursue there clearly The utility for the user being the management of their profile and its value to a marketplace they chose to participate in.

None of this is intended to caim that there is not a role for the LMS in corporate learning. There are too many of them around for that argument to hold water. The value (and there is a fair amount to contend with), however, is for the orgnanisation rather than the user. That is why we, as users, don’t chose to use them.

 

 

 

The device is not the user – the user is

~ mylesrun ~ Leave a comment

Flicking through some conference notes this morning I noticed a quote from an event I attended last year. My notes are poor so I cannot attribute the quote. It was the 2016 version of this event. If you are responsible for it, or you know who may be, do let me know and I will attribute accordingly.

Here is what this wise person said about developing for mobile.

Think of a mobile phone as a customer, as a person, not as a device.

Reading this again, it struck me as blindingly obvious yet very helpful – a hallmark of much good advice. Short. Simple. Direct. Thank you.

As with most consideration of UX matters, a quick check of my own behaviour and expectations helps confirm the approach. There is also the simple fact that (most) devices do not work independently. They are the tools of the user. As tools, they are applied to a purpose, to the purpose of the user. Whilst consideration of how the device or the OS and software handles our content is crucial, it does not necessarily support the intent of the user.

I have been hung up on the challenge of rendering and presentation across devices and platforms in the past and have overlooked the user intent as a result. This is not an easy problem to solve. As always (and as I remind myself) the start point must be the user need. What is trying to be done? The device and presentation is, at least, secondary. As machine learning marches on, it is still useful to remember that there are organisms behind the machines.

What is, perhaps, importantly different about our mobile phones is how we personally attach to them. They are part of us and we imbue them with our selves as we use them. This brings a mobile phone interaction closer to us than with other devices. Close enough for us, as service providers, to pay extra care and attention. A dumb response on the phone feels dumber and more brutal than via the laptop browser I reckon. More care needs to be taken.

We also have some more particular needs on our phones. Time may be more pressured or more scarce, at least. We may not be sat attentively waiting to bathe in the wonder of that content. Standing, on the bus, in the supermarket, walking the dog. These are modes that require simplicity as well as brevity. At the very least,  they require choice. These are not device constraints they are the context of the user.

That context can be remarkably well defined on a phone as well. The amount of data available will vary from native to mobile app to mobile browser and from provider to provider. This data can describe a great deal about the user behind the device. To my mind any data we have needs to be handled responsibly. It needs to be put to good use or not gathered at all. The more data we hold form a device and it’s owner/user, the more utility and value we are responsible to offer. That’s what I expect on my phone, anyway.