Difference between revisions of "DCD Blogs/7 Things I Learned from Leading a Design Project"

From wiki
Jump to navigation Jump to search
(Created page with "FR:DCN_Blogues/L'essai de l’icône <!--The following line of code hides the page title--> {{DISPLAYTITLE:<span style="position: absolute; clip: rect(1px 1px 1px 1px); c...")
 
Line 15: Line 15:
 
<br>
 
<br>
 
<div style="border:1px solid #white; {{Round corners}}; text-indent: 8%; margin: 20px; margin: 0 auto; width: 700px; line-height: 2em; font-size:125%">
 
<div style="border:1px solid #white; {{Round corners}}; text-indent: 8%; margin: 20px; margin: 0 auto; width: 700px; line-height: 2em; font-size:125%">
−
'''<span style='color:#545454; font-size:125%'>Last week at the Innovation Fair</span>''', the Digital Collaboration Division team invited guests to take part in an icon testing experiment. The Digital Collaboration Division (GCTools team) is working on a redesign to make the different tasks (i.e. blogs, the Wire, GCcollab, the Wiki, profile) into one centralized application suite, and we want to make sure we get it right! To create the best tools possible for users across government, private industry, and academia, we will be conducting usability tests regularly. This was the first step!
+
'''<span style='color:#545454; font-size:125%'>In November, two developers and I started working on a design system</span>''', for Government of Canada digital collaboration applications to guide the design of the next iteration of the GCTools. Over many days of planning and late afternoon epiphanies, we came up with a solid strategy and work plan to build something awesome.  
 
<br>
 
<br>
 
<br>
 
<br>
−
Redesigning a website is hard, and requires incredible attention to detail, which is why we need to test everything — even something as small as icons used on the site. Icon testing is done to make sure that when various icons are used on our webpages, users will understand what they mean, and what functions they might find if they click on the icon. This is important because users with different cultural and technological experiences may ascribe different meanings to different icons. This can cause trouble when attempting to convey a singular meaning through a simple image.
+
Fast forward to today and we have four developers, three writers, three user experience researchers as well as design expertise across the whole project team. We’ve collaborated with six partners across four different organizations. Most importantly, over the past months, we’ve built and compiled a large repository of content that matches the caliber of private tech companies, and connects the Government of Canada’s various digital resources, policies and learning material.
 
<br>
 
<br>
 
<br>
 
<br>
−
Alongside the development team, we decided to look at three categories of icons, and chose six icons for people to choose from: a gear, a wrench, a hamburger menu, a waffle menu, a bell, and a flag. We displayed icons commonly used to represent settings, application selection and notifications — three important functions in any app suite
+
After six months of managing a project, I’ve definitely learned many things about myself, my teammates and the challenges surrounding every innovative or unconventional government project. Here are some of our key lessons learned:
 
</div>
 
</div>
 
<br>
 
<br>
−
[[File:Icon Testing Blog - Icons.png|center|936x186px]]
 
 
<br>
 
<br>
 
<div style="border:1px solid #white; {{Round corners}}; margin: 0 auto; line-height: 2em; width: 700px; font-size:125%">
 
<div style="border:1px solid #white; {{Round corners}}; margin: 0 auto; line-height: 2em; width: 700px; font-size:125%">
−
We selected a gear or a wrench for '''settings''', a hamburger menu or a waffle menu for '''application selection''', and a bell or a flag for '''notifications'''.
+
1. Get to know people on your team; they are everything to the success and enjoyment of your project. Knowing the strengths and weaknesses of the people on your team makes delegating tasks so much easier, and everyone should get a say and get a chance to work on something they’re interested in. And having a group of people that works well together makes everything smoother and more fun!
 
<br>
 
<br>
 
<br>
 
<br>
−
When it came time to test the icons at the Innovation Fair, we were the girls struggling to carry an easel up and down Slater Street. While we unfortunately were not able to complete our icon testing using virtual reality — an asset many other departments were equipped with — we still managed to have 32 participants run our minute-long icon test!
+
2. Building anything new is a messy process. Try to organize the chaos best you can, but accept that the amount of uncertainty and tough questions will feel overwhelming at times.  
 
<br>
 
<br>
 
<br>
 
<br>
−
While we had our own assumptions of how icons would be classified and which icons would be best, we were surprised by the diversity of responses! Of course, when gathering thoughts and opinions there were no wrong answers, but over time a clear trend emerged. When asked which icon best represented the category we named, it was found that users most often chose the Gear, used to represent Settings, the Waffle Menu for Application Selection and finally the Bell which was chosen to represent Notifications.
+
3. Be strategic about working with others. Partners and collaborators are valuable, but can also broaden the project far beyond its original scope. Stick to your original goals and have a clear plan from the start on who to engage with, and when to engage them.  
 
<br>
 
<br>
 
<br>
 
<br>
−
The results and feedback we got from this quick experiment are going to be combined with some of our other user testing research, and be put towards designing the new GCTools! Which icons would you have chosen for each category? Would you choose some icons for a desktop website and others for a mobile application?
+
4. Planning is good; building is better. Since this project started in parallel with the rebuild of our applications, there were a lot of questions that were still unanswered. At some point we had to just get started and see what kind of process evolved. We had to adapt our original process as we went, but no amount of planning would have avoided that.
 +
<br>
 +
<br>
 +
5. Democracy is good, but eventually someone has to make a decision. Critique and feedback is necessary, but not every decision will be a full consensus. That’s okay. Have faith in your judgment, and change things later as you gain new information. 
 +
<br>
 +
<br>
 +
6. Content is always king. Your work should speak for itself. Be proud of it, pour all your expertise into it, and take ownership of your work! (Even if we’re so often afraid in government to do that).
 +
<br>
 +
<br>
 +
Bonus: Food is always the best way to get to know people, to apologize, or to celebrate. Start your meetings off right with Timbits!
 +
<br>
 +
<br>
 +
Curious to know where we’re at with the Design system?
 +
Now in phase II, our design system currently contains enough content to start building application wireframes, learn more about design, and apply common styles to all our digital products. Completely open, the design system is available via our Github repository and our Gitbook documentation.
 +
<br>
 +
<br>
 +
As the GCTools and other digital applications evolve, our design system will undertake constant modifications and additions. Do you have suggestions or comments about our content? Want to make use of our system? Submit an issue through Github or contact me directly!
 
</div>
 
</div>
 
<br>
 
<br>
 
<br>
 
<br>

Revision as of 11:39, 19 June 2018




Blogs Banner EN.PNG



 7 Things I Learned from Leading a Design Project
 Sierra Duffey / Web Content Developer / June 20, 2018
 4 minute read


In November, two developers and I started working on a design system, for Government of Canada digital collaboration applications to guide the design of the next iteration of the GCTools. Over many days of planning and late afternoon epiphanies, we came up with a solid strategy and work plan to build something awesome.

Fast forward to today and we have four developers, three writers, three user experience researchers as well as design expertise across the whole project team. We’ve collaborated with six partners across four different organizations. Most importantly, over the past months, we’ve built and compiled a large repository of content that matches the caliber of private tech companies, and connects the Government of Canada’s various digital resources, policies and learning material.

After six months of managing a project, I’ve definitely learned many things about myself, my teammates and the challenges surrounding every innovative or unconventional government project. Here are some of our key lessons learned:



1. Get to know people on your team; they are everything to the success and enjoyment of your project. Knowing the strengths and weaknesses of the people on your team makes delegating tasks so much easier, and everyone should get a say and get a chance to work on something they’re interested in. And having a group of people that works well together makes everything smoother and more fun!

2. Building anything new is a messy process. Try to organize the chaos best you can, but accept that the amount of uncertainty and tough questions will feel overwhelming at times.

3. Be strategic about working with others. Partners and collaborators are valuable, but can also broaden the project far beyond its original scope. Stick to your original goals and have a clear plan from the start on who to engage with, and when to engage them.

4. Planning is good; building is better. Since this project started in parallel with the rebuild of our applications, there were a lot of questions that were still unanswered. At some point we had to just get started and see what kind of process evolved. We had to adapt our original process as we went, but no amount of planning would have avoided that.

5. Democracy is good, but eventually someone has to make a decision. Critique and feedback is necessary, but not every decision will be a full consensus. That’s okay. Have faith in your judgment, and change things later as you gain new information.

6. Content is always king. Your work should speak for itself. Be proud of it, pour all your expertise into it, and take ownership of your work! (Even if we’re so often afraid in government to do that).

Bonus: Food is always the best way to get to know people, to apologize, or to celebrate. Start your meetings off right with Timbits!

Curious to know where we’re at with the Design system? Now in phase II, our design system currently contains enough content to start building application wireframes, learn more about design, and apply common styles to all our digital products. Completely open, the design system is available via our Github repository and our Gitbook documentation.

As the GCTools and other digital applications evolve, our design system will undertake constant modifications and additions. Do you have suggestions or comments about our content? Want to make use of our system? Submit an issue through Github or contact me directly!



Retrieved from "https://wiki.gccollab.ca/index.php?title=DCD_Blogs/7_Things_I_Learned_from_Leading_a_Design_Project&oldid=3335"