I had the opportunity of working with Elokuent to examine ideas to optimize their process of finding vendor prices for their products and sending estimates to clients.
view prototypeUX Research
UI Design
Contextual inquiry
Client interview
Competitive analysis
Personas
User stories
Wireframes
User testing
Adobe XD
Adobe Illustrator
Adobe Photoshop
Miro
Design sprint (1-week)
Elokuent is a graphic design agency in Orlando, where I worked as a graphic designer. They offer services from logos, business cards, apparel, signage, and websites.
Owning a company is not easy. Having to look up prices for the services being offered, shouldn't have to be either. As Elokuent has grown, two challenges have arisen.
While I was working at Elokuent, I remember trying different apps to speed up the process of sending proofs to clients. While doing that, some of those apps also offered tools to create and send invoices, one of them being Quickbooks. When I first started looking at apps, I began with Quickbooks since I had already found that it was the website they used for their accounting. I downloaded the app and when I was looking for it on the app store, an ad for Invoice2go came up which made it easier to find additional options to look at.
Robust app with the advantage of Intuit being the parent company. The app benefits from a clean design and it clearly has gone through multiple iterations. The onboarding process helps identify which features are helpful depending on the type of business the user has. Adding a new estimate or invoice is simple and the user is able to integrate it with the rest of her Quickbooks account. When it comes to populating the estimate or invoice, there is no option to reference existing products, so each time an estimate is generated, the user has to start from scratch.
On the other hand, Invoice2go stands out as having features closer related to Elokuent’s needs. Instead of having multiple tools, Invoice2go focuses on sending invoices and features relating to that. More specifically, the ability to add products for quick access when creating an estimate. A weakness that this app has, however, is that it doesn’t let the user use variable prices for the products.
In order to get a clearer picture of what their needs were, I went down to the Elokuent office to conduct an informal interview. Prior to the meeting I had written down notes with assumptions and hypotheses that would help me come up with questions to ask them before seeing them. I was interested in learning what their processes were like when clients call asking for quotes, what tools they use, how many estimates they send out during the day, who is usually in charge of sending them, and most importantly for this design sprint, what item is the most complicated to quote, and which category is sold the most.
The answer to these questions, among others, would structure the design decisions when it came time to build the wireframes.
Before and after doing the interview, I observed how the team was working and got insights into their day to day. Right away I noticed that the phone rings pretty much non-stop, interruptions are going on at all times, everyone has questions, there are always at least 10 applications open on the computer, the browser window has another 10 tabs open and time doesn’t seem to slow down.
What all of this told me was that the solution needed to fit into their hectic schedule. Since the owners are also frequently out of the office, I had to design a system that would let them send estimates while they were not on their office computer.
I left the office full of valuable information, ready to start ideating. I went on the Miro website to generate ideas using the “how might we” method.
Focusing on the scope of the project was crucial and I had to resist ideas that were out of scope. Since this was a design sprint, I knew that I didn’t have the time or the resources to tackle all the products and services that they offer right off the bat. I decided to concentrate on apparel and being able to customize the prices depending on the style, size, color, material, and shirt brand.
It was super important to remember who I was designing for. Even though the owners are the ones who send the most estimates, they also expressed the need to hire other sales people. Training new people could be a lot simpler, but the complex process of searching for prices through all the vendors’ websites has kept them from delegating that task.
For the personas, I created two profiles. One for the owner and the other for the salesperson. Writing down what their motivations and frustrations are, really allowed me to empathize with them and dive deep into their needs.
I need better systems so I can do a great job and get a raise
I have so many tasks to complete and not enough time
Now that I had started empathizing with the users, I was getting closer to start sketching the wireframes. In order to know what the layout was going to be or even what kind of solution would benefit them most, I needed to visualize the current journey from beginning to end. Right away I began noticing redundant steps that needed to be optimized.
What would the optimal scenario look like? In order to show the owners how the new process would help them, a storyboard was just the right tool. It quickly conveyed the idea and the problem the new solution was trying to solve.
After conducting the research, I decided the best solution would be a mobile application. Even though I had thought a desktop website would work well, I found a mobile app would work better since the research showed the owners were out of the office quite a bit and all they had was their phone while out.
Key items I came up while sketching were: a search bar, since the users were used to looking up items in “sent” email messages to create estimates. A layout similar to the one of Quickbooks and Invoice2go where there are favorite/recent items below the search bar and a section with large sized tiles with the main categories.
One of the screens had to allow the users to customize the apparel order, so the sketches helped lay out the content in an intuitive order and with the right hierarchy.
Making sure that I kept the design clean and categories easy to find, I started the design of the wireframes focusing on hierarchy using size and spacing. Based on the user journey from earlier, I made the steps follow what a typical estimate was like. My main objective here was to get the design of the screens done quickly so I could move on to testing as soon as possible to iterate on the design.
For the testing phase, I recruited participants who fit the personas defined earlier. Initially, I observed how the app flow felt, how many steps it took to achieve a desired result, and how simple the whole process was.
The feedback I received was both positive and constructive, describing the app as easy to use, clean, and having a simple interface.
What did participants have to say about improvements? They wish the apparel selection screen was less confusing, with the ability of adding estimates to a “shopping cart” and the system to be better equipped to be filled out during a phone call or a meeting with the client.
Interactive prototype
When sending invoices, the Elokuent team had to go through multiple vendor websites to get product prices and were finding the whole process very tedious. The Elokuent invoice app allows users to have a fast and simple experience sending clients estimates by easily displaying prices of products and services provided by the agency as well as sending the estimate from the app.
The next step is to either continue the design for the rest of the services and products or to start the development process of just the apparel section. Something else that needs to be looked into is the automatic pulling of prices from the vendor websites using an API.
Working with the Elokuent team was very rewarding since this is a project I had in the back of my mind while I was working there and I eventually would love to help them complete it.
