Organising the design workstream
by Sven Laux - Monday, 11 November 2013, 10:47 PM


Following the design stand-up on Friday, 8th November, I have given some thought as to how we could best organise the work stream. I have the following proposal and would be keen on your feedback.

The overall objective of the work stream (as I see it) is:

  • To translate the Adapt Learning vision
  • into a server-based authoring tool product
  • by designing a market leading, easy to use, server based authoring tool.


The focus of the design work stream is on the authoring tool.

Most of the project is split into two major component parts: the framework and the authoring tool. It’s important to note that the framework is in existence and that the authoring tool is essentially following on from that (apologies for stating the obvious). This also means that the majority of the design for the Framework is done and follows a specific learning methodology. The focus on the design stream is therefore on the authoring tool. The work we are doing for the MVP on the framework is a re-architecture to make it more modular and suitable for an open source project and for use with an authoring tool.


The design stream ought to lead ahead of the development work.

Given that the framework is already largely in place, that we have had workshops on the technical front and that we are working to tight deadlines, the technical work is currently ahead of the design. Our challenge therefore is to catch up with the design work and lead ahead of the development. The positive news is that we have a very good common understanding of the high-level concept and vision so that, as long as we catch up soon, no efforts are wasted.

The purpose of the design stream in relation to the technical stream is to inform, guide, support and review the technical work. There are several vehicles allowing us to achieve this: the key ones being documentation (deliverables) and communication (via a variety of channels). These are outlined below.


We have to pull in the expertise of the steering group.

We are designing a learning related product. This entails a number of considerations:

  • Product – we need to think in product terms, rather than in project terms. Generally, this involves looking further ahead into the future, taking on board many views and getting insight into the mindset and characteristics of the target audience.
  • Audience - ideally we will have direct input from the audience. The steering group has been designed with this in mind: The various ‘hats’ will give us the breadth of considerations we need. Further to this, the community site gives us direct access to some potential end users and we can also reach out to further specific user types through the members of the steering group.
  • Learning-related – we have to achieve the correct balance between ease of use and flexibility. The specific example is the information architecture around plug-ins. For example: fixing navigation in the tool for 'assessment' and 'learner support'. While these are plugins, it's important for us to think of the UI and navigation in the tool and making this meaningful and suitable rather than letting everything be a configurable via a plugins menu (e.g. as with Drupal and Joomla).

The task of the project team is to draw out the thinking and advice, ideally through planned thinking activities and reviews. This should be done with specific questions / objectives in mind, i.e. rather than uploading docs and welcoming views, we ought to try and ask specific questions and agree timeframes for input.


We work on the following deliverables:

It’s important for us to agree on a set of deliverables. The methodology of how we work is as yet in flux. That’s fine and things will fall into place as we move along, especially if we:

  • Have a clear and joint understanding of the concept
  • Communicate well
  • Agree on the set of deliverables

The development team uses the Agile software development methodology. The design stream has a bit more ground work to do for this methodology to work well. The challenges is for us are to

  • Understand the bigger picture
  • Agree on the minimum viable product (MVP)
  • Think through enough of the product so that the overall interface is well designed and easy to use rather than be cobbled together
  • Be one step ahead of the development stream

I propose the following set of deliverables:

  • Glossary of terms (to establish a common language)
  • Concept / vision document
  • MVP definition document
  • Requirements document
  • Actors and user stories document
  • Information architecture document
  • Functional specification document
  • User interface document including wireframes
  • Art direction
  • End user documentation
  • Review / sign-off of built end result


We structure our communication as follows:

We have three main communication channels. These are:

  • Weekly design stand-ups
  • The community site
  • The IRC channel

I propose we use these channels like so:

The weekly design stand-ups should focus on individual updates on progress and blockers, assigning tasks with regards to producing deliverables, presenting outcomes, discussing specific issues and discussing reviews of deliverables submitted. Each meeting will therefore have one or more specific topics for discussion, which we should know in advance.

The community site should be used to post notes from the design stand-ups (to keep the community informed) and raise specific topics for discussion, especially with a view to getting a steer and moving towards a decision. Naturally, there may be questions and input on an ad-hoc basis, which should be included in our thinking. We should therefore aim to answer every post from a community member one the same day.

The IRC channel should be used to ask ad-hoc questions as and when they arise and quick input is needed. We agreed to put all communication (related to design and technical work) until this becomes an issue, at which point we can split out a design channel. Until the work on auto-archiving the channel is complete, please consider posting notes of major discussions on the community site by hand.


Ordering of design documentation

There have been a fair few design-related documents posted on the community site for review and comments. I have started the task of downloading and ordering them today and will upload them to Github shortly. I propose to use the following folder structure. We can amend this later on if needed:

  • Concept & vision
  • Requirements (incl. actors, user stories and MVP definition)
  • Specification
  • User interface
  • Architecture
  • End user documentation


I hope this makes sense. Please let me know of you agree or if you have any questions or alternative suggestions. 



Re: Organising the design workstream
by Sven Laux - Tuesday, 12 November 2013, 5:00 PM

I have restructured the Github repository documentation accordingly. Ryan, thanks for merging the pull request.

Note, Github does not let us upload empty folders so there are some missing.

Also, I'm aware there are a few documents kicking around on individual's Google docs accounts. Please can I ask everyone to add them?

The folders created should be suitable for all documentation (i.e. the folders accommodate both technical and design-related docs). However, the repository is split into the following three categories:

  • Generic / cross workstream
  • Adapt Authoring Tool only
  • Adapt Framework only


Picture of Ryan Adams
Re: Organising the design workstream
by Ryan Adams - Thursday, 14 November 2013, 12:08 PM

Hi Sven,

I've now read and digested this.  It makes sense to me.

I wonder whether it would be useful to define what we mean by design in the context of this workstream. I think I was considering it from the perspective of UI and user flow through the Authoring Tool, but I perceive from the deliverables you've listed that you view it a bit wider, encompassing Learning (Instructional) Design, Product Design and some Technical Design.

I agree with you that its focus should be on the Authoring Tool.  I think the requirements of the Framework should be an input to it, particularly if the design of the framework is already complete (i.e. if we say the MVP for the Authoring Tool is to enable authoring of content for the MVP of the Framework then the framework needs to feed its requirements into the Authoring Tool design workstream).

I think we're beginning to see that set of requirements now with the Component specs from Daryl (currently in draft) and the notes Paul has been putting up here (assessment etc.)

Just on your point about the Steering Group, I've had a look around the community site and I can't find a list of steering group members.  Could you publish (or point me to) that along with the hats they wear?


Re: Organising the design workstream
by Sven Laux - Thursday, 14 November 2013, 12:55 PM

Thanks, Ryan. 

Yes, by 'design' I mean the wider thing that happens before the actual implementation (development), i.e. all the things you have listed above. Probably not the best choice of term on my part. Thanks for highlighting.

Good catch regarding the Steering Group, I meant to have this written up a while ago. Will do so as part of a page on the community site before tomorrow.


Re: Organising the design workstream
by Sven Laux - Friday, 15 November 2013, 6:49 PM

I have just written up the current Steering Group membership with names, roles and hats on our public governance page.