Keeping everyone in the loop – WPCampus 2018 – WordPress in Higher Education

Keeping everyone in the loop – WPCampus 2018 – WordPress in Higher Education

September 30, 2019 0 By Ronny Jaskolski


– [Shawn] My name’s Shawn Hooper. My pleasure to be here
for my third WPCampus. (audience cheers) I am the director of IT
at Canadian-based learning and development platform
startup Actionable. And what I wanted to
talk to you about today is the process that we go through for keeping all of our
stakeholders in the loop as we develop new
features for our platform. Actionable Conversations is our platform. The idea behind it is, it’s to help teams at workplaces build new habits
through continual reminders through the platform that
you would sign up for after a 10-week experience,
or something like that. It is a software-as-a-service product. We sell to consultants that are in the change management
space, in the HR space. We are a B2B platform. We are multilingual, with
users all over the world. We are built API first. The platform itself is
a Node.js application with WordPress being used headlessly as the content delivery with the REST API. And all of the notifications
that go out to the users of the platform asking them
to do their daily check-ins on their on their equipment, these are sent by email and SMS. So, that sort of positions where
the platform is that we do. And then we have all
sorts of players involved that we have to keep in
the loop during the design and development phase
right through the launch. We have our sales and marketing team. We have our technical support, our help desk that’s herding
cats (speaks quietly). And our account management people who work with our B2B partners. We have our lawyers who
have to be kept in the loop, our developers of course, our DevOps infrastructure people, our translators, everyone who writes documentation, the consumers of our API
that may not be ourselves, our B2B partners themselves, and of course the end users. These are all people that
need to know what’s coming when you’re going to be
changing something on the site. And they’ll need to be
brought into the loop at specific parts of development. So we’ve broken up our
development into phases, from concept, to design, to development and QA, to documentation and training, and finally to the launch. In the concept phase, we have a new feature
that we want to create, this usually comes from
our product leader, who happens to be our founder, or from feedback we get from the users. And at this point, we’re
gonna just wireframe what these screens might look like. Now, neither he nor I are designers, we don’t know how to
make this look pretty, and we’re usually drawing
them on a glass wall on our coworking space, just
to have a rough idea of, “Yeah, we can just build
something like this. “This would be kinda neat!” So what we’ll do is we’ll
take those wireframes, we’ll share them around with some members of our internal team, or maybe to a trusted user,
too, in our partner group, and see if what it is that
we’re thinking of building makes sense to them, before we go any further
into actually detailing out what tasks we might need to undertake. The other thing we want
to do at this point is a financial impact
analysis, if it’s required. For example, I’ve said
that our platform sends out a lot of text messages. So if we’re gonna add a
new feature to the platform that increases the number
of messages that go out, well, there’s a financial impact there. In North America,
sending a text message is a fraction of a cent per message. But if you’re sending a
text message in New Zealand, it’s 10 cents per message. So the impact could become
significant quickly. We’re also hosted on AWS, so if what we’re gonna be
adding adds new microservices or a bigger database,
or something like that, our hosting costs could go up. So, right at the concept level, you want to take a look and see, is there gonna be a
financial impact ongoing from adding this new feature and getting those approvals done. Of course, this is 2018 and
I’ve updated my privacy policy. (laughs) We do want to do
a personal data analysis at this point as well. We’re gonna add new features to the site. Are we gonna be collecting
new information from the users that is personal information? Do we need to update our
end-user license agreement? Is there GDPR impacts? Because at this point, if
there is, this is when we want to start reaching out
to legal, right away, and seeing if we need
to get their assistance, or if, for some reason,
they’re gonna put a roadblock to that feature ever getting
added in the first place. Here’s an idea of one of
those glass wall wireframes I was talking about. It isn’t pretty, but it does the trick. So at this… Agreed we’re gonna build the
feature, we go into design, those wireframes are then turned
into nicer graphic designs, the screenshots and notes are
converted into Jira tickets and Confluence pages for
the developers to work with. Confluence, we use for the “How did we build this
and why did we build this” explanation stuff that
Eric talked about earlier. A bit of documentation is always good. And we also look at
other supporting systems. We’ve built tools that
our help desk staff uses, for example, to help debug tickets. Is the new feature we’re building going to impact those tools, and do
we need to get the developers for those products involved in it as well? So, here’s a screen taken
quickly by our graphic designer. And he took our wireframes and turned it into a nicer-looking screen
that we can then hand off to the developers to build. Using our graphic designer, who, we use the same person all the time, helps our screens adhere
to corporate standards and has everything look the same, even though our developers are freelancers that might only be involved
for short periods of time. Jira tickets breaking out
all the tasks involved in creating that new feature. Even if it’s just on
a high level initially and then we can build in detailed tickets as we get further into the project. So, in the development phase,
the wireframes are converted into graphics, but at this
point, we also have to worry about collecting the copy
that goes on the pages. We have to worry about images,
we have to worry about video, we have embedded video
on some of the pages, the alt tags that we need
for those images and videos, transcripts, we need the text
for the email notifications and we need the text for the SMS messages. We can collect all of that stuff while the feature is actually being built. And of course, all of the tests
that go with that feature. In our environments
that are not production, so everything from the QA environment to local development environments, we’re using test data. This is especially important now in the age of the GDPR, private data, that we don’t wanna be
using production data in local environments because
you’re moving that outside of the data centers where
you’ve agreed to store the data. So we’ve developed test data sets that mirror what you would
really see in production. And at the same time,
we wanna be making sure that the infrastructure is being updated to handle these new features, that the continuous integration is still going to
support the new features. And if you need to step in, have that ready during
the development phase, and testing that in your
staging environments. At this point, we wanna have
the translators on standby. I’m not gonna actually
send them the strings that need to be translated yet because they’re probably
still going to change. But I’m gonna have an idea, at least, within a couple hundred
words of how many words it’s going to be, and what the
timelines are gonna be like, so I can make sure the
translators have time available. In the QA phase, we have
everything up in staging, and with a limited number of users, and with our internal staff, we ask them to go test the feature. See if it’s still making sense to them, see if there’s any
changes they would like. At this point, translation’s also working, and as soon as the translations are ready, then the QA testers who are familiar with those languages can
go in and look there. Also, this is the great
time to do load testing and security audits of all
that code that was written, also doing different
vulnerability assessments, penetration testing, anything
you can do to make sure that your code is secure
when it goes live. Of course, at any point in
this, we can still go back to development, make changes, tweaks, and make sure that the
feature’s the best it can be. But, changes, critically important, and especially sharing
it with people who are outside of the design
and development circle. Because you’re too close to it, make sure you get that second set of eyes on that feature by someone
who’s never seen it before. Make sure it still makes sense to them. Then there’s the documentation
and training stage. So, when you know what’s going on in QA, we know everything’s good, we need to worry about
detailed change logs. Those who are really close
to the product are gonna want to know every single thing
that’s changed in that release, even if it’s a minor
little bugfix or a typo. That’s what’s nice to
share in the change logs. Our user guides, our PDFs
that include screenshots and our “How to use this product” guides that go out to our partners
and their end users. The API documentation for developers who will be
consuming data from our API, they need to know if
there’s new endpoints, if that data’s changing,
what concerns are there. So that needs to be updated. We need to do training
sessions with the people who will be working the helpdesk, with the sales team, with
the key account managers, so that, when the product goes live and they’re getting phone calls or emails, they know how to explain that new feature without having to come
to the developer team. And also preparing canned
responses for the help desk. We know that, when a new feature launches, we’re gonna see an increase in tickets. So, if we can have some
responses ready for things that we know might be
questions, that saves them time. Also, worrying back to the staffing levels on the help desk as well,
right after a new release. So, there’s an idea of the
bullet-form release notes including bugfixes and everything. And then, just a piece
of the PDF user guide that we send out that
has screenshots included. Two weeks before a new release goes live, the site is in staging,
ideally code frozen. I say ideally because, well, you know, I was working on these slides last night. (audience laughs) The documentation and
release notes are sent to our partners and support
team with the release schedule. Sending this out in
advance allows our partners to know what’s coming,
and when it’s coming, and to be able to let
their end users know, and prepare them for that, and also, work that into the schedules that they’re going to be
using that platform for within that time period. So it gives them a little bit
of time to become familiar and ask questions before
that feature goes live. And then finally, we have launch. The site goes live,
ideally in off-peak hours. We’re working in a global market; that’s a very short window sometimes. And then, update the
client-facing user guides that are on our public websites, to have those guides that we shared directly two weeks prior, putting those up on the site. And having, then, the
support team also go in and look at all the bug tickets
that we may have had open, our feature requests that have been open and sitting on hold for a future release, and replying back to
those users and saying, “Thank you for that feature
you requested two months ago. “It’s been added to the platform.” And just closing up, closing
the loop on those tickets. And in keeping that entire
lifecycle going then, we have everyone internally, from staff right up to the end user base, who are now kept in the
loop throughout the design and development phase and
able to provide their input at the right time. And so, thank you. I hope that gives you
an idea of how we work! (audience applauds)