Example workflow guide

[TJkrusinski]

This is an early prototype we developed for feature development at that startup I work for. Originally we were planning on using the wiki but we realized we could get by using issues. Haven't update that information on this doc.

Workflow

Purpose of this document

This resource is the outline of how STARTUP imagines, develops and implements features on the STARTUP product. The goal is to have open conversation regarding a feature as it goes from idea to implementation.

Goals

• Create an environment for feature development that is open and collaborative.
• Have processes in place that enforce accountability and open communication.
• Establish all information regarding a feature before it hits development.
• Once a feature is in development, allow a place for the developer to refence that is current and can answer any related questions.
• Notify users of changes during feature development process automatically.

Process

Feature lablels

• Proposed - A feature idea that is new and is open to any and all changes, revistions. Here the idea is shot down or chosen to be created.
• Candidate - A proposed feature that has been chosen to move forward in the process.
• Describing - Listing out every scenario that the feature has and does
• Designing - A feature that is being designed.
• Developing - A feature that is being developed.
• Testing - A feature that is being tested in the hands of beta testers.
• Deployed - A feature that has hit production and is in use by the general user.

Feature imagination proposed

An abstract of the feature is presented to the team. Outlines of the problems it solves, it's value, where it is, what it would look like, how it would be used are established. Conversation takes place on whether or not to move forward with it. The feature is currently considered a candidate.

Once the feature is proposed to move forward, it's functionality is outlined with user stories. Using the user sign up process as an example, it could look like this.

We need to create a better sign up process that general
users can user to become informed on not only how to signup
but also be informed on the app itself. - TJ

I like the idea. It could almost be a timeline based
walkthrough of the app with panes that have
screenshots that the user uses to sign up - Stephen

These blocks of ideas contribute to the overall implementation (these are now comments on issues), design and code of the to be feature. Putting the conversation in blocks helps later on by going back and having a full reference log of how the idea formed.

Outlining feature roles candidate

After the idea has been established, an outline of the roles of the feature is plonked down. Here pros and cons are disscussed. However mundane it is to outline the features, having them spelled out is valuable. For example outilining the goals of a chat feature would look like so.

• The user has a list of available people to chat
• The user can select a user to chat with
• The user can type into a text box that will allow them to send a message to the other user
• Chat histories are stored for user to user interaction allowing users to go back and reference old chat messages

Fleshing out the high level goals a feature in the wiki that are listed out directly after the proposed ideas will allow us to hopefully be able to turn the dreams and ideas we had into actual peices of that feature.

Listing feature roles and actions describing

See this as the overview of the UX of the feature. In this stage we go through and list the entirety of the features steps of fuctionality, categorized by general related tasks. Here is an example with the tracking menu (not the whole thing but you get the idea).

Tracking menu

Selecting a user to track

• If the user is currently not tracking a user, the dropdown list will currently say Select User and the tracking logo will be grey.
• If the user is currently tracking a user, the dropdown list will say the name of the user that user is tracking and the tracking logo will be blue.
• When the user selects a user to track, the tracking logo will turn blue, the name of the user to track will appear as the currently tracking user.
• After the dropdown menu disappears the user to be taken to the show that the user they are tracking is in and the cue sheet will advance to the cue the tracking user is on.
• At that point they will be subscribed to any changes in show position that the tracking user makes, moving forward a cue, back a cue, to a different show or jumping to a cue within the current show.
• The cue the user is currently on is highlighed blue, and the next cue is highlighted a ligher blue.

Turning tracking off

• Should the user choose to no longer track another user, they can click the blue tracking logo, or select the Select User item from the list of available users to track.
• This will unhighlight the current selected cue from the cuesheet and will unhighlight the next cue also.
• The tracking logo will at this point turn grey.

The processes and steps associated with using the feature are outlined as much as they can be at this point. These are a mix of UI changes, tasks that the user has to do, notifications they will recieve etc. This list of things to do is an evolving one. Changes should be made by anyone, but as they change things, they should notify the rest of the team in some capacity. This period of creation is rather loose, but when it is time to move on to the next step, the title section for this peice should read LOCKED at which point we shouldn't make any changes before asking anyone who is working on this feature, whether it's design, or development.

Designing designing

See this as the creation of the UI of the feature, after the UX is done. This is simply a label that the feature uses to tell people it is being designed. This process is something we'll have to work on, I imagine a lot of the conversation here will be done by email. We will have to figure out how to place a timeline on this stage Once the design is done, screenshots will be updloaded to S3 or they could use the public URL from dropbox and use that as the image source, and will then be linked in the wiki that outline the states of the feature and the procedures. When this is done, there is an approval process that occurs before moving on to develpoment. Any needed revisions happen then.

Developing developing

This stage is when the idea comes to life. The developer has everything they need to create the feature in terms of UX/UI of the feature, the importance of the feature and some idea of the timeline of when it needs to be done. The dev also has all the screenshots of what it should look like so they can flesh out the CSS to where it needs to be. After the dev has finished the implementation, they push the code to dev servers and ad links to the wiki that the team can use to take a look at the work. Once the link is posted, the feature goes in to Testing mode. Unless something totall sucks which conversation like the following will happen on this part of the document.

So this feature actually sucks I don't know what
we were thinking, how do we fix it. - TJ

I'm going to put this feature back into designing
state so, I'll let you know when I am finished 
and put it back into developing. - Stephen

Testing testing

Here's where github issues can come in handy. My thought is that once the dev has provided a link, the rest of the team knows it is in testing and can use issues for bugs, enhancements, css changes etc. Then if it is a feature that needs beta testing, we can provide links to our beta testers to try it out and use.

Pushing the feature live deployed

At this point the feature is ready to get into the wild world. From here we notify users, monitor it's usage with a watchful eye and present opportunities for feedback from general users. Should there be any bugs from this feature anytime they are put in github labeled as a bug and with immediate priority. This way they get primary attention and get fixed as soon as possible.

So that is what I'm thinking. A central document that has everything you could ever need to know about a feature that we can hopefully give to anyone. For instance if we hire a copywriter for the marketing site, we can create PDFs of these documents and then hand those off. If we hire a new designer, they can use the documents as reference against the current state of a feature as they update it, and then they can update the document to reflect their changes. Let me know what you think.

Other stuff

Comment blocks

The comment blocks should look like this

This is my comment about something - TJ

That is totally rad, I'm going to give you 
more money. - Stephen

Basically it's a ghetto conversation peice. Look at the source code on how to create them.

[robbschiller]

Thanks for sharing this dude.

Stoked to read through it.

[robbschiller]

By the way @TJkrusinski and @mstrchrstphr, you guys should both come to the design orlando meetup next week so we can have the DT framework I learned at the d.school in mind to keep communicating about this stuff.