We had a wonderful call today. We have begun the process of finalizing the edits to ship version 1.5.
Listening and learning from everyone who joins the calls always impresses me. Today we returned to the spreadsheet and began to hack away.
We started with Marc Lusser summarizing everyone’s general concern with the Connecting strand. Simply too much overlap and unobservable outcomes. The group decided to hold off on addressing this bug and focused mainly on the Designing for the web competency.
The competencies are now locked in this release. We are now finalizing the skills. In other words We will do our best to make sure skills fall in only one bucket for V 1.5 but won’t change the buckets until V 2.0. So for example in Connecting we will try to make sure the skills are differentiated and observable under each competency.
Turning to Designing for the Web
As a reminder this competency, “designing for the web” was split from accessibility to strengthen the weight of each. The design element of the map always felt inadequate, and if the web will be open to all it must also be accessible to all. We had scoped accessibility well, but we didn’t get at what design meant.
Doug, Jamie, and I had a wonderful conversation over on the git issue. Then Cassie came in and dropped some deep knowledge on us from a designer’s perspective. Doug summed it up as:
Thanks @cassiemc! Really useful to think through the different types of design. Just to pull them out of your comment, they were:
Visual design (graphic design, branding, style, illustration)
Interaction design (user interface and sometimes html/css)
User experience design (the overall emotional and practical journey through an experience)
As we were revising the designing for the web competency today I kept those words and LRA feedback about aesthetics in my thoughts.
I think we got close on the competency:
Designing for the Web
Enhancing visual aesthetics and user experiences
- Using CSS properties to change the style and layout of a Web page
- Demonstrating the difference between inline, embedded and external CSS
- Improving user experiences through feedback and iteration
- Creating device-agnostic web resources
To test this theory out I decided to go apply the skills to the work of a design team. I went and found Cassie’s great blog posts on her teams irl meetings. I then read her reflections and tried to annotate the post using the skills and looking for holes.
An unknown is where should interaction design live? We left it out of designing for the web because it is in the definition of the competency of coding/scripting: creating interactive experience on the web. Should interaction move under design? Is it the wrong modifier for experiences under coding?
Much of Cassie’s post stressed the importance of user testing in the design process. I think we captured that well:
I do wonder if we are only improving for user experience. There is so much more we can improve upon through feedback and iteration. Maybe user feedback is only one type?
Maybe iteration should be separated out into it’s own skill. That is one thing we did not capture. When you watch the slide show Cassie posted you see iterative design in situ. Do we need a skill to speak to this process?
We also revised the screen size, mobile vs desktop skill. Looking at what the team is cooking up I think we wrote a skill to match
I didn’t annotate for the first two skills about CSS but they are all over the pictures and the aesthetic last step. It’s interesting that such talented artist consider this their last step. When you watch the slide show you see design influencing every step of the way.
Looking Forward to Connecting
One of the major take aways from the last two weeks of calls was the need to address the Connecting Strand (which is why I threw out a click-baitish title last week). There is just too much overlap in the skills and ill-defined competencies. Plus we don’t get at the knowledge work teams do. Read through Cassie’s blog. We are missing something fundemental, though I do not know what it is or how to boil it down. We are going to hold off expending any mental capital on this until after v 1.5 ships. When we get there, though, I want to watch the spaces where Mozilla builds, learns, and leads in the open.
Exploring the competencies in the wild allows us to test the validity of the skills we try to identify.