Hi, 

Following the design stand-up on Friday, 8^th 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. 

Thanks
Sven