Kickoff
I started my part of the project off by simply compiling the various
requirements passed down
from the business. I wanted to make sure that all of the features we were
wanting for the
initial release made it into the design.
Like I mentioned I started the project off by creating a flowchart that would
allow other
individuals on the team to see how the application would flow from start to
finish. From there I
constructed a simple wireframe that helped me layout all of the different
screens and the
content within the screens themselves. All of these deliverables were going back
and forth
between the different teams and me on the design team to make sure
that everything was clear and concise while also meeting requirements. Once I
got approval on my
first few deliverables I hit the ground running with a high-fidelity prototype.
It was the most
time consuming yet valuable part of my entire design process because it allowed
us as a team to
find faults in the product before it ever reached development. By the last
iteration it was
clear that the product was ready to head into development with me guiding the
way from a design
standpoint.
My Responsibilities
I had various responsibilities throughout the life of this project. I was put
into a lead role
for the initial design process and more of a support role during the actual
development phase of
the project.
- Interviewed members of the support team in order to develop an accurate persona
- Worked side by side with developers to ensure the design needs would be met Created various deliverables such as wireframes, high-fidelity prototypes, and flowcharts
- Developed user stories with project managers in order to establish requirements and Deadlines
- Oversaw in-person user testing that was intended to find shortfalls in the product
Challenges
This being a smaller scale in-house product came with a lot fewer challenges then a broad consumer product. Nonetheless there were still various challenges I faced on the design side from the very early phases to the late development phases. Some of those challenges include the following.
- Managing various aspects of the project that didn’t just include design
- Collecting various information from the support team in order to develop all of the necessary requirements that they wanted to see in the product
- Ensuring development team is accurately developing the product based on the design
- Large project with various features and a strict timeline
Needs vs. Wants
This application was extremely important in the eyes of the support team and the
business as a
whole. It was a way to manage various pieces of lending information, client
branding, support
requests, and more.
It was a way to give support the control that they lacked for so long and the
ability to help
our customers effectively. However, one challenging part of this project was
developing requirements around what we wanted in the first release without
overloading the teams
working on the product with redundant work. Support wanted lots of different
features that would
push the project beyond its deadline so it was very important to meet often in
order to knock
out the features that were truly needed in the first release and what was a
“nice to have”. This
would put less strain on all of the teams involved. The features that were must
haves in the
initial release were:
- A dashboard that would display various pieces of important information such as a list of active partners and an activity list that would show changes to partner branding
- The ability to add new partners and apply their branding identity
- A way to manage or edit existing partners. Including updating their name, logo, and colors
- A login page in order to keep the application secure and open strictly to the support team
- A profile page that allowed support team members to manage their credentials and view activity only related to them
The Toolbelt
I used a lot of my go-to tools for this project such as Miro, Adobe XD, and
Hotjar. I used Miro
in order to sketch out the flow of the application.
This was very helpful because it allowed me to present the flow to the business
and garner
feedback. This feedback would give me the ability to make changes accordingly.
My tool for
prototyping was Adobe XD. It’s one of the prototyping tools I use most because
of all of the
helpful plugins and ease of use. It has a very fluid prototyping feature that I
really enjoy as
well. Another tool that I use on every important UX project is Hotjar. It is
probably one of the
most important tools I use in my day to day. It’s a user tracking tool that
allows me to see
heatmaps, session recording, gather feedback, and so much more. It is the
primary tool I use in
regards to user testing and it has yet to fail me. I feel like using these tools
always gives me
the confidence to tackle any project including this one.
Summary
It was obvious from the beginning of the first release that this new application
would be a game
changer for the support team. It gave them the ability to do their job more
effectively than
ever and gave them the chance to help our customers all from one place.
From the early stages of the design process the excitement for this product was
unreal. Sharing
the first iteration of the prototype was proof enough that they wanted this
badly and couldn’t
wait to get their hands on it, let alone actually having it fully available to
them. Early user
testing showed a great ease of use in regards to how the support team used the
application and
their behavior while making certain decisions within the interface. No obvious
frustrations were
prevalent in any of the user testing and it was clear that the support team
could navigate the
new application with little to no training. Apart from in-person testing I also
tracked a lot of
the user activity within Hotjar to make sure that I didn’t miss anything from
the in-person
sessions. Even with this no negative user behavior was apparent which was a big
plus especially
for the first release.