I had a great time at the Monday UX meeting yesterday and I believe we accomplished a lot as well as made progress about many other important things. As this was the first time I attended from start to end, I would like to take this opportunity to present the good, the bad and the ugly from my fresh point of view.
The best part is that there where no ugly, not even a hint. The meeting went smooth and Kevin, with the help of Dharmesh did a stellar job moderating and leading it. They where well prepared and lead the meeting perfectly. Even more importantly, they had done a their homework to be able to ask the right questions to the right people at the right time. #awesome!
In fact, they did such good job that I would like to nominate them to permanently lead these meetings. That would also help us build consistency, continuity and make it easier for new people to get up to speed.
That together with the ideas we discussed, at the end, about improving the g.d.o/usability group by using tabs and events to better organize and structure our work and information will, I'm sure, help us better get on-top of things. It will for sure allow us to better plan meeting agendas and thus allow everyone to be more prepared for the meetings too.
I'm happy to work with Roy and Bojhan, who are group administrators, and others with these things. I think my fresh impressions may come to good use here.
Meeting scope and peoples available time
One thing I believe is important is that we need to narrow the scope of these meetings. This is especially important based on the time each person are able to contribute to the community with. Many in the meeting yesterday does this as part of their work, while others, like myself, have much more limited and often unknown/unplanable number of hours per week where we can focus on community contributions.
I my case that means I need to carefully pick UX tasks where I can focus the time I have to really be able to make a difference. While I do keep an eye on the overall D8 development, there simply are no time for me to spend on keeping up to speed, including lots and lots of testing, on everything that was discussed yesterday. It think that was quite obvious as after the discussion about the file clean up problem, I pretty much zoomed out and had little I could give any contribution about.
Some of this will be improved simply by the changes we touched on for g.d.o/usability, especially when it comes to planning these meetings better ahead.
Planning ahead and an improved meeting agenda wont solve everything. We also need to figure out how to make better use of peoples available time and also the things they really want to work on when it comes to Drupal and UX.
In my own case I believe that my time and skills are not used effectively in meetings like yesterday. Simply because I have such limited and fluctuating number of hours per week. Yes, I can drop in to the meetings when its relevant, such as about the file clean up yesterday, but the rest of the time was not very productive.
However, we all know that we need to find long term solutions for the UX situation. That includes things such as a proper community UX strategy, how to get UX in earlier in the process, how to find ways to give basic training and education about UX and so on. These are things that isn't as panicy, having deadlines, as those we discussed yesterday. Thus they are topics us with more limited time really can dig into without the pressure about a deadline getting closer. And it is also something I personally am very passionate about. Little give me a stronger kick than empowering others to focus on their real role tasks.
I also strongly believe that we must find ways to deal with these in parallel to the development related UX work. If we don't we will just continue to be stuck trying to deal with UX after the API's are defined and code already are written. This because the short term needs will always have higher priority than the long term ones. We will keep ourselves busy, but it will not be a very efficient way of really improving UX, certainly not long term. Plus it will keep us in a stalemate between us and them...
My proposal for us to do both is this:
- Narrow the scope for the weekly Monday meetings to only direct development related UX work.
- Form a separate team that focuses on our long term UX needs, including a holistic UX strategy
We could even call the group working within the development the UX Task Force. It would in the name tell exactly what the scope is. Plus its a pretty cool name that in itself should be able to help raise both awareness about UX and the status for how important UX actually is. We will for example be able to use it to document and show a track record, "The UX Task Force was here...", for the things we are working on as well as what the task force has done. That way it wont just disappear and become invisible as much of the amazing UX work currently does. This because of the fact that many within the community doesn't really understand the massive amount of work needed to make great UX happen or why it is needed.
After all, the better the UX is, the more invisible it becomes...
At the same time, the new group will be able to focus on our long term needs. Starting by identifying what they are, what we already have and then come up with ways we can develop and implement improvements one by one.
This wont be two groups with two separate and isolated sets of people. There will be overlaps and many sub projects in each with different formations of members.
However, it will allow us to do both by better structure and organize the work to improve UX at all levels within the community. The new team will work closely with the UX Task Force as one of its primary tasks is to understand the work involved and help develop and improve the tools, processes and guides for the task force needs to not only be successful, but to allow new members of the community to join it.
I am convinced that if we do this right, it will quickly make huge improvement to everything UX related.
Comments
Thank you
Thomas,
Thank you for the detailed post and the kind words. This is super helpful for every one who attended the meeting but also for others who would be interested in joining the group and understanding our challenges.
We all have been working hard in all our might to bring the UX change, one screen at a time but yes! we need to work smart than hard. It is my hope that meetings like these will help get better how we tackle problems.
I particularly like your idea of having two components to UX team because everyone doesn't necessarily want to be involved in both of the aspects, given the time constraints/ interests. This can be loosely be based on a model followed by organizations: Project manager/ Designers/ Researchers. We can think of ourselves as a consultancy, just that we aren't getting paid :)
Now, what we need to do is to keep the momentum going and not stop. To move this forward, I would really appreciate if others could provide feedback that they have on this.
Dharmesh Mistry
UX Researcher | Acquia,Inc.
Glad you found the post
Glad you found the post useful Dharmesh. Particularly I'm happy about that you like my idea about "having two components" as you put it.
The more I've been thinking about this the more right it sounds to do it. The simple way to define these two components could then be:
UX Strategy would then be where we analyze our current processes, tools and needs, not just UX, then identify, prioritize and work on improving those.
I believe this would make it much easier to separate things. It owuld also allow us to work not only more focused, but also make good progress on both short and long term needs.
But most importantly, it will give us a much better ability to find tasks that fit everyones abilities when it comes to skills as well as time and resources they are able to contribute with. That and minimizing the risk of burning people out at the same time.
--
/thomas
T: @tsvenson | S: tsvenson.com
Thanks for writing this up
Thanks for writing this up Thomas. You make an interesting point about the crammed agenda of the meetings. Because UX is a initiative that spans the entirety of Drupal, it's difficult to be up to date with every task and often design contributors find their own particular niche to improve. I's also very common for certain items on the agenda to overrun.
With that in mind, I think we could go one step further, instead of splitting out meetings into architectural and task based I think we could split up meetings by individual task or initiative. This fits better with how other Drupal initiatives are being run, UX is an element of all of them.
Thanks Lewis, glad you picked
Thanks Lewis, glad you picked up on that. As you say, UX is everywhere and also a quite different thing compared to everything else that is done in the community.
I completely agree with you about splitting up meetings in individual tasks and initiatives. I would actually reverse it and say its the individual tasks and initiatives, in combination with the time and resources those wanting to work on them have, that should define not only the meeting needs, but also the best ways to collaborate to solve each task.
This is where our long term strategy, processes and tools needs comes in. Its where we can identify and work on defining our collaboration methods, models and tools to allow people to work really focused on those things.
--
/thomas
T: @tsvenson | S: tsvenson.com
Before running full-steam
Before running full-steam into several meetings, I'd love to see the attendance of our current meetings rise a bit. I don't think it makes much sense to call for more meetings, when our current meetings are often sparingly attended. I love the post-drupalcon attention to this, but when that dies down a bit we are left with a organisational structure for dozens of people where there are realistically only a few active.
I believe its valuable to have a strategy discussion, but lets just have that a strategy discussion - no need to make that a weekly meeting. We don't have enough tactical force anyway, to strategise about it every week :)
Sorry for being so pragmatic here, but I think this proposal might be over reaching a bit, lets just start this discussion and then plan ways to move it forward, if that means having more regular meetings thats fine. But lets first kick off the strategic discussion.
I think you have
I think you have misunderstood my post quite a bit Bojhan. I'm not talking about more meetings - I'm talking about more focused meetings. That is a very big difference.
I don't judge the success of meetings from how frequent they are or how many people that attended them. The outcome of the meetings is what is the important thing. Particularly how energized and motivated the attendees are after the meetings.
To be able to plan and execute a successful meeting there are many ingredients that needs to be right. Most important part is that the meeting needs to be relevant for those attending it. If its not they lose motivation and simply won't show up the next time.
As I mentioned, Kevin and Dharmesh made a stellar job leading the meeting and keep it focused. But as I also said there where a big chunk of the meeting that was very irrelevant for me. It covered topics that I had limited, or none at all, knowledge about and it was impossible for me to really understand what was talked about.
To be honest, I don't see the relevance for me to attend these Monday meetings. This simply because I don't have the time available to do testing and following the progress made on the topics discussed.
However I have time to work on other UX related things and I know that there are lots of other members of the community that is in the same situation. The problem is that currently there is no place for us to do this in an organized form.
I am looking at this from a pragmatic point of view. A view that tells me that we haven't actually made much progress in the way we do UX work.
We don't need one big UX team where everything is tried to be solved. Then the short term priorities and needs will always win. That is why we are still stuck doing UX after the code is written and have to fight harder than needed for every UX win we get. The same as during the Drupal 7 development cycle.
No, we need many small teams that works on different tasks and has different goals. Then they will be able to prioritize their work based on their own goals and objectives.
As I have already mentioned, The UX Task Force teams would have the goals and objectives to work on solving short term UX tasks for Drupal Core and contrib projects. The UX Strategy teams on the other hand would working against completely different goals and objectives based on the long term UX needs.
Part of the goals and objectives for the UX Strategy teams would be to define productive ways of collaborating on UX. In that sense they will actually function as support/service teams to the UX Task Force, making it possible for task force team members to better focus on making things happen.
But the most important difference this would introduce would be to make it much easier for members of the community to find teams and tasks that are relevant for them to work on. Not only based on the skills and experience those members have, but most importantly the available time and resources they have and are able to contribute with.
Lastly, I am convinced this will have absolutely no negative impact on the current work. In fact, it will quickly improve things as it will open up for new members to find things to work on that suites their individual situation.
It would transform us from an all or nothing situation to a bite sized buffet to chose from.
--
/thomas
T: @tsvenson | S: tsvenson.com
Still: resources are our bottleneck
I like the perspective, but this all still depends on there being a bigger crowd the we currently have. I think that having more focussed topics, teams, meetings could help improve that situation.
How do you propose to grow the team(s)?
I agree completely that
I agree completely that resources is a bottleneck. Part of the solution is the be smarter about how we use the resources we do have.
I am a little swamped right now, but give me a few days and I will come back with more elaborate information about how we can do just that.
--
/thomas
T: @tsvenson | S: tsvenson.com
I'm personally interested in
I'm personally interested in helping out where I can, although it would be more on my own time. Unfortunately, I was missing any meeting reminders that may have been going up about the Monday morning meetings, so I wasn't attending. This discussion has helped keep me back on track though, so I'll make sure to attend the next meeting and help out where I can!
Danielle Sheffler
Engagement Manager at Acquia
http://www.acquia.com
Great! Maybe add this to your calendar
https://www.google.com/calendar/ical/drupalux%40gmail.com/public/basic.ics
We're meeting in IRC every monday. ( http://drupal.org/irc for info on that)
Focus is the key
I’m all in favour of accommodating diverse modes of participation. And more focused meetings would be a key part of that. Articulating these focus areas (e.g. testing, reviews, design, prototyping, strategy, bug fixing, …) allows a greater number of potential participants to choose how they want to jump in, based on their own skills and interests. Establishing the relationship between these areas will help make the most of people’s valuable time.
While it will be a challenge to get in front of the problem and help guide developers rather than doing post-production ‘cleanup’, if we can pull it off then the across-the-board saving in time and energy, as well as the noticeable improvement to UX in Drupal, will be well worth the effort.
Michael Keara
User Interface Systems Architect,
The User Advocate Group