An Interaction Design journey: from scratch to a product

A case study of ideating and building a product from a growing designer perspective in 8 steps

As a fellow UI & Product designer, sometimes we have the tendency to focus on brand coherence, visual appealing and information architecture. But most often than not, we lack feedback (we may have it from our fellow colleagues: designers, developers and or product managers) from real life users.

Also, the UI is one of the final pieces of the creation of a digital product: just before development and production. As I was getting to know more and more the field from the past 4 years working in different startups and digital companies, I was getting more and more interested in the process of building a product from zero. That’s why I decided to complement my studies with a Human Computer Interaction course.

This is an article about the ideation and evolution of a product from scratch to a fully interactive project. I made it as the capstone project for the Interaction Design specialisation at UC San Diego.

This is article is about the ideation and evolution of a product from scratch to a fully interactive product.

1. The idea

We had to select 1 of the 3 broad concepts to do the Capstone Project. The idea I selected was: Time.

After a lot of researching and brainstorming, I realised that what personally impacts me most are my surroundings, the day-to-day life.

My first idea was to support local workers by putting them in contact with either investors or people who want to buy their service or products.

Why:

It started from a social need within the Spanish population: a deep economic crisis in which 30% of the population became unemployed. A lot of local workers (professionals and nonprofessionals) became unemployed, having a lot of knowledge in their respective areas and a lot of time and nobody to invest in them.

Preparing the field:

There’re specifically 2 areas that I wish to investigate in order to fully understand and based my project on:

1. The process of looking for a job, service or a product (from both worker and investor).

2. The process of developing this product or service.

The best projects are the ones you can relate to, because you will put your whole life into it.

2. Needfinding

To select a final idea, you shouldn’t get stuck with the first one you have, even if you think it’s the best one. Limiting yourself to one result cuts out a lot of opportunities out there waiting to be solved. You can find those just by observing the environment, people, or just by talking to them.

For this purpose, I observed and interviewed 3 different persons: all of them freelancers who work in different fields. I chose them specifically for their wide range in age, working areas and their relationship with tools and technology. I asked each of them to go through the processes from how they find a job, do budgets, manage their day-to-day work, contact other skateholders and more. I also asked all of them to show me the most important tools (job finding and management) that they work with on their jobs.

I’ll highlight some observations of the user from which I found the final need. It’s very important to observe a user in his natural work environment, how he works, take notes of every important thing and observe,… a lot.

The most important quality for problem solving is observation.

1. Interviewing

The user:
A 58 year old, currently unemployed architect who works sporadically as a Construction Foreman.

Identifying the user working processes:
I’ll write down to examples from which we can identify different behaviours, needs and workarounds:

1. In the construction building premises: he has an agenda about what he’s got to do and writes down everything the project needs, and what’s been done.
2. In the office: he’s got to write down all the notes he’s taken and type them again into an excel or a word file to make the reports — he types very slow– . He’s worked with a software called Presto which is and advanced tool for budget and construction purchase management. He says but it’s too complicated he isn’t using it anymore.

Observations:

Notes from the construction foreman’s agenda. He draws sketches, writes down notes and budgets.

Here we can see his daily agenda. This is where he writes down what he needs to do, draw some schemes, notes down the materials he needs to buy and other tasks.

We can see that it’s not very organised and he combines very different information: TODOs, prices, amount of materials, name of workers, tasks done and more.

There are very different opportunities that can be addressed: incorporating these sets of information into one, providing a tool that can automatically add what’s written to his office’s tools, and a lot more to improve in terms of management.

Brainstorming ideas

After these observations and relistening to the interviews, it was time to identify every need, and rephrase it as a doable action. These are some of the needs I identified and brainstormed:

1. A construction foreman needs to plan timing, delivery phases, amount of workers needed, materials and money the project will need right after the first meeting with the client.
2. The user needs to write down every day TODOs, progress, done activities and be able to explain/show it to the workers and other notes.
3. The user needs to write down what the construction spends programatically, new or unexpected purchases and plan what the next expenditures are going to be.

Selecting the final need

Selecting the final need or problem to fix is the most important decision, but –do not panic– it will probably change in the process. Also note that the final product can address one or more needs that are proposed to a problem.

There should be a quicker and more organised way to communicate with all the skateholders, regardless of the media used.

Communicating with every skateholder (internal, external, office workers and providers) from a construction building can be very demanding because of the diversity of media used (notes, schemes, blueprints, budgets, phone calls, etc.) and the hardships of group scheduling.

Selecting the final need or problem to fix is the most important decision

3. Storyboarding and paper prototyping

Once I had the need or problem that we need to solve, it was time to address it within a context and for certain users.

Storyboarding:

Storyboarding is a really fast way to build a user story to explain a context in which that product would solve the need we identified.

I created the following storyboards that proposed solutions for: purchasing materials from a construction building and assigning tasks to his workers.

The first storyboard addressed the need of purchasing materials via the app and the second one, creating tasks and sharing it with its coworkers.

Once I identified a solution and the viability of the application — at least from a theoretical point of view) — the next step was getting into details and create a graphic piece that represented what the application could look like.

Paper prototype:

Paper prototyping allowed me to create the interface of different screens for the previously mentioned tasks, focusing only on the function and omitting details. It also allowed me to create elements that can be modified, iterated and destroyed very quickly, that can be reused and crafting it is a really fun thing to do.

Paper prototypes allows to be iterated quickly and recycle elements between screens

4. Analysing the prototype: Heuristic Evaluation

Now that I had a basic skeleton of the application (in form of a paper prototype), it’s turn to evaluate it. It’s the first opportunity I had when the future users or colleagues can give us qualitative feedback on a product that’s more than just a concept.

What is a heuristic evaluation?

A heuristic evaluation is a method that help us find mistakes and usability errors on an application. It involves an evaluator that has to run several tasks throughout the app and evaluate each of them with different criteria, such as: visibility of system status, flexibility and efficiency, error prevention, etc.

With this goal in mind, I made the user run through 2 different prototypes, and made them fill a spreadsheet with the flaws or mistakes they found that fitted these criteria. I gather the results and wrote them down into a single document that helped me to focus on the next steps.

Note: It’s really good to have someone that’s an expert on the field, in this case, I had a construction foreman, that not only found some heuristic errors, but also advised me with improvements, and share his point of view as a constructor and helped me shape some of the small details.

After this, I had the chance of redesigning a wireframe that corrected the issues.

Homepage wireframe redesign

It’s very important to have someone that’s an expert on the field that can help you find errors, advice and share his point of view.

5. Planning the development

This is one of the things that I struggled the most. Because of my inexperience in planning tasks I’ve never done and the variance in tasks that depended on the results of the previous ones.

We, designers, thrive in working with products, polishing them to a non-existent perfection. But planning depends on others, in what you’ve done before, on outside constraints, and much more. So having a road map is a vital part for teams, for our own goal of having a global vision of our project, and turning broad ideas into tangible objects in a measurable time.

Every week, I updated the roadmap to evaluate my progress and the evolution of the project.

Planning for the first week. It is very important to set due dates, estimating times. Even though I in the beginning I was way off with the estimations, with practice I got way better at predicting the time spent on doing the tasks.

Having a road map is a vital part for teams, for our own goal of having a global vision of your project, and turning broad ideas into tangible objects in a measurable time.

6. Prototyping & Testing

I built the UI design & wireframes with Sketch and generate a functional prototype in a reasonable time with inVision. I had one week to build it and another one in which I ran a pilot test with a couple of users that gave me hints to know which features I should’ve tested and what things I had to change.

Preparing the test:

After the pilot test I run the tests with 3 different users: a construction manager, a civil engineer and a developer. Each of them with different backgrounds that could help me a lot to improve the design.

It was very important to prepare the users for the interview, suggesting them to talk aloud with every thought that cross their minds and add a set of tasks that would help me to find errors and improvement opportunities. Some of the tasks were:

• Sign up as a member, joining the Carpenter’s team.
• Create a New Task.
• Create a new reminder.
• View all tasks on October 17th.
• Send a message to the management team.

The different users helped me found different issues in the process.

After the test: planned changes

After the observations, I wrote down a list of actionable changes to be done in the next week. Here is a small fraction of the list:

• Make the task progress buttons more visual and easier to track. The buttons seemed to not be relevant enough.
• Establish starting date for tasks as the main date. It’s more important than the delivery date.
• Remove the “mark as complete” and “delete” buttons on Task creation. They should only be there when editing a task, not creating it.

7. User Testing

With the list of planned changes, I prepared quickly some wireframes with the features to test:

Prototype A includes buttons in the body of the detail page. Prototype B includes them in the bottom as system UI buttons.

With this in mind, I created 2 alternate prototype versions which were ready to be tested.

Testing the prototype: users

On behalf of UC. San Diego, I used Usertesting.com as a tool for real life users to test my product. This tool provides each user the prototype and a series of tasks they have to do. After they do it, I’d have their answers, how they performed, a video of what they were doing with the app, together with what they were saying out loud. It’s an amazing way to get user’s feedback at the expense of being a bit pricey.

A/B Testing allowed me to measure click ratio and speed in the buttons as well as listening and reading to subsequent comments about the performance

This testing allowed me to identify:

• The small buttons in the middle of the screens were recognised faster than the ones that were more system-like (at the bottom of the page).
• All of the tasks were properly done. So it seems that all of them are working well, regardless of the time performance.
• The tasks seem to perform equally depending from the entry point (they can be accessed on both “Tasks” and “Management” sections.
• The users with the same prototypes had a pretty big variation in the times, in Prototype B case, one of them went over the different elements in the page and talked about it loudly and spent a lot more time than what was expected.

In summary, these are not conclusive due to the small amount of users I had, but can be indicative of certain trends to be followed or solved.

Common findings & conclusion:

Apart from the A/B testing results, I also summarised different insights from the rest of the tasks that were not A/B measured:

• All users had different ways to approach the same tasks, even spoke differently (some more others less) and in some cases, there were users that started performing different actions before reading the tasks.
• Some users expect prototypes to be finished products and as such, focus more in prototype or UI failures (or not yet done features) than in the expected tasks.
• System UI seems to have a more important role for advanced users than for the average one. It seems that properly hierarchized actions work better than default system UI elements.
• There was one reminder in the task list that distracted the users because it was not related to a construction task, but to a personal one (take kids to school). And some of them spent time discussing about it instead of performing directly the task.
• Taking out a contextual action from a general section to a subsection did not seem to affect that people would find the action within the tab and not one global and then, select the action.

Additional Features and future changes:

There are also other findings that needs to be addressed and new features that can solve those or enhance the experience. Some of those are:

• Create a gantt type, overall view for projects.
• Improve sharing feature, more in-app oriented than a default “share on other apps”.
• Improve multiple users doing different parts of a single task. Investigate on progress and ownership of the tasks.
• Add search.
• Listing filtering
• Project phases prioritisation.

Final view of the prototype

8. Conclusions:

It was an enriching experience. I learned a lot, specially in paying attention to the users actions, what they say, how they see things and that nobody has the utmost truth: everybody has their own need, and a product needs to be broad enough to cover them, but precise enough to always be focused in the most important actions.

It was also enlightening trying to find the equilibrium between qualitative and quantitive data from results and trying to find the best moment for applying the proper UX techniques to maximise time and effort.

In the end, in 10 weeks I made a prototype of an application that tried to solve the life to construction workers and managers. It’s not yet a finished product. One that started from scratch and needs the last push to become a product.

I’d like to thank Professors Scott Klemmer, Elizabeth Gerber, and Jacob O. Wobbrock for this specialisation program and my fellow colleagues for their help and shared knowledge.

Thanks for reading my first post! you can also find me on twitter and other future posts here. See you around!